Deepseek Harness compaction missing thinking tokens

[JWIMaster]

The fundamental issue I am having right now is when using Qwen3.8 27b, which is a model that tends to think a LOT, and in fact most of its useful output is done in thinking, Deepseek Harness only compacts the actual "output" tokens, which leads to it missing a lot of context, and ends up having it redo things it has already done in thinking. A good example is file generation, the model will build files through thinking and then add them to the directory but not necessarily comment on them in the output tokens. This leads to the compaction acting as if they never existed in the first place. If there is a general fix to this I would be happy to hear suggestions.

[PerryLink]

Short answer: compaction itself does not strip thinking — its input is the verbatim derived messages of the shadowed region, so reasoning survives into the summarization call if and only if your adapter persisted it as message content. The official DeepSeek adapter does exactly that; the gap you're seeing is almost certainly in the local Qwen adapter, so that's where to look.

Evidence, all against HEAD (v0.1.6-alpha.2):

• How the compaction input is built: packages/compaction/compaction-basic/src/region.ts:545-563 — buildSummarizationInput maps the shadowed seqs through session.deriveEventMessage(session.eventAt(seq)!) and forwards the resulting messages untouched.
• Nothing is re-filtered afterwards: packages/compaction/compaction-basic/src/summarizer.ts:144-150 appends only the compaction instruction to input.messages; the package README says it outright — compaction-basic/README.md:186: "The summarization model receives the conversation replayed verbatim — the same system prompt, tool schemas, and messages the last routed request sent for the shadowed region."
• What the surface carries: packages/core/session/src/surface.ts:145-149 — an assistant/message projects to event.data.message verbatim (only empty content projects to null). So if reasoning blocks are in that message's content, they reach the summarizer.
• The official adapter does persist thinking as content: packages/llm/llm-deepseek/src/protocols/messages/translate.ts:51-52 maps native thinking to { type: 'reasoning', text }; the chat-completions path opens reasoning blocks from reasoning_content deltas (chat-completions/translate.ts:93, 159-164) and re-serializes them on replay (chat-completions/serialize.ts:198-199, 226; messages/serialize.ts:31-32). So with the official adapter, thinking reaches compaction by design.
• One design-intent caveat: only the summarizer's returned text becomes the checkpoint — compaction-basic/README.md:118: "only returned text enters the checkpoint, excluding reasoning and tool calls." Thinking is consumed to produce the summary, not preserved verbatim. That's not your bug.

What to check in your adapter (adapter-specific, not verified here):

1. Does it write the model's thinking into the assistant message's content blocks (a reasoning-type block), or does it keep thinking only in provider-side metadata/usage fields? If it never lands in message content, the surface never has it, and compaction cannot include it.
2. Inspect a session archive (session.v3.jsonl.zstd) and look at the assistant/message events for the turns where the model "built files in thinking" — if the reasoning text isn't in content blocks there, that's the smoking gun.
3. If blocks are present, check whether the summarization call traverses the same adapter path and whether that path serializes incoming reasoning blocks (some local adapters silently drop block types they don't know).

If thinking is dropped at ingest, the fix belongs in the adapter (persist reasoning into assistant message content) — there's no compaction-side switch that can recover thinking that was never stored. Paste a snippet of one assistant/message event from your session log and I'll tell you exactly which check fails.