From 1fe8fd1b3395fd04efc343065e1435bb291943fd Mon Sep 17 00:00:00 2001
From: Kaiyi <me@kaiyi.cool>
Date: Fri, 3 Jul 2026 13:30:24 +0800
Subject: [PATCH] feat(agent-core): make compaction notes capture a forward
 plan, not just the next step
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Compaction runs at the point of maximum context for the task, and the next
turn resumes with less. So the handoff note now records the plan for the
remaining work — upcoming steps, settled decisions, and foreseeable obstacles,
plus any work that can be pre-committed — instead of only the immediate next
command. Update the affected compaction snapshots and one hardcoded
input-token assertion (the instruction is ~163 tokens longer).
---
 .changeset/compaction-forward-plan.md         |  5 ++
 .../compaction/compaction-instruction.md      | 13 +++++-
 .../test/agent/compaction/full.test.ts        | 46 +++++++++----------
 3 files changed, 39 insertions(+), 25 deletions(-)
 create mode 100644 .changeset/compaction-forward-plan.md

diff --git a/.changeset/compaction-forward-plan.md b/.changeset/compaction-forward-plan.md
new file mode 100644
index 0000000000..69765325f8
--- /dev/null
+++ b/.changeset/compaction-forward-plan.md
@@ -0,0 +1,5 @@
+---
+"@moonshot-ai/kimi-code": patch
+---
+
+Have context-compaction notes capture a forward plan for the remaining work — upcoming steps, settled decisions, and foreseeable obstacles — instead of only the immediate next step, so the agent continues more coherently after auto-compaction.
diff --git a/packages/agent-core/src/agent/compaction/compaction-instruction.md b/packages/agent-core/src/agent/compaction/compaction-instruction.md
index f0ee851f22..d137e3ca3a 100644
--- a/packages/agent-core/src/agent/compaction/compaction-instruction.md
+++ b/packages/agent-core/src/agent/compaction/compaction-instruction.md
@@ -40,8 +40,17 @@ continue:
   conversation never established — files or paths referenced but not yet read,
   schemas or APIs assumed but unseen, questions the user has not answered. Name
   these gaps so the next turn goes and checks them instead of assuming.
-- The precise next action — including the exact next command or tool call you
-  intend to make — and any required format for the final answer.
+- The forward plan — and this is the moment to invest in it. Right now you
+  hold more context on this task than you ever will again; the next turn
+  resumes with less, so the plan you commit here is the one it will follow.
+  Give the exact next command or tool call, but don't stop at the next step:
+  set out the remaining sequence to finish, the decisions you have already
+  made for those upcoming steps (so the next turn doesn't reopen them), the
+  obstacles or edge cases you can already foresee and how you mean to handle
+  them, and any work you can commit to now — the exact patch, query, or shape
+  of the final answer you already know you will produce. Anything you settle
+  here is one less thing the next turn must rediscover. Include any required
+  format for the final answer.
 
 Your TODO list is re-attached automatically below this note from its live
 source, so do not transcribe it — copying it wastes space and can contradict the
diff --git a/packages/agent-core/test/agent/compaction/full.test.ts b/packages/agent-core/test/agent/compaction/full.test.ts
index a31a247678..cdd0567ead 100644
--- a/packages/agent-core/test/agent/compaction/full.test.ts
+++ b/packages/agent-core/test/agent/compaction/full.test.ts
@@ -76,10 +76,10 @@ describe('FullCompaction', () => {
       [wire] context.append_message     { "message": { "role": "user", "content": [ { "type": "text", "text": "recent user three" } ], "toolCalls": [], "origin": { "kind": "user" } }, "time": "<time>" }
       [wire] full_compaction.begin      { "source": "manual", "instruction": "Keep the important test facts.", "time": "<time>" }
       [emit] compaction.started         { "trigger": "manual", "instruction": "Keep the important test facts." }
-      [wire] usage.record               { "model": "kimi-code", "usage": { "inputOther": 1018, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
-      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 120, "maxContextTokens": 256000, "contextUsage": 0.00046875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1018, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1018, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [wire] usage.record               { "model": "kimi-code", "usage": { "inputOther": 1181, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
+      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 120, "maxContextTokens": 256000, "contextUsage": 0.00046875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1181, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1181, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] context.apply_compaction   { "summary": "Compacted summary.", "contextSummary": "The conversation so far has been compacted to free up context. What follows is your own working summary of this task — use it to continue your train of thought rather than starting over. Treat it as notes, not proof: where it says a step was done, tests passed, or a fix worked, verify that yourself before relying on it. Any user messages earlier in this context are preserved verbatim from the compacted conversation; where a system-reminder note among them marks an omitted middle section, the user messages it replaced are covered by this summary.\\nCompacted summary.", "compactedCount": 6, "tokensBefore": 39, "tokensAfter": 158, "keptUserMessageCount": 3, "time": "<time>" }
-      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 158, "maxContextTokens": 256000, "contextUsage": 0.0006171875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1018, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1018, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 158, "maxContextTokens": 256000, "contextUsage": 0.0006171875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1181, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1181, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] full_compaction.complete   { "time": "<time>" }
       [emit] compaction.completed       { "result": { "summary": "Compacted summary.", "compactedCount": 6, "tokensBefore": 39, "tokensAfter": 158, "keptUserMessageCount": 3 } }
     `);
@@ -93,7 +93,7 @@ describe('FullCompaction', () => {
         assistant: text "old assistant two"
         user: text "recent user three"
         assistant: text "recent assistant three"
-        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history.\\n\\n\\nOptional user instruction:\\nKeep the important test facts."
+        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history.\\n\\n\\nOptional user instruction:\\nKeep the important test facts."
     `);
     expect(ctx.compactHistory()).toMatchInlineSnapshot(`
       [
@@ -126,7 +126,7 @@ describe('FullCompaction', () => {
         compacted_count: 6,
         retry_count: 0,
         thinking_effort: 'off',
-        input_tokens: 1018,
+        input_tokens: 1181,
         output_tokens: 8,
       }),
     });
@@ -979,7 +979,7 @@ describe('FullCompaction', () => {
         assistant: []  calls call_open_one:LookupOne { "query": "one" }, call_open_two:LookupTwo { "query": "two" }
         tool[call_open_one]: text "one result"
         tool[call_open_two]: text "Tool result is not available in the current context. Do not assume the tool completed successfully."
-        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history.\\n\\n\\nOptional user instruction:\\nKeep stable facts."
+        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history.\\n\\n\\nOptional user instruction:\\nKeep stable facts."
     `);
     // The unresolved tool call is sent to the model with a synthetic tool_result
     // closing it (so a strict provider accepts the summary request), while the
@@ -1030,10 +1030,10 @@ describe('FullCompaction', () => {
       [wire] full_compaction.begin      { "source": "manual", "time": "<time>" }
       [emit] compaction.started         { "trigger": "manual" }
       [wire] context.append_message     { "message": { "role": "user", "content": [ { "type": "text", "text": "new user while compacting" } ], "toolCalls": [], "origin": { "kind": "user" } }, "time": "<time>" }
-      [wire] usage.record               { "model": "kimi-code", "usage": { "inputOther": 989, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
-      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 80, "maxContextTokens": 256000, "contextUsage": 0.0003125, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 989, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 989, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [wire] usage.record               { "model": "kimi-code", "usage": { "inputOther": 1152, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
+      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 80, "maxContextTokens": 256000, "contextUsage": 0.0003125, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1152, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1152, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] context.apply_compaction   { "summary": "Compacted prefix.", "contextSummary": "The conversation so far has been compacted to free up context. What follows is your own working summary of this task — use it to continue your train of thought rather than starting over. Treat it as notes, not proof: where it says a step was done, tests passed, or a fix worked, verify that yourself before relying on it. Any user messages earlier in this context are preserved verbatim from the compacted conversation; where a system-reminder note among them marks an omitted middle section, the user messages it replaced are covered by this summary.\\nCompacted prefix.", "compactedCount": 4, "tokensBefore": 25, "tokensAfter": 160, "keptUserMessageCount": 3, "time": "<time>" }
-      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 160, "maxContextTokens": 256000, "contextUsage": 0.000625, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 989, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 989, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated       { "model": "kimi-code", "contextTokens": 160, "maxContextTokens": 256000, "contextUsage": 0.000625, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1152, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1152, "output": 8, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] full_compaction.complete   { "time": "<time>" }
       [emit] compaction.completed       { "result": { "summary": "Compacted prefix.", "compactedCount": 4, "tokensBefore": 25, "tokensAfter": 160, "keptUserMessageCount": 3 } }
     `);
@@ -1045,7 +1045,7 @@ describe('FullCompaction', () => {
         assistant: text "old assistant one"
         user: text "recent user two"
         assistant: text "recent assistant two"
-        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
+        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
     `);
     expect(ctx.compactHistory()).toMatchInlineSnapshot(`
       [
@@ -1094,8 +1094,8 @@ describe('FullCompaction', () => {
       [emit] compaction.started       { "trigger": "manual" }
       [wire] context.clear            { "time": "<time>" }
       [emit] agent.status.updated     { "model": "kimi-code", "contextTokens": 0, "maxContextTokens": 256000, "contextUsage": 0, "planMode": false, "swarmMode": false, "permission": "manual" }
-      [wire] usage.record             { "model": "kimi-code", "usage": { "inputOther": 989, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
-      [emit] agent.status.updated     { "model": "kimi-code", "contextTokens": 0, "maxContextTokens": 256000, "contextUsage": 0, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 989, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 989, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [wire] usage.record             { "model": "kimi-code", "usage": { "inputOther": 1152, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
+      [emit] agent.status.updated     { "model": "kimi-code", "contextTokens": 0, "maxContextTokens": 256000, "contextUsage": 0, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1152, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1152, "output": 7, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] full_compaction.cancel   { "time": "<time>" }
       [emit] compaction.cancelled     {}
     `);
@@ -1107,7 +1107,7 @@ describe('FullCompaction', () => {
         assistant: text "old assistant one"
         user: text "recent user two"
         assistant: text "recent assistant two"
-        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
+        user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
     `);
     expect(ctx.compactHistory()).toMatchInlineSnapshot(`[]`);
     await ctx.expectResumeMatches();
@@ -1138,10 +1138,10 @@ describe('FullCompaction', () => {
       [wire] full_compaction.begin       { "source": "auto", "time": "<time>" }
       [emit] compaction.started          { "trigger": "auto" }
       [emit] compaction.blocked          { "turnId": 0 }
-      [wire] usage.record                { "model": "kimi-code", "usage": { "inputOther": 1010, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
-      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 950000, "maxContextTokens": 256000, "contextUsage": 3.7109375, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1010, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1010, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [wire] usage.record                { "model": "kimi-code", "usage": { "inputOther": 1173, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
+      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 950000, "maxContextTokens": 256000, "contextUsage": 3.7109375, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1173, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1173, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] context.apply_compaction    { "summary": "Auto compacted summary.", "contextSummary": "The conversation so far has been compacted to free up context. What follows is your own working summary of this task — use it to continue your train of thought rather than starting over. Treat it as notes, not proof: where it says a step was done, tests passed, or a fix worked, verify that yourself before relying on it. Any user messages earlier in this context are preserved verbatim from the compacted conversation; where a system-reminder note among them marks an omitted middle section, the user messages it replaced are covered by this summary.\\nAuto compacted summary.", "compactedCount": 7, "tokensBefore": 46, "tokensAfter": 166, "keptUserMessageCount": 4, "time": "<time>" }
-      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 166, "maxContextTokens": 256000, "contextUsage": 0.0006484375, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1010, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1010, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 166, "maxContextTokens": 256000, "contextUsage": 0.0006484375, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1173, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1173, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] full_compaction.complete    { "time": "<time>" }
       [emit] compaction.completed        { "result": { "summary": "Auto compacted summary.", "compactedCount": 7, "tokensBefore": 46, "tokensAfter": 166, "keptUserMessageCount": 4 } }
       [wire] context.append_loop_event   { "event": { "type": "step.begin", "uuid": "<uuid-1>", "turnId": "0", "step": 1 }, "time": "<time>" }
@@ -1151,7 +1151,7 @@ describe('FullCompaction', () => {
       [wire] context.append_loop_event   { "event": { "type": "step.end", "uuid": "<uuid-1>", "turnId": "0", "step": 1, "usage": { "inputOther": 165, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "finishReason": "end_turn" }, "time": "<time>" }
       [emit] turn.step.completed         { "turnId": 0, "step": 1, "stepId": "<uuid-1>", "usage": { "inputOther": 165, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "finishReason": "end_turn" }
       [wire] usage.record                { "model": "kimi-code", "usage": { "inputOther": 165, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "turn", "time": "<time>" }
-      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 176, "maxContextTokens": 256000, "contextUsage": 0.0006875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1175, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1175, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 }, "currentTurn": { "inputOther": 165, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated        { "model": "kimi-code", "contextTokens": 176, "maxContextTokens": 256000, "contextUsage": 0.0006875, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "kimi-code": { "inputOther": 1338, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1338, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 }, "currentTurn": { "inputOther": 165, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [emit] turn.ended                  { "turnId": 0, "reason": "completed" }
     `);
     expect(ctx.llmInputs()).toMatchInlineSnapshot(`
@@ -1166,7 +1166,7 @@ describe('FullCompaction', () => {
           user: text "recent user three"
           assistant: text "recent assistant three"
           user: text "Answer after compacting"
-          user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
+          user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
 
       call 2:
         messages:
@@ -2175,10 +2175,10 @@ describe('FullCompaction', () => {
       [wire] full_compaction.begin       { "source": "auto", "time": "<time>" }
       [emit] compaction.started          { "trigger": "auto" }
       [emit] compaction.blocked          { "turnId": 0 }
-      [wire] usage.record                { "model": "mock-model", "usage": { "inputOther": 972, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
-      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 0, "maxContextTokens": 1000000, "contextUsage": 0, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 972, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 972, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [wire] usage.record                { "model": "mock-model", "usage": { "inputOther": 1135, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "session", "time": "<time>" }
+      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 0, "maxContextTokens": 1000000, "contextUsage": 0, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 1135, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1135, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] context.apply_compaction    { "summary": "First compacted summary.", "contextSummary": "The conversation so far has been compacted to free up context. What follows is your own working summary of this task — use it to continue your train of thought rather than starting over. Treat it as notes, not proof: where it says a step was done, tests passed, or a fix worked, verify that yourself before relying on it. Any user messages earlier in this context are preserved verbatim from the compacted conversation; where a system-reminder note among them marks an omitted middle section, the user messages it replaced are covered by this summary.\\nFirst compacted summary.", "compactedCount": 1, "tokensBefore": 8, "tokensAfter": 153, "keptUserMessageCount": 1, "time": "<time>" }
-      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 153, "maxContextTokens": 1000000, "contextUsage": 0.000153, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 972, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 972, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 153, "maxContextTokens": 1000000, "contextUsage": 0.000153, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 1135, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1135, "output": 9, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [wire] full_compaction.complete    { "time": "<time>" }
       [emit] compaction.completed        { "result": { "summary": "First compacted summary.", "compactedCount": 1, "tokensBefore": 8, "tokensAfter": 153, "keptUserMessageCount": 1 } }
       [wire] context.append_loop_event   { "event": { "type": "step.begin", "uuid": "<uuid-1>", "turnId": "0", "step": 1 }, "time": "<time>" }
@@ -2193,7 +2193,7 @@ describe('FullCompaction', () => {
       [wire] context.append_loop_event   { "event": { "type": "step.end", "uuid": "<uuid-1>", "turnId": "0", "step": 1, "usage": { "inputOther": 154, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "finishReason": "tool_use" }, "time": "<time>" }
       [emit] turn.step.completed         { "turnId": 0, "step": 1, "stepId": "<uuid-1>", "usage": { "inputOther": 154, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "finishReason": "tool_use" }
       [wire] usage.record                { "model": "mock-model", "usage": { "inputOther": 154, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 }, "usageScope": "turn", "time": "<time>" }
-      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 165, "maxContextTokens": 1000000, "contextUsage": 0.000165, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 1126, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1126, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 }, "currentTurn": { "inputOther": 154, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
+      [emit] agent.status.updated        { "model": "mock-model", "contextTokens": 165, "maxContextTokens": 1000000, "contextUsage": 0.000165, "planMode": false, "swarmMode": false, "permission": "manual", "usage": { "byModel": { "mock-model": { "inputOther": 1289, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 } }, "total": { "inputOther": 1289, "output": 20, "inputCacheRead": 0, "inputCacheCreation": 0 }, "currentTurn": { "inputOther": 154, "output": 11, "inputCacheRead": 0, "inputCacheCreation": 0 } } }
       [emit] turn.step.interrupted       { "turnId": 0, "step": 2, "reason": "error", "message": "Compaction limit exceeded (1)" }
       [emit] turn.ended                  { "turnId": 0, "reason": "failed", "error": { "code": "context.overflow", "message": "Compaction limit exceeded (1)", "name": "KimiError", "details": { "maxCompactions": 1, "turnId": 0 }, "retryable": true } }
     `);
@@ -2206,7 +2206,7 @@ describe('FullCompaction', () => {
         tools: []
         messages:
           user: text "Trigger repeated compaction"
-          user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The precise next action — including the exact next command or tool call you\\n  intend to make — and any required format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
+          user: text "You are about to run out of context. Write a first-person handoff note to\\nyourself so you can seamlessly continue this task after the earlier\\nconversation is cleared.\\n\\n--- This message is a direct task, not part of the above conversation ---\\n\\nWrite the note as your own continuing train of thought — first person, present\\ntense, the way you would reason through the next move. Do not write a\\nthird-party report about someone else's work, and do not impose rigid section\\nheadings; let the shape follow the task. Write the note in the same language the\\nconversation has been using — do not switch to English just because these\\ninstructions happen to be in English.\\n\\nMake the note self-sufficient: the next turn will see only your most recent user\\nmessages and this note — every assistant message, tool call, and tool result\\nabove will be gone. In your own words, preserve what you genuinely need to\\ncontinue:\\n\\n- What the latest request is actually asking for: your reading of its intent and\\n  any ambiguity you have already resolved — not a re-transcription, since what\\n  fits is kept verbatim in your most recent messages. But those kept messages are\\n  size-capped, so a long request is truncated there: if the latest request is\\n  large (a big paste or file), preserve the parts at risk of being dropped —\\n  above all the actual ask. If several requests are in play, say which one governs\\n  the next move, and re-quote any still-relevant earlier request that may have\\n  scrolled out of the kept messages.\\n- The instructions and constraints currently in force (user preferences,\\n  project rules, environment and tooling limits) — condensed to what still\\n  matters, keeping decisions you have already settled (what you chose and why)\\n  separate from questions still open, so you neither silently reopen a closed\\n  choice nor treat an undecided point as decided.\\n- What has actually been done, at high fidelity: keep the exact commands that\\n  were run, the exact file paths touched, and whether each succeeded or failed —\\n  and the results themselves, not just the commands: the concrete values\\n  returned, the key lines or error text, the schema or signature a lookup\\n  revealed, since re-running to recover them may be slow or impossible. Keep only\\n  the final working version of any code; drop intermediate attempts and\\n  already-resolved errors.\\n- What you still don't know: context the next step depends on that this\\n  conversation never established — files or paths referenced but not yet read,\\n  schemas or APIs assumed but unseen, questions the user has not answered. Name\\n  these gaps so the next turn goes and checks them instead of assuming.\\n- The forward plan — and this is the moment to invest in it. Right now you\\n  hold more context on this task than you ever will again; the next turn\\n  resumes with less, so the plan you commit here is the one it will follow.\\n  Give the exact next command or tool call, but don't stop at the next step:\\n  set out the remaining sequence to finish, the decisions you have already\\n  made for those upcoming steps (so the next turn doesn't reopen them), the\\n  obstacles or edge cases you can already foresee and how you mean to handle\\n  them, and any work you can commit to now — the exact patch, query, or shape\\n  of the final answer you already know you will produce. Anything you settle\\n  here is one less thing the next turn must rediscover. Include any required\\n  format for the final answer.\\n\\nYour TODO list is re-attached automatically below this note from its live\\nsource, so do not transcribe it — copying it wastes space and can contradict the\\nlive version. What that list cannot hold is the reasoning between tasks — why one\\nwas reordered or dropped, or a decision on one that constrains another — so\\nrecord that instead.\\n\\nBe honest about uncertainty. If an earlier step claimed something was done but\\nwas never verified (tests \\"passing\\", a fix \\"working\\", a file \\"created\\"), say so\\nplainly and treat it as unverified rather than fact — re-check before relying\\non it.\\n\\nBe concise, and keep the note proportional to the task: a long multi-step task\\nwarrants detail, but a trivial or nearly finished exchange needs only a sentence\\nor two — do not pad it out. Include the critical data, identifiers, and\\nreferences needed to continue, and omit anything that does not change the next\\nmove.\\n\\nRespond with text only. Do not call any tools — you already have everything you\\nneed in the conversation history."
 
       call 2:
         messages: