•4 min
Dev, AI
The vibe coding trap: 97% of AI-generated apps never ship
Forbes named it today. 92% of devs use AI coding tools daily, 46% of new code is AI-generated — and 97% of vibe-coded apps never make it to production.
Lire l'article→
Dev, AI
Alexandre··
10 Ways to Cut Your Token Bill by 5x (Copilot, Claude Code, Cursor)
Reading time: 15 min
Click to enlarge
Since June 1, 2026, GitHub Copilot charges per usage. 1 AI Credit = $0.01. A single exchange with Claude Opus 4.8 costs $25 per million output tokens. The same exchange with Haiku 4.5 costs $5. That is a 5x factor on the same task, depending on the model you pick (GitHub Docs).
On AlexWrites and Waku, I use a daily combo of 4 tools to cut my consumption: RTK to compress CLI outputs, codegraph to give the model structured context, a compact CLAUDE.md with proactive rules (I wrote about it here), and a model-per-task strategy. I also tried Caveman (a skill that forces the model to respond in ultra-short mode, GitHub), but I do not recommend it: the 60-75% reduction on output tokens comes at the cost of too much information loss. When the model answers in telegraphic mode, you lose critical context and end up asking more questions to compensate.
Let's break it down.
The problem: usage costs are exploding (and it is not slowing down)
A token is the billing unit for all language models. It is not a word: it is a text fragment of roughly 4 characters that the AI splits text into for processing. 750 words correspond to about 1,000 tokens. And every token going in or out of the context window has a price.
The context window of an LLM (Large Language Model, the language model powering your code assistant) is its working memory. It defaults to around 200,000 tokens, expandable to 1 million on some models. But beyond 60 to 70% fill, response quality drops. The model loses track, repeats itself, hallucinates. Researchers call this the "lost in the middle" problem (VS Code Blog, June 2026).
Every interaction mobilizes two token streams that add up. Input tokens are everything you send: your prompt, open files, conversation history, system instructions. Output tokens are what the model generates in return. And here is the trap: output tokens cost 4 to 8 times more than input tokens (CIO). On Claude Opus 4.8, that is $5 input vs $25 output per million tokens (Anthropic).
The consequences are threefold. Cost increases with every superfluous token sent or generated. Speed degrades proportionally to the volume of tokens processed, each additional millisecond of latency. And quality drops when the context window is saturated with irrelevant data (Anthropic, 2026 Agentic Coding Trends Report).
| Model | Input cost (1M tokens) | Output cost (1M tokens) | Output/Input ratio | Recommended use |
|---|---|---|---|---|
| Claude Opus 4.8 | $5 | $25 | x5 | Architecture, complex refactoring |
| Claude Sonnet 4.6 | $3 | $15 | x5 | Implementation, everyday debugging |
| Claude Haiku 4.5 | $1 | $5 | x5 | Tests, docs, simple tasks |
| Gemini 3 Flash | $0.60 | $3 | x5 | Reading, reformulation |
This pricing model shift caught many teams off guard. William Ogez from Carbon IT wrote a thorough article on the topic: "Maitriser la facturation GitHub Copilot". He details how the switch from "premium requests" to "AI Credits" forces companies to rethink their AI governance. Setting a global budget, defining usage profiles per team (power users vs capped lightweight profiles), setting up consumption alerts via the admin dashboard. On the enterprise side, it has become a real line item to manage. On the solo dev side, the same principles apply, but the levers are different: that is what the rest of this article covers.
Step 1: methodology (before installing anything)
Lever 1: pick the right model per task
On a single task, the cost gap between a premium model and a lightweight model can reach a 9x factor. The most effective strategy is not to reduce AI usage, it is to use the right model for each step of the work. This is the lever nobody uses and that pays off the most.
In practice, that means using Opus to write the spec or resolve a multi-file bug, then switching to Haiku or Sonnet to execute tasks one by one. This is what the GitHub documentation calls the "hybrid strategy" (GitHub Docs). The premium model reasons and decides. The lightweight model applies and executes.
| Task | Recommended model | Output cost | Why |
|---|---|---|---|
| Spec, architecture, complex debugging | Opus 4.8 | $25/M | Deep reasoning required |
| Implementation, plan execution | Sonnet 4.6 | $15/M | Good quality/cost ratio |
| Unit tests, docs, reformulation | Haiku 4.5 | $5/M | Simple execution, high volume |
| Code reading, summarization | Gemini 3 Flash | $3/M | Low-value-added tasks |
For Waku and my projects, I do exactly this with Claude Code every day. When I need to rethink a module's architecture, I launch an Opus session. When I need to generate 15 unit tests from an already-written spec, Haiku does the job in 3x fewer tokens. The gap over a workday is easily 40 to 60% of tokens saved, with zero quality loss on the produced code.
Lever 2: adjust the reasoning effort level. The model's effort level is the second reflex that matters. Claude Code and Copilot let you adjust reasoning intensity (low, medium, high, max). Leaving it on "high" permanently pushes the model to think longer and call more tools than necessary. The "medium" setting is enough for 80% of tasks and consumes significantly fewer tokens than "high" or "max". Mickey Gousset demonstrates this well in his video (3,900 views), where he measures the direct impact of effort level on consumption.
Lever 3: write before you code (spec-driven development)
Spec-driven development (SDD, a method that structures work into spec, plan, and tasks before letting the agent code) reduces costly back-and-forth and prevents the model from exploring the codebase without a clear direction. Fewer iterations = fewer tokens wasted on pointless exploration.
The process has 4 steps. First, you describe the what and the why in a short spec (Specify). Then, you provide the technical direction and constraints in a plan (Plan). Next, you break it down into short, testable tasks (Tasks). And finally, you hand each task to an appropriate model, often lighter than the one that wrote the plan (Implement). Key point: each step is reviewed and validated by the dev before moving to the next.
Comparison: with and without SDD
| Without SDD | With SDD | |
|---|---|---|
| Codebase exploration | Agent reads 10-15 files to understand context | Agent knows exactly which files to touch |
| Iterations | 3-5 clarification round-trips | 1 single pass, the spec is clear |
| Wasted tokens | Full context re-read on every iteration | Minimal, targeted context |
| Model used | Opus for the entire session | Opus for the spec, Haiku for execution |
| Estimated cost per feature | ~$3-5 | ~$1-2 |
Several open-source frameworks structure this approach. BMAD Method (50,700 GitHub stars) offers a complete agile workflow with specialized agents, from brief to implementation. Spec-Kit is the official GitHub toolkit for SDD in Copilot, with
/speckit.specify, /speckit.plan, and /speckit.tasks commands. And AI-Driven Dev Community gathers tools, prompts, and snippets for devs who use AI daily.The token benefit is direct. Without this structure, the agent explores unconstrained, reads files it does not need, asks clarification questions, backtracks. Each pointless iteration costs input tokens (full context re-read) and output tokens (abandoned generation). With SDD, the model knows exactly what to do from the first prompt. Nate Herk shows it well (258,000 views): structuring your requests before sending them is the most cost-effective hack of all.
This is exactly the workflow I use with Claude Code on Waku. I write a short spec in Opus, generate the plan, then execute each task in Haiku. Cost per feature dropped by half compared to the "I describe my need loosely and let the agent figure it out" approach.
Step 2: compression tools
Methodology reduces unnecessary tokens upstream. The tools below compress what gets through anyway.
Lever 4: compress CLI outputs with RTK
Click to enlarge
RTK (Rust Token Killer) is an open-source CLI proxy written in Rust that intercepts terminal command outputs before they reach the AI's context window. Measured result: 60 to 90% fewer tokens on common commands, with zero workflow changes. 71,400 GitHub stars in under 6 months (GitHub).
The problem is simple. When Claude Code runs a
git status, an npm test, or a docker ps, the raw output contains hundreds of lines of repetitive data, system headers, and messages that the model will never use to solve your task. All of this verbose output lands in the context window, takes up space, and dilutes the model's attention on what actually matters. Without guardrails, your AI agent is a curious intern with an unlimited credit card who reads the entire node_modules to understand a library.RTK acts as a smart filter between your terminal and the AI. The flow is simple: the model executes a command (git, npm, docker...), RTK intercepts the raw output (~2,000 tokens), applies its filters, and only returns the essentials (~200 tokens) into the context window. The model never sees the verbose output.
4 compression strategies: filtering (removing non-essential system data), grouping (aggregating similar elements), truncation (selectively keeping critical segments), deduplication (merging repeated lines with occurrence counters).
Before/after RTK comparison by command
| Command | Tokens without RTK | Tokens with RTK | Reduction |
|---|---|---|---|
cargo test (full suite) | ~4,500 | ~360 | 92% |
git status (monorepo) | ~1,200 | ~230 | 81% |
docker ps (10 containers) | ~800 | ~160 | 80% |
npm test (Jest, 50 tests) | ~3,200 | ~400 | 87% |
kubectl get pods | ~1,500 | ~200 | 87% |
| 30 min session (total) | ~118,000 | ~24,000 | 80% |
Sources: RTK Benchmarks, Medium. FuturMinds reproduced these results (25,000 views):
Installation takes two commands:
curl -fsSL https://rtk-ai.app/install.sh | sh rtk init --global
After restarting VS Code or your terminal, the hook fires automatically on 100+ commands (git, npm, cargo, Docker, Kubernetes, AWS...). You can track gains in real time with
rtk gain --graph, and rtk discover analyzes your history to find commands that could still be compressed.RTK does not cover everything. Other tools fill in the gaps for specific cases:
| Tool | Type | Claimed reduction | What it compresses |
|---|---|---|---|
| RTK | CLI proxy Rust | 60-90% | Outputs of 100+ shell commands |
| Snip | CLI proxy Go | 60-97% | Declarative YAML filters |
| Headroom | Proxy / lib / MCP | 40-95% | Tool outputs, logs, RAG chunks |
Be careful not to stack RTK and Snip together: they intercept the same category of traffic, and the combined gain is not proportional (Sogeti Labs).
Honestly, I have been using RTK on all my projects since April. Combined with the CLAUDE.md setup and hooks I had put in place (full details here), it is the combo that brought me from $6/day to under $2 on average on Waku.
Mes apps indie
Lever 5: give structured context with codegraph
Click to enlarge
Codegraph is an MCP server (Model Context Protocol, the open standard that connects AI agents to external data sources) that builds a knowledge graph of your codebase locally. Instead of letting the agent read entire files to understand the code, it provides structured context: symbols, imports, call graphs, architecture. Measured result: about 35% fewer tokens and 70% fewer tool calls (DeveloperDigest).
The problem codegraph solves is different from RTK. RTK compresses shell command outputs. Codegraph compresses the code context itself. When Claude Code needs to understand how a function is used in the project, without codegraph it will read the entire file, then its imports, then the files that call it. That can mean 10 to 15 opened files, thousands of ingested lines. With codegraph, it queries the graph via the
codegraph_context or codegraph_explore MCP tool and gets the structured answer directly, without ingesting raw content.Comparison: with and without codegraph on a multi-file refactor
| Without codegraph | With codegraph | |
|---|---|---|
| Files read by agent | 10-15 complete files | 3-4 targeted files |
| Tool calls (read, grep) | ~25 calls | ~8 calls |
| Tokens consumed | ~45,000 | ~29,000 |
| Reduction | baseline | ~35% |
| Response accuracy | Gets lost in context | Finds the right answer on the first try |
The tool is developed by Colby McHenry, distributed on npm as
@colbymchenry/codegraph, and runs entirely locally with tree-sitter (a universal code parser) for parsing and SQLite + FTS5 for indexing. It is compatible with Claude Code, Cursor, Codex, and any MCP client (BigHatGroup).I just installed it on the AlexWrites monorepo, where I am writing these lines. It is pretty impressive. On multi-file refactoring tasks, where the agent would usually have to read a dozen files to understand dependencies, it reads 3 or 4 and finds the right answer on the first try. The token savings are real, but what convinced me the most is the accuracy: the model no longer gets lost in thousands of lines of irrelevant context.
Codegraph vs AGENTS.md: why the graph wins
| AGENTS.md / copilot-instructions.md | Codegraph | |
|---|---|---|
| Updates | Manual (you have to remember to do it) | Automatic (file watcher, 2s debounce) |
| Coverage | What you thought to document | Entire indexed codebase |
| Staleness risk | High after every refactor | Zero (continuous re-indexing) |
| Token cost per session | Fixed (loaded every session) | On-demand (queried when needed) |
| Stale info = | Model following wrong instructions | Impossible (the graph reflects actual code) |
In my view, codegraph is more powerful than a well-written AGENTS.md, for one simple reason: a project documentation file, you have to maintain it by hand. Every refactor, every new module, every renamed function can make it stale. And a stale AGENTS.md is worse than no AGENTS.md at all, because the model will follow instructions that no longer match the real code. Codegraph updates itself automatically. Its native file watcher (FSEvents/inotify) monitors file changes and re-indexes continuously with a 2-second debounce (GitHub). You modify a function, the graph is up to date 2 seconds later. Zero manual maintenance (Sourcegraph).
Step 3: cache, sub-agents, and targeted context
Prompt caching (a mechanism that reuses identical context portions from one call to the next instead of charging them at full price) is the quietest and most powerful lever. Keeping a stable, compact context at the top of the conversation can achieve cache hit rates of 90 to 97%, which massively reduces the input token bill.
The principle is simple. On every exchange, the agent resends the full history to the model. If the beginning of that history does not change from one turn to the next (system instructions, CLAUDE.md, rules files), those tokens are billed at a reduced rate. Hence the importance of keeping these configuration files stable and compact. Beyond a few hundred lines, the marginal utility of your CLAUDE.md or AGENTS.md drops, but the cost remains on every session. On my setup, I reach a cache hit rate of 96.80% on Claude Opus 4.8: 27,467 tokens reused out of 28,375, only 908 uncached tokens (VS Code Blog).
| Lever | What it changes | Estimated impact |
|---|---|---|
| #6 Compact and stable CLAUDE.md | Maximizes prompt cache hit rate | 90-97% cache on input tokens |
| #7 New chat per feature | Avoids accumulated stale context | -20 to 30% tokens per session |
| #8 Sub-agents for research | Targeted summary instead of full raw context | -40 to 60% on reading tasks |
| #9 Selective MCP (disable unused ones) | Fewer tool descriptions in context | -5 to 15% system tokens |
| #10 Targeted context ("this file" vs "the whole repo") | Agent only reads what is needed | 5x to 10x factor on targeted tasks |
Lever 7: new chat per feature. Keeping stale context costs more than the cache saves. Each new task deserves a clean window.
Lever 8: sub-agents for research. Sub-agents work in their own context window and return a targeted summary instead of the full raw context. This is the pattern I describe in my article on AI code agent architecture: a lightweight agent reads and analyzes, the premium model synthesizes and decides.
Lever 9: selective MCP. Each loaded MCP server adds its tool descriptions to the context. If you are not doing quality reviews, disable SonarQube. If you are not touching the database, disable the PostgreSQL MCP. Fewer active MCPs = fewer system tokens per turn.
Lever 10: targeted context over broad scope. Provide the right file, the right class, or the right function directly. Never let the agent explore the entire repo unconstrained. It is the difference between "look at this file" and "search the whole project", and the token gap can easily reach a 10x factor. RoadsideCoder demonstrates this (2,700 views) with before/after measurements on Claude Code and Cursor:
Summary: all 10 levers in one table
| # | Lever | Category | Estimated reduction | Difficulty |
|---|---|---|---|---|
| 1 | Pick the right model per task | Methodology | 40-60% on overall cost | Easy |
| 2 | Adjust effort level (medium by default) | Methodology | 10-20% | Easy |
| 3 | Spec-driven development (SDD) | Methodology | 30-50% fewer iterations | Medium |
| 4 | RTK on CLI outputs | Tool | 60-90% on shell commands | Easy |
| 5 | Codegraph for structured context | Tool | ~35% tokens, 70% fewer calls | Medium |
| 6 | Compact and stable CLAUDE.md | Config | Better cache rate (90-97%) | Easy |
| 7 | New chat per feature | Habit | -20-30% stale context | Easy |
| 8 | Sub-agents for research | Architecture | -40-60% on reading tasks | Medium |
| 9 | Selective MCP | Config | -5-15% system tokens | Easy |
| 10 | Targeted context (file vs repo) | Habit | 5x to 10x factor on targeted tasks | Easy |
What this changes for us, indie devs
1. AI cost has become a line item to manage, not just a subscription
With per-usage billing, every session has a variable cost. Like cloud hosting, the best practice is to measure (with
/cost on Claude Code, rtk gain on RTK), set a daily budget, and optimize the most token-hungry items first. According to Anthropic, the observed average is $6/dev/day, with 90% of users under $12/day. If you are consistently above that, the sections above are for you.2. The real savings come from framing, not restriction
Not using AI to save tokens is like not driving to save gas. The lever is better framing: right model, right prompt structure, right context level. My sessions on Waku have been more productive since I implemented these 10 levers, not less. The produced code is better because the model focuses on the right files instead of drowning in useless context.
3. Compression tools are no longer optional
RTK at 71,000 stars in 6 months, codegraph as native MCP, the VS Code cache explorer: the token optimization ecosystem is becoming a standard. Not using them means accepting to pay 3 to 5x more for the same result.
Conclusion: the most efficient AI is the one that only reads what matters
Ten levers, one principle. The right question is not "how to spend fewer tokens". It is "how to feed the right tokens at the right time". A model that receives exactly the context it needs responds faster, more accurately, and for less. A model drowning in thousands of lines of logs, irrelevant files, and stale history will produce mediocre code, slowly, at a premium.
These tools are still young. RTK is 6 months old, codegraph is on version 1.1.0, BMAD Method evolves fast. The numbers I share in this article come from my measurements and public sources, but your context (project size, stack, usage frequency) will yield different results. The best advice I can give you is to install RTK and codegraph, measure your gains with
rtk gain and /cost, and form your own opinion. Numbers matter, but it is your feel for response quality that should guide your choices.The real optimization is not using AI less. It is giving it exactly what it needs, nothing more.
What about you, have you measured your token consumption? Are you using RTK or codegraph? Send me a message on Twitter/X or in the comments.
Alex
Key takeaways
- Picking the right model per task (Opus for the spec, Haiku for execution) cuts the bill by 40 to 60% with no quality loss
- RTK compresses CLI outputs by 60 to 90% automatically (71,400 GitHub stars), codegraph reduces code context by 35% via a structured MCP graph
- Prompt caching rewards stability: a compact, stable CLAUDE.md can reach 97% cache hit rate on input tokens
Related articles
•7 min
Dev, AI
How I cut my Claude Code token usage in half
Not with /compact. With what I set up BEFORE opening a session. CLAUDE.md, hooks, and proactive rules: my setup to cut token consumption by 40 to 60%.
Lire l'article→
•14 min
Dev, AI
AI agents don't code for you: they orchestrate. Here's how it actually works
Agentic loop, hierarchical subagents, MCP protocol: a technical deep dive into code agent architecture and lessons learned after 8 months of solo dev with Claude Code.
Lire l'article→
Comments
Comments
Got a take on this article?
Create a free account in 10 seconds to comment, like, and get the next articles straight to your inbox.
Don't have an account yet?