New Currency
Forget cloud bills — in 2026, the line item engineers actually argue about is tokens. Every move a coding agent makes (reading a file, running a test, replying "Sure, happy to help!") has a price tag attached.
Buzz around
The dev community has been buzzing about a few repos lately, all tackling the same problem: do the same work, spend fewer tokens. What's interesting is that each one attacks it from a totally different angle — like three different ways to cut a grocery bill: buy less, waste less, and stop paying for the gift wrap.
How to spend less?
rtk — github.com/rtk-ai/rtk
The "stop paying for noise" layer. It sits between your agent (Claude Code, Copilot, Cursor, etc.) and your terminal. It compresses the output of everyday dev commands — git status, test runs, docker ps, build logs — before any of it reaches the model's context. Most CLI output is boilerplate the model never needed in the first place; the project claims 60-90% savings on routine commands as a result.caveman — github.com/JuliusBrussee/caveman
Flips the problem around: instead of compressing what goes in, it compresses what comes out. It's a skill that makes your agent answer in short, fragment-heavy sentences instead of polite paragraphs — same technical content, way fewer words. It reports roughly 65% fewer output tokens while maintaining accuracy and has a side feature that compresses memory/context files (like CLAUDE.md), so every new session starts smaller, too.
⚠️ One caveat worth noting: output compression works well for chat-style Q&A, but use it carefully on long multi-step agent runs. The model's own previous answers carry reasoning forward between steps — compress those too aggressively and it can quietly lose the thread by step 6 or 7 with no obvious error. Input compression (rtk) doesn't have this problem since you're removing noise the model never needed. Output compression removes scaffolding it was actually using.
- superpowers — github.com/obra/superpowers Doesn't compress anything directly — it goes after the most expensive token sink of all: waste. Disorganized agent sessions burn tokens re-explaining context, wandering down the wrong implementation path, and redoing work nobody planned properly. Superpowers is a structured workflow (brainstorm → plan → test-first build → isolated subagent execution → review) that keeps the agent on-task and hands work off to fresh subagents so the main conversation doesn't balloon. Less backtracking, fewer tokens paid for twice.
Don't put it in the cart at all
Before compressing anything, scope what gets injected at session start — rules files, memory files, giant CLAUDE.md dumps. A well-trimmed session start usually beats any compression trick applied after the fact.
Wrapping up
Put together: one shrinks what comes in, one shrinks what goes out, and one stops you from paying for the same work twice. Three different layers of the same economy.
Funny thing — a year ago we were all measuring AI cost in "API calls." Now we're tuning prose style for token efficiency. The grind never stops; it just changes units.
What else have you used?
My Other Blogs:
- Personal Agentic AI Assistant - Architecture
- Openclaw Personal AI Assistant Complete Series
- “Skills” in Claude Aren’t About Prompts — They’re About Context Design
- Practical Tips When Working with AI Coding Assistants
- Trying MCP for the First Time — What Stood Out
- Subagents: The Building Block of Agentic AI
Top comments (4)
The three layers are not equally safe, and I think that ordering matters more than the percentages. Compressing what goes IN (the rtk layer) is behavior-neutral: the model never needed 40 lines of docker ps boilerplate to reason correctly. Compressing what comes OUT changes how the model talks to itself. On long multi-file refactors I have seen terse-output styles quietly degrade step 7 because the plan the agent was following partly lived in its own verbose intermediate answers. Same technical content per message, but less scaffolding carried forward between messages.
So my rule of thumb: input-side compression always on, output-side compression for chat-style Q&A but off for multi-step agent runs, workflow structure always. There is also a fourth layer your grocery metaphor suggests: do not put it in the cart at all. Scoping what gets injected at session start (rules, memory files, giant CLAUDE.md) usually beats compressing it after the fact.
The scaffolding degradation on multi-step runs is a good call out — output compression as a quiet reasoning tax rather than a clean trade-off. Curious what your trigger is for knowing when a task is 'multi-step enough' to turn it off. Is it just task length, or do you watch for something specific like plan dependencies?
Not length - data dependencies. The trigger is whether a later step consumes an earlier step's output verbatim. If step 4 needs exact identifiers produced at step 2 (file paths, symbol names, generated IDs, error strings), compression between them is a correctness risk, because the paraphrase is lossy in exactly the fields that must round-trip. If later steps only need the gist (a decision, a summary of findings), compress freely. So the practical check is on the plan shape: artifacts referenced downstream = keep verbatim within that chain; independent checklist items = compress at will. One habit that softens the whole tradeoff: treat compressed recall as a hint, not a source - when a step depends on an exact value, re-read it from disk instead of trusting what survived compression.
The artifact vs checklist distinction is a cleaner mental model than anything I had going in. And 'hint not a source' is going straight into how I think about this; context window as a cache that can go stale is exactly the right way to frame it.