关于 HISTORY_SNIP 的 head+tail 策略：中间的结果是否同样重要？

[zwrong]

Hi! First of all, thank you so much for this article series. The 04-context-compression piece explains the four-layer compression strategy very clearly, and I learned a lot from it.

I had two questions while reading the HISTORY_SNIP section:

1. Is the head+tail strategy appropriate for grep and other search results?

The article mentions that HISTORY_SNIP's compression strategy is to "retain the first and last few lines," and CoreCoder's _snip_tool_outputs() implements this by keeping the first 3 + last 3 lines.

But I was thinking: for grep search results, important matches can appear anywhere in the output — beginning, middle, or end. For example, a key function call that the LLM is searching for might happen to appear in the middle of the output, and the head+tail strategy would discard it entirely.

Have you considered alternative strategies? For example:

• Retaining results by relevance/weight (though that's hard to judge without calling an LLM)
• Using different strategies for different types of tool output (grep results vs. bash command output vs. file reads)
• Keeping head + middle + tail segments instead of just head+tail

I'd love to hear your thinking on this design trade-off.

2. Where does this conclusion come from?

I looked into Claude Code's source code and found:

• The HISTORY_SNIP feature flag does exist and is referenced in query.ts, QueryEngine.ts, tools.ts, and other files
• However, the actual implementation modules (snipCompact.js, snipProjection.js, SnipTool.js) do not exist in the currently public source code — they are all conditionally required via feature('HISTORY_SNIP'), but the files themselves are missing
• The only truncation logic currently in the source is BashTool/utils.ts's formatOutput(), which performs head-only truncation: content.slice(0, maxOutputLength) plus "... [N lines truncated] ..." — there is no tail preservation

So the specific strategy described in the article — "keep first and last few lines + [snipped N lines]" — doesn't have a corresponding implementation in the Claude Code source. CoreCoder's _snip_tool_outputs() does implement head+tail, but that appears to be CoreCoder's own design rather than something derived from Claude Code.

I'd like to confirm: is this conclusion based on inference from the source code, or from other sources?

---

Thanks again for the article series and the CoreCoder project — they've been a huge help in understanding AI coding agent architecture!

[he-yufeng]

Great questions — and your source code analysis is spot on. Let me address both.

1. Head+tail for grep/search results

You're right that head+tail is a lossy heuristic, and grep results are the worst case for it. The key match could be on line 47 of 200 and you'd lose it entirely.

Claude Code's actual approach (as of the leaked/decompiled source) is more nuanced than what I described in the article:

• BashTool: uses head-only truncation (content.slice(0, maxOutputLength) + [N lines truncated]), as you found. The reasoning is that bash output is usually ordered by relevance (grep results appear in file order, but the user typically cares about the first few hits).
• HISTORY_SNIP: the feature flag exists and is referenced, but the implementation modules (snipCompact.js, snipProjection.js) are indeed gated behind the flag and not present in the public/leaked source. This is an internal A/B test that hasn't shipped to all users.

CoreCoder's _snip_tool_outputs() head+tail strategy is my own design choice, not a direct port from Claude Code. I should have been clearer about this in the article. The rationale was: for most tool outputs (file reads, ls, git log), the beginning gives context and the end gives the most recent/relevant info. For grep specifically, it's suboptimal.

Better strategies I've considered but didn't implement (to keep CoreCoder simple):

• Per-tool-type snipping: grep keeps all match lines but truncates surrounding context; bash keeps head; file reads keep head+tail
• Semantic dedup: collapse repeated patterns (e.g., 50 similar grep matches → keep 5 representative ones)
• Token-budget allocation: give each tool result a token budget proportional to how recently it was called

These are all valid improvements. If you want to experiment, _snip_tool_outputs() in core.py is the right place to hook in.

2. Source attribution

You're 100% correct. The HISTORY_SNIP implementation details in the article were partly inferred from the feature flag references and partly from CoreCoder's own design. The actual Claude Code snip modules are not in the public source. I'll add a clarification note to the article to distinguish between "what Claude Code references but doesn't expose" vs "what CoreCoder implements."

Thanks for the careful reading — this is exactly the kind of feedback that makes the articles better.

[he-yufeng]

已回复，关闭。如有后续问题欢迎重新开 issue。