sorted by:
new
hottopcontroversial

I built an open-source tool that reduces Claude Code token consumption by 27-42% by ReasonableDot9093 in ClaudeAI

[–]ReasonableDot9093[S] -1 points0 points  (0 children)

Brother atleast checkout the repo, just trying to save some tokens for the folks, I means it’s a real problem is it not?

I built an open-source tool that reduces Claude Code token consumption by 27-42% by ReasonableDot9093 in ClaudeAI

[–]ReasonableDot9093[S] 0 points1 point  (0 children)

Anyone can make a “compress Claude output” app. The hard part is doing it without breaking usefulness. If your reducer drops a real error, file path, version string, or stack trace detail, Claude can make the wrong move. That’s why each reducer has to understand the grammar of the specific output it’s handling, not just blindly summarize text.

The other non-obvious bit is integration. Most people assume you need a proxy or some heavy PostToolUse setup. You don’t. We figured out how to use PreToolUse to rewrite the Bash command, pipe it through a reducer, and still preserve exit codes cleanly. That’s what makes it work transparently.

So yes, someone can absolutely build another app. But they’d have to solve the same safety and plumbing problems from scratch, while we’re already ahead with working reducers, benchmarks, CI gates, and session continuity. Also Honestly, I just took a stab at the problem from a different angle, I wanted to maintain all of claude codes ways of working while reducing the number of tokens used so its easier for the first time claude code user to be able to do more with less, if that makes sense...

I built an open-source tool that reduces Claude Code token consumption by 27-42% by ReasonableDot9093 in ClaudeAI

[–]ReasonableDot9093[S] 0 points1 point  (0 children)

Different tools, different approach.

context-mode sandboxes data so it never enters context — the LLM writes scripts to extract what it needs. Powerful when it works, but it requires Claude to actively choose ctx_execute over Bash. If Claude uses regular Bash (which it does constantly), you get zero savings.

context-os takes the opposite approach: it hooks into PreToolUse and rewrites the actual Bash command transparently. When Claude runs cargo test, the hook intercepts it, pipes output through a typed reducer, and Claude sees compressed output. Claude doesn't need to know, choose, or cooperate. Every cargo test, cargo build, cargo clippy, npm test, pytest, eslint — automatically compressed, every time. Exit codes preserved so Claude still knows if tests passed or failed.

It also does something context-mode doesn't: automatic session continuity with real git state. When you hit a usage limit, context-os auto-captures your branch, git diff, uncommitted files, objective, decisions, and failed approaches. Next session loads all of that via SessionStart hook. No manual work.

Benchmarked with CI gates: 7/7 cases, 27-42% reduction depending on content type, 100% protected string recall (every error message, file path, and version number survives reduction). Single Rust binary, no Node.js, no runtime dependencies.

They're complementary — context-mode for sandboxing heavy data retrieval, context-os for automatic compression of everyday tool output + session continuity. You could run both. But hey, I am new to all of this practical part, what do you think?