What version of Kimi Code is running?
0.39.1 (observed on the installed CLI; a latest-release live reproduction has not been run)
Which open platform/subscription were you using?
Custom OpenAI-compatible BYOK provider using Alibaba Cloud Model Studio / DashScope, through an intermediary gateway. No Kimi subscription model was used for this sample.
Which model were you using?
qwen3.7-max; thinking effort medium; declared context window 1,000,000 tokens
What platform is your computer?
Linux remote machine. Exact kernel details were not captured in this investigation.
What issue are you seeing?
In a real ACP session, automatic compaction received an HTTP 200 response whose entire visible text was ACK_21. Kimi accepted that acknowledgement as the summary and committed the context replacement. A deliberate middle-session update was then unavailable to subsequent turns.
The original wire.jsonl still contains the update. This report concerns loss from the active model context, not deletion of the durable transcript. All conversation data used for this test was synthetic.
Sanitized projection of the observed native records, in file order:
{"type":"context.append_message","testBatch":12,"observedTextExcerpt":"业务更新：交付日改为周三，中段校验码=682514；其他初始事实不变。"}
{"type":"full_compaction.begin","source":"auto"}
{"type":"llm.request","kind":"compaction","messageCount":45,"maxTokens":65536}
{"type":"context.apply_compaction","summary":"ACK_21","compactedCount":44,"tokensBefore":346584,"tokensAfter":47335,"summaryOutputTokens":179,"keptUserMessageCount":4,"keptHeadUserMessageCount":2}
{"type":"full_compaction.complete"}testBatch and observedTextExcerpt above are annotations for this projection, not additional native wire fields. The stored contextSummary consisted of the normal handoff wrapper followed by ACK_21; it contained neither the updated day nor the middle verification code.
The gateway's text extraction independently showed the compaction instruction requesting a handoff summary, and the response text was also exactly ACK_21. This extraction is not a complete raw supplier request. The request used 902,523 input tokens including cache. The reported 179 output tokens included 172 reasoning tokens and only 7 visible-output tokens; the saved summary was six characters. The native tokensBefore above is a separate estimate and must not be compared directly to provider input usage.
After loading the same native session, the model could recall the initial deadline (Friday) and other initial facts, but could not recall the change to Wednesday or the middle verification code. Those facts were in the middle, outside the retained head/tail messages.
A subsequent ordinary continuation request encountered HTTP 429. Native records show that this occurred after context.apply_compaction and full_compaction.complete, so it did not cause the acknowledgement-only summary to be committed. Error propagation is tracked separately in #3107 / #1865.
What steps can reproduce the bug?
Observed reproduction pattern (model output is nondeterministic; the exact triggering batch can vary):
- Start a fresh Kimi 0.39.1 ACP session with a custom OpenAI-compatible model configured for a 1M context window and medium thinking. Use only synthetic facts and do not invoke tools. Record an initial deadline of Friday and ask for a short acknowledgement.
- Append independent synthetic ASCII batches of approximately 56,000 characters, one completed turn at a time, asking only for
ACK_nn. In batch 12, place an explicit update before the synthetic-data block: 业务更新：交付日改为周三，中段校验码=682514；其他初始事实不变。
- Continue until native automatic compaction is triggered. Do not issue a concurrent prompt or a manual
/compact. In the observed sample it triggered on batch 21. The live run used the unmodified window and compaction settings.
- Inspect
llm.request(kind=compaction) and context.apply_compaction, then ask for the current deadline and the middle verification code without supplying their values again.
The filler can be reproduced with this generator:
def filler(batch, length=56000):
chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
x = (20260909 + batch) & 0xffffffff
out = []
for _ in range(length):
x = (1664525 * x + 1013904223) & 0xffffffff
out.append(chars[x % 62])
return ''.join(out)A deterministic regression could stub only the summarizer to return a nonempty acknowledgement with a normal finish reason, then test whether it is committed as a replacement summary. That is a suggested test, not an additional reproduction claimed to have been executed here.
What is the expected behavior?
An acknowledgement-only response should not silently replace a long conversation as if it were a usable summary. Define and validate a minimal summary contract before applying the context replacement. If a response fails that contract, retain the recoverable old context and retry within a bound or report a compaction failure.
This is not a request to special-case ACK_21 or to claim that an arbitrary length check can guarantee semantic completeness. A successful real compaction should retain the current business facts and updates needed to continue the task.
Additional information
Relevant source area: the v2 collectSummary and compaction commit path in fullCompactionService.ts. The visible-summary acceptance check rejects empty content and truncated completion, but a nonempty acknowledgement passes.
Related issues reviewed: #3487 (summary authority/reinjection), #2680 (continuation targeting), and #3629 (misleading compaction wait text). This report isolates the earlier acceptance/commit boundary: the summary itself has no task information when middle history is replaced.
Only sanitized event projections and synthetic values are included here. Private account, deployment, session and request identifiers, full request/response dumps, credentials and reasoning text are omitted. No production program/configuration was modified during investigation.
Contribution
What version of Kimi Code is running?
0.39.1 (observed on the installed CLI; a latest-release live reproduction has not been run)
Which open platform/subscription were you using?
Custom OpenAI-compatible BYOK provider using Alibaba Cloud Model Studio / DashScope, through an intermediary gateway. No Kimi subscription model was used for this sample.
Which model were you using?
qwen3.7-max; thinking effort medium; declared context window 1,000,000 tokens
What platform is your computer?
Linux remote machine. Exact kernel details were not captured in this investigation.
What issue are you seeing?
In a real ACP session, automatic compaction received an HTTP 200 response whose entire visible text was
ACK_21. Kimi accepted that acknowledgement as the summary and committed the context replacement. A deliberate middle-session update was then unavailable to subsequent turns.The original
wire.jsonlstill contains the update. This report concerns loss from the active model context, not deletion of the durable transcript. All conversation data used for this test was synthetic.Sanitized projection of the observed native records, in file order:
{"type":"context.append_message","testBatch":12,"observedTextExcerpt":"业务更新：交付日改为周三，中段校验码=682514；其他初始事实不变。"} {"type":"full_compaction.begin","source":"auto"} {"type":"llm.request","kind":"compaction","messageCount":45,"maxTokens":65536} {"type":"context.apply_compaction","summary":"ACK_21","compactedCount":44,"tokensBefore":346584,"tokensAfter":47335,"summaryOutputTokens":179,"keptUserMessageCount":4,"keptHeadUserMessageCount":2} {"type":"full_compaction.complete"}testBatchandobservedTextExcerptabove are annotations for this projection, not additional native wire fields. The storedcontextSummaryconsisted of the normal handoff wrapper followed byACK_21; it contained neither the updated day nor the middle verification code.The gateway's text extraction independently showed the compaction instruction requesting a handoff summary, and the response text was also exactly
ACK_21. This extraction is not a complete raw supplier request. The request used 902,523 input tokens including cache. The reported 179 output tokens included 172 reasoning tokens and only 7 visible-output tokens; the saved summary was six characters. The nativetokensBeforeabove is a separate estimate and must not be compared directly to provider input usage.After loading the same native session, the model could recall the initial deadline (Friday) and other initial facts, but could not recall the change to Wednesday or the middle verification code. Those facts were in the middle, outside the retained head/tail messages.
A subsequent ordinary continuation request encountered HTTP 429. Native records show that this occurred after
context.apply_compactionandfull_compaction.complete, so it did not cause the acknowledgement-only summary to be committed. Error propagation is tracked separately in #3107 / #1865.What steps can reproduce the bug?
Observed reproduction pattern (model output is nondeterministic; the exact triggering batch can vary):
ACK_nn. In batch 12, place an explicit update before the synthetic-data block:业务更新：交付日改为周三，中段校验码=682514；其他初始事实不变。/compact. In the observed sample it triggered on batch 21. The live run used the unmodified window and compaction settings.llm.request(kind=compaction)andcontext.apply_compaction, then ask for the current deadline and the middle verification code without supplying their values again.The filler can be reproduced with this generator:
A deterministic regression could stub only the summarizer to return a nonempty acknowledgement with a normal finish reason, then test whether it is committed as a replacement summary. That is a suggested test, not an additional reproduction claimed to have been executed here.
What is the expected behavior?
An acknowledgement-only response should not silently replace a long conversation as if it were a usable summary. Define and validate a minimal summary contract before applying the context replacement. If a response fails that contract, retain the recoverable old context and retry within a bound or report a compaction failure.
This is not a request to special-case
ACK_21or to claim that an arbitrary length check can guarantee semantic completeness. A successful real compaction should retain the current business facts and updates needed to continue the task.Additional information
Relevant source area: the v2
collectSummaryand compaction commit path in fullCompactionService.ts. The visible-summary acceptance check rejects empty content and truncated completion, but a nonempty acknowledgement passes.Related issues reviewed: #3487 (summary authority/reinjection), #2680 (continuation targeting), and #3629 (misleading compaction wait text). This report isolates the earlier acceptance/commit boundary: the summary itself has no task information when middle history is replaced.
Only sanitized event projections and synthetic values are included here. Private account, deployment, session and request identifiers, full request/response dumps, credentials and reasoning text are omitted. No production program/configuration was modified during investigation.
Contribution