Findings from a long multi-task Kimi K3 session: ten long tasks used 57% of
451 M tokens, tool results were 31% of the final context and whole-file
write_file bodies 14%, and compaction fired once. Three harness changes:
1. Tool-result cap. Every tool result is bounded on arrival at 10,000 bytes,
head + tail, with a marker naming the spill file that holds the full text
(coworker/toolresult.py; engine `_record_result`; config
`tool_result_max_bytes`, env COWORKER_TOOL_RESULT_MAX_BYTES, 0 = off).
The spill folder is the session's scratch root when there is one, else it
joins the session's directories read-only so read_file can open it.
shell.py's own 20k-char tail cut becomes a 2M safety net.
2. Edit steering. write_file, replace_in_file, apply_patch and
apply_unified_diff describe WHEN to use each (catalog.EDIT_TOOL_GUIDANCE),
and the Cowork prompt says to edit in place rather than rewrite.
3. Compaction. `compaction_cap_tokens` (config / env
COWORKER_COMPACTION_CAP_TOKENS) lowers the trigger; each compaction writes
the verbatim transcript of the compacted turns (no reasoning) to the spill
folder and the compacted block names the file (CompactionState.transcript_path,
compaction.render_transcript).
Trial on 15 long tasks x 3 attempts (Kimi K3 via Together, cap 60,000):
33/45 passed vs 54/75 for the unchanged harness on the same tasks, tokens per
attempt 3.30 M -> 1.40 M, cost down 44%. Observed and left for a
follow-up: Kimi's summariser reply lands mostly in reasoning within the
3,000-token summary budget (7 proper summaries in 103 calls), and the trial had
16 timeouts vs 9 in the baseline.
Tests: tests/test_tool_result_cap.py, tests/test_edit_tool_guidance.py,
tests/test_compaction_transcript.py; full suite unchanged against the Windows
baseline.
