AI coding tools are extraordinarily useful, and if you use Claude Code or Codex every day one problem shows up fast: your usage disappears sooner than it should. The obvious fix is to switch to a cheaper model. That helps, but it treats one symptom of a much bigger problem.
In practice, most AI coding cost is waste: oversized context, sessions that run for hours, reasoning nobody needed, too many active tools, enormous terminal dumps, the same repository scanned again and again, over-engineered code, and retries that were avoidable. None of that is the price of intelligence. It's the price of a sloppy workflow.
So the goal isn't to use AI less. It's to make the agent work more efficiently — the right context, the right model, the right tools, and the smallest amount of work needed to finish the task correctly. What follows is how I do that, in five parts, with both Claude Code and Codex.
Context
Where most of the money actually goes.
Technique 01Stop carrying old context into new tasks
The easiest way to burn tokens is to keep one session running across unrelated work. Fix authentication, build a pricing page, debug the database, change some animations, research Stripe. By the time you reach the last task, the agent may still be carrying everything before it — context that is no longer useful but still shapes every new turn.
Click through a session and watch it happen, then try each of the three recovery moves.
Add tasks in order, the way a real afternoon goes.
The habit is simple. Task finished, next task unrelated: /clear and start fresh. But don't clear blindly — sometimes you need a fresh context window while keeping the project state. That's what a handoff is for.
Technique 02Use handoffs instead of endless conversations
For long-running work, I externalize the important state before starting a new session. A short HANDOFF.md holds only what the next session needs to continue: the goal, the current state, decisions already made, files changed, known issues, failing tests, and the next action. Then the loop is: work, write the handoff, start fresh, read the handoff, continue.
That's far cheaper than dragging a multi-hour conversation forward, and it points at the larger idea:
Technique 03Use structured compaction
Compaction helps when you're still on the same task but the conversation has gotten too large. The mistake is compacting without telling the agent what matters. Don't just run /compact — give it preservation instructions: current goal, architecture decisions, files changed, unresolved bugs, test failures, constraints that must not change, next action.
The point isn't to make the context shorter. It's to keep the high-value state and drop the low-value history. Which gives you a clean three-way rule:
Nothing from before helps. Start with an empty window.
Keep the state, drop the transcript. Say what to preserve.
Write it down in the repo, then start clean and read it back.
Technique 04Use just-in-time context
This is the most important idea in the whole workflow. The common mistake is preloading everything before the agent starts: CLAUDE.md, the PRD, architecture docs, the database schema, twenty source files, design screenshots, MCP tools, skills, deployment docs. Then you ask it to fix the login redirect bug — and it needed three files.
Preloaded
Actually needed
The principle: context should be retrieved, not accumulated. Stop asking what the agent could possibly need across the whole project and ask what it needs for this specific task, right now. Identify the relevant context, load only that, execute, discard. It cuts cost, and it usually improves focus, because the model isn't being distracted by things that don't matter.
Technique 05Put your CLAUDE.md and AGENTS.md on a diet
Instruction files are useful, and they quietly become permanent overhead. A project starts with a 2 KB CLAUDE.md. Months later it's 30 KB of coding conventions, deployment instructions, design rules, database decisions, animation guidelines, old bugs, historical notes and API documentation — most of it irrelevant to whatever you're doing today, all of it loaded every time.
Keep only the always-needed material in the root file: tech stack, critical constraints, important commands, global conventions, and the things the agent must never do. Move the rest into docs/architecture.md, docs/database.md, docs/frontend.md, docs/motion.md, docs/deployment.md, and load them when they're relevant.
On larger projects, go further and use folder-level instructions — a CLAUDE.md at the root, another in /frontend/, another in /backend/, another in /agents/. Frontend rules stay out of backend work and vice versa. It's just-in-time context applied to your project instructions.
Technique 06Build JIT skills
The same problem hits reusable skills. A skill shouldn't be another giant instruction dump. Instead of an 8,000-line SKILL.md, write a small routing file and move the depth into references: references/api.md, references/design.md, references/examples.md, references/troubleshooting.md.
The main skill only has to define three things: when to use it, the workflow, and which reference to load next. The agent pulls the deeper material when it actually needs it. That gives you JIT skills instead of always-on skills — which matters a lot once your setup has dozens of specialized capabilities.
Technique 07Map the repo before scanning the repo
Large codebases are expensive to re-understand. Left to itself, an agent will list files, grep, read ten files, search again, read fifteen more, trace dependencies — and then do something similar next session. A short map in the repo cuts most of that.
Intelligence
Buying only as much thinking as the task needs.
Technique 08Route models by task difficulty
Not every task deserves your most expensive model, and not every task deserves deep reasoning. Both are dials, and most people leave both pinned at maximum. Pick a task and see where it should land:
Don't use a bulldozer to open a refrigerator.
Technique 09Route reasoning, not just models
Model choice is one lever; reasoning effort is a separate one. Changing a border radius from 8px to 12px does not need deep reasoning, yet plenty of people leave high effort on permanently. Default to low for mechanical work, medium for normal coding, high for anything ambiguous or architectural — and escalate when the task turns out to be harder than it looked. Use escalation, not always-on intelligence.
Technique 10Batch related questions
Every extra turn re-carries conversation history. Asking "why does this rerender?", then "can the state be simplified?", then "will the fix break mobile?", then "what's the smallest safe change?" costs four times what one well-formed question costs.
Technique 11Rewind instead of correcting forward
You told the agent to use Supabase. Then you realized it should be Neon. If you just add another message, the conversation now contains both instructions — and the agent may already have built something on the wrong one. Where the environment supports it, edit or rewind to the point of the mistake instead.
Remove the bad branch rather than stacking corrections on top of it. It shrinks the context and, more importantly, removes the contradiction. In coding work contradiction is expensive, because it usually turns into retries.
Tools
Capability is not free just because it's available.
Technique 12Use MCP on demand
MCP is genuinely useful, but more servers don't automatically make a better agent. Each tool brings capabilities and metadata the agent may have to reason about. If your environment has GitHub, Figma, Notion, Supabase, a browser, Linear, Slack, Canva and analytics all connected, and today's job is fixing authentication, almost all of that is noise.
Think in terms of available tools ≠ active tools. For a coding task, GitHub and the database may be enough. For design work, Figma and a browser. Turn on capability when the task actually needs it.
Technique 13Consider CLI before MCP
If a service offers both a CLI and an MCP integration, ask whether the CLI is sufficient. The GitHub, Supabase and Vercel CLIs already handle deploys, project state, logs, resource creation and migrations — and a CLI is only invoked when you need it, rather than sitting in context.
Technique 14Give tool output a budget
This is the biggest hidden leak in coding agents. You run npm test, the terminal returns four thousand lines, and all of it goes into context — when 97 tests passed and 3 failed, and the agent only needed the three. Run the pipeline below on a real-sized test output.
Code
Every line you don't write is a line nobody pays to re-read.
Technique 15Prefer the smallest safe change
Coding agents love to over-engineer. You ask for one feature and get a new service, a new helper, a new abstraction, a new dependency, new config and new types. A more experienced instinct asks: can existing code solve this? Can something be deleted instead? Do we need another abstraction, another dependency? What's the smallest safe change?
Put it in the instruction file directly: prefer the smallest safe change, reuse existing code before creating new abstractions, avoid new dependencies unless necessary, don't refactor unrelated code, delete or simplify before adding. The saving compounds:
Technique 16Define scope before the agent starts
The most expensive prompt you can write is "improve my app." That's an open-ended research assignment: scan the repo, inspect the architecture, rewrite components, install dependencies, change styling, run tests, keep exploring. Give it a contract instead.
Technique 17Ask for concise agent communication
Verbose responses cost output tokens and your attention. Worse, when an answer is unclear you ask follow-ups, which creates more turns. A short communication contract fixes it: be concise, lead with the answer, don't restate my request, don't narrate obvious actions, and for coding tasks report problem, change, files, result.
Technique 18Turn screenshots into a reusable design spec
If you do UI work, screenshots become their own repeated context: screenshot, "make it more like this," screenshot, "change it again," screenshot. Do it once instead. Take the reference, have the agent extract the visual DNA — typography, spacing, grid, colors, radius, surface, motion, image treatment — and save it as design-system.md. Future tasks reference the small text file rather than re-uploading images. Expensive visual context becomes cheap compressed memory.
Quality
Where spending a little prevents spending a lot.
Technique 19Use cross-model review at expensive checkpoints
Running two models sounds more expensive. Sometimes it is. But after Claude finishes an authentication architecture, a database migration, a large refactor or an important agent workflow, asking Codex for an independent review is cheap insurance: find incorrect assumptions, architecture risks, regression risks, security concerns, unnecessary complexity — report findings only, don't rewrite anything yet.
A small review cost beats a large rebuild cost. Don't do it for a button color; do it at the decision points that would be painful to undo.
Technique 20Let tests and files carry the memory
The strongest long-term pattern is to stop relying on the conversation to remember anything. Let the project encode its own progress: tests, git history, HANDOFF.md, progress.md, architecture decision records, issue files, the repo map. A fresh agent can then recover state from the repository, which means you can start new sessions aggressively without losing continuity.
The TOKEN framework
All twenty techniques collapse into five moves. Tap each letter.
Clear between unrelated tasks, compact with preservation instructions, hand off to a fresh session when state must survive.
Retrieve context, don't accumulate it. Slim instruction files, JIT skills, a repo map instead of a repeated scan.
Route by difficulty on two dials — model and reasoning effort — and escalate only when the task earns it.
Activate MCP on demand, reach for a CLI first, and put every tool output through filter, cap, compress.
Smallest safe change, explicit scope and stop criteria, review at expensive checkpoints, memory in the repo.
Try it on your next session
Ten things you can change today. Tick them off as you set them up.
Setup
Per session
Final thought
The future of AI coding probably isn't better prompt engineering. It's context engineering and agent engineering. The strongest workflow isn't the one that gives the agent the most information — it's the one that gives it the right context, the right model, the right tool, the right scope, at the right time.
And when you get those right, something interesting happens: you use fewer tokens and get better results. The agent is less distracted. It explores less. It writes less unnecessary code. It makes fewer mistakes. You spend less time cleaning up after it.
That's a much better goal than trying to use less Claude. The real goal is to stop paying AI to do unnecessary work.
Starting music…