Sipcode

The re-read dedup looks like a clear win! QQ - when you inject a head_limit on a grep Claude ran without one, does the model see a "truncated, N more matches exist" marker? Does it read the capped list as the full set? Overall, very well done!

The dogfooding story sells this more than any benchmark — discovering your own drift tool read 624,940 tokens wasted while --stats credited 7,553 saved, then root-causing it to uncached mid-session installs and shipping Warm-Fill in 24h. Most launches would've quietly buried that. And the 38% duplicate-Read finding finally names that "why does this session feel sluggish" sensation I could never explain.One question on the dedup: you canonicalize LF and BOM before the byte comparison. For files where whitespace carries meaning — Python, Makefiles, YAML — can that normalization ever flatten a real change into a false no-op, or is it strictly newline/BOM and never touches interior whitespace?

Claude Code users know how quickly context gets polluted with logs, repetitive outputs, and tool noise 😅 The idea of treating context as a limited resource rather than an infinite one really resonates. Curious... what was the most surprising source of context bloat you discovered while building Sipcode?

Congrats on the launch! Keeping Claude Code context clean is a very real pain point for anyone building with AI coding tools. I like the focus on sharper answers instead of just longer context. How are you deciding what should stay in context versus what should be summarized or dropped?

Context bloat is my #1 frustration with Claude Code in long sessions. You watch it re-read the same files and re-print npm install walls of text and by the end of a complex session the answers are noticeably worse. The 40% agent error reduction stat is the one that got my attention - quality lift is nice but errors are the thing that actually breaks workflows. The PreToolUse hook approach is smart because it intercepts before the context gets polluted rather than trying to clean up after. Installing this today. Does it handle situations where Claude Code genuinely needs to re-read a file because it changed, or does it dedupe those too?

Great minimal video you have I liked it but would have been more interesting with a voiceover!

The context window management problem in Claude Code is real. Long sessions accumulate dead weight fast, old tool outputs, abandoned approaches, redundant file reads, and once the context gets bloated the model starts hedging more and the answers get muddier. Curious whether Sipcode is doing something principled to decide what to prune (like deprioritizing failed attempts or stale file state) or whether it's more of a manual curation layer where you're telling it what to keep. Also wondering if there's any handling for cases where something that looked like a dead end earlier in the session turns out to be relevant again.

Hey, congrats! A couple of questions.Have you measured the quality performance somehow? I mean, the speed/quality on certain tasks.Also - is it configurable be Claude to "disable" it if needed, if it things that the hook over-stripped the content?Thanks!

Hey PH. I'm Anuj, solo indie dev. Built Sipcode because I kept watching Claude Code re-read the same files 6-8 times per session and re-print 4,000-line npm install logs into its context. Each unnecessary token in the window pushes signal out and makes the next answer worse. That is the reliability problem I built it to fix.

It is a PreToolUse hook for Claude Code. Caps verbose output (git log, npm install, grep, tsc), dedupes same-session re-reads of unchanged files, exposes 15 MCP tools so Claude can read its own context-hygiene stats. Anthropic's own research: cleaner context lifts quality 29% and cuts agent errors 40%. That is the mechanism Sipcode targets.

Tokens saved are the PROOF the context got cleaner. Locked 20-task benchmark: 62.6% median tool-output savings, $67.43 per corpus run, reproducible on any machine. The benchmark task list is checked into the repo.

Honest disclosure that became the launch story: last week my drift tool said 624,940 tokens wasted in a single session. My proxy --stats credited only 7,553 saved. 83x undercount, my own tool lying to me. Root cause was mid-session installs leaving the first half of the session uncached. Shipped v1.6.15 with Verified Warm-Fill 24h later, drift now reads "no drift detected." Shipped v1.6.16 today with cache-defer and grep-cap fixes. Three releases in nine days.

MIT, zero network calls in normal use (privacy test fails the build if anyone imports node:http in src/). Happy to answer anything technical, especially the Warm-Fill correctness proof or the benchmark methodology.

If Sipcode saves you a session, a star on the repo at github.com/Anuj7411/sipcode would mean a lot to a solo project trying to find the people who would actually benefit from this.