Muaaz K.
← All posts

Cheap Agent: how I made my Claude plan last 2.2–2.7x longer

Published · 16 min read

Cheap Agent: Opus plans, a cheap model types, plain code checks the work.

I have been working with Claude for a really long time (Aug 2024 , the copy pasting era lol) and alwaya have loved Opus and it's ability to think about problem and then provide options , overall the thinking and planning ability of Opus/Fable is something that no other model can tops

But From the start of Agentic Era I kept hitting my Opus limit, and most of it was going on typing: reading files, writing boilerplate, re-running tests , something that very cheap model can do very well as well but never got time to make this Framework/workflow properly

Cheap Agent is a free, open-source plugin for Claude Code. Opus keeps doing the thinking, a cheap model (DeepSeek by default, on your own key, for cents) does the reading and the typing, and plain code checks the work before anything lands in your project.

On SWE-bench Verified it cut my Opus token use by 55–63%, so the Claude plan I already pay for lasts about 2.2–2.7x as long. Below is the whole story: why I built it, how it works step by step, why it isn't "just a subagent", how it compares to T3 Code, and where it loses.

Key takeaways

  • Cheap Agent is a free, MIT-licensed Claude Code plugin. Opus plans, a cheap model (DeepSeek V4.1 Flash by default) reads and writes the code, and plain code runs the tests.
  • On SWE-bench Verified it used 55–63% fewer Opus tokens, so a Claude plan lasts about 2.2–2.7x as long.
  • The cheap model runs on your own API key, so its tokens never touch your Claude plan. One feature add cost $0.005.
  • Nothing lands unless the tests pass when Cheap Agent runs them itself, and the new test has to fail without the fix.
  • It has limits. It's slower (real bugs took roughly 2x the wall-clock time), and Opus alone still does a bit better on the very hardest bugs.

Where does your Claude plan actually go?

Most of your Opus tokens go to reading files and typing code, not to thinking.

If you're on a Claude plan, you have a usage limit: a rolling 5-hour window and a weekly cap. Hit either one and you wait. A token is a small chunk of text (a word, or a piece of one). Everything Claude reads or writes is counted in tokens, and every token comes out of that limit.

Opus is the strongest model, and it burns through the limit fastest. Everyone knows that part.

What bothered me was what those tokens were spent on. When you ask Claude Code to fix a bug, most of them go to opening files, reading them, searching, opening more files, and then typing out the change. The actual decision ("the bug is in the coupon logic, and here's the fix") is a tiny slice of the bill. You're paying architect rates for someone to carry bricks.

Four months of doing it by hand

For about four months before I wrote any of this, I ran the same idea by hand. Opus planned the change in one window, a cheap model wrote the code in another, and I sat in the middle copying the plan over, kicking off each step, and copying the result back.

It worked, and it was annoying. The window-switching and the "ok, now do step 3" babysitting got old fast, and I kept thinking the glue should be a tool, not me.

I made the first commit on 2026-10-15. It was just for me, and I had no plan to open source it. The repo went public on 2026-10-28, which is why it looks newer than its history.

I made it public because of the people I kept meeting. I'm a software engineer from Pakistan, and I've met a lot of students, mostly in developing countries, who want Opus for hard problems and can't afford $100 a month. The README is blunt about the goal: get $200-plan usage out of the $100 plan, and $50–70 worth out of the $20 plan, with a few dollars of DeepSeek doing the typing. It won't make Opus ten times cheaper, but stretching the plan you already pay for is something.

The cast: an architect, a builder and an inspector

The easiest way to hold the whole design in your head is to picture a small construction crew.

Four cards: the architect (Opus, billed to your Claude plan), the builder (a cheap model, billed to your own API key in cents), the inspector (Cheap Agent itself, plain code, uses no tokens) and a standby (Sonnet, only when the builder fails).

The architect is Opus, running inside Claude Code like always. It plans the change and decides what "done" means, and it leaves the file reading to the builder.

The builder is a cheap model. By default that's DeepSeek V4.1 Flash, which lists at about $0.15 per million input tokens and $0.60 per million output tokens. It reads the codebase, writes the test and writes the code change. It runs inside OpenCode, an open-source coding agent that Cheap Agent bundles at a pinned version, on your own API key from OpenRouter, DeepSeek, OpenCode Go or Command Code. Gemini 3.8 Flash and more worker options are being added now.

An API key is a password-like string a provider gives you, so your tools can call their models and get billed per use. You put a few dollars on it and that's it.

The inspector is Cheap Agent itself, and this is the part people miss. It isn't a model. It's plain code that runs the tests, reads the exit code, and decides whether the builder's work is allowed to land. It uses no tokens at all.

The standby is Sonnet. It only shows up when the builder fails a step, and then it finishes that step instead of Opus.

Under the hood, Cheap Agent is an MCP server plus a Claude Code plugin. MCP (Model Context Protocol) is a standard way to give Claude Code new tools; modelcontextprotocol.io has the details. Cheap Agent gives Claude two of them, and everything else happens behind these two:

  • research: the cheap model reads the codebase and answers with file:line references, so Opus reads three lines instead of ten files.
  • delegate: the cheap model makes a code change and has to prove it with a test.

How does Cheap Agent work, step by step?

Opus writes the task, a cheap model does it in a private copy of your project, Cheap Agent runs the tests itself, and only passing work lands. That's the one-line version. Now let's follow one real request through the whole crew, from the moment you type it to the moment it lands in your project: "fix the cart total when a coupon is applied."

Eight steps: you ask, Opus writes a task with a done-when command, Cheap Agent makes a private git worktree, the cheap model writes a failing test and fixes it, Cheap Agent runs the checks itself, removes the fix to prove the test fails, lands the change uncommitted, and Opus reads about ten lines. A red path shows retries, a stronger cheap model, then Sonnet.

Step 1: You talk to the architect

You type "fix the cart total when a coupon is applied" into Claude Code, exactly like you always do. Nothing new to learn.

Opus reads your request, but Cheap Agent has already told it the house rules: don't open the source files yourself, send every code change to delegate. That sounds strict, and it is on purpose. Every file Opus reads costs your plan tokens. A 500-line file read by Opus is expensive. The same file read by DeepSeek costs a fraction of a cent.

Step 2: The builder scouts the site (research)

Opus doesn't know where the cart code lives yet, so it calls research: "where is the cart total calculated?"

The cheap model goes off, opens ten files, and comes back with a short answer and line numbers, something like "src/cart.ts:42, the coupon is applied in src/coupon.ts:10." Opus reads three lines instead of ten files. That's the first big saving.

Step 3: The architect writes the work order (delegate)

Now Opus writes a short task. For bigger work it writes a small plan file with steps, and each step looks like this:

## 1 Coupon total
files: src/cart.ts, test/cart.test.ts
do: apply the coupon before tax, not after
done-when: `npm test -- cart`

The last line is the important one. The text in backticks after done-when is a command that must succeed. So "done" is decided by a test, not by the builder saying "I'm done." Each step is also kept to one change, so nothing gets lost in a giant to-do list.

Before any work starts, the inspector checks the paperwork: is the plan well formed, did a human give consent for this repo, and is there budget left?

Step 4: A photocopy of your house (the worktree)

This is my favourite trick. The builder never touches your real project.

Cheap Agent makes a git worktree, which is a second working copy of your repository in its own folder. It copies your exact current state, not just your last commit: your uncommitted changes and new files come along too, and big dependency folders like node_modules are linked instead of copied.

Think of it like this: the builder works on a perfect photocopy of your blueprints in another room. If they spill coffee on it, your originals are fine.

Step 5: The builder works, with handcuffs on

The cheap model runs inside OpenCode, with strict rules:

  • it can't read .env files, where your secrets usually live;
  • it can't commit or push;
  • it has caps on turns, time and cost, so it can't run away with your money.

Inside those walls, it works in a fixed order:

  1. Write a test that fails, proving the bug exists ("a 10% coupon on $100 should total $90" fails today).
  2. Fix the code.
  3. Make the test pass.
  4. Report back with a summary and which command proves the bug existed.

Step 6: The inspector doesn't trust anyone 🕵️

The builder says "done, tests pass!" Cheap Agent shrugs and runs the done-when command itself, then looks at the exit code.

This matters because AI models sometimes say tests pass when they don't. Code doesn't lie. If the check fails, the builder gets the error and tries again. If it keeps failing, the step goes once to a stronger cheap model.

Step 7: The lie detector (the repro check) 🔍

A test that passes proves nothing if it would have passed anyway. Imagine the builder writes a test that checks 1 + 1 === 2. It passes, and it's useless.

So Cheap Agent does a magic trick:

  1. Run the test with the fix. It must pass. ✅
  2. Hide the fix, keep only the new test, and run it again. It must fail. ❌
  3. Put the fix back.

If the test fails without the fix and passes with it, that's real proof the test catches the bug. If it passes both ways, the result is marked unverified with a warning, so nobody mistakes it for proof. Someone on Reddit liked this idea enough to credit it and automate it in their own setup.

The repro check in two runs. Run 1: the builder's fix and the new test, and the test passes. Run 2: the fix is removed but the same test is kept, and the test must fail. If it fails, the test is proven to catch the bug; if it still passes, the result is marked unverified with a warning.

Step 8: Moving in (landing the change)

Cheap Agent takes the diff, the list of every line that changed, and applies it to your real project, uncommitted. You'll see it in git status like changes you made yourself, and you decide whether to commit. Then the photocopy room is cleaned up.

If you edited the same lines in the meantime, you get a CONFLICT result instead of a half-merged mess.

Step 9: The ten-line report 📋

Opus doesn't read the work. It gets a tiny report, and the first word is the verdict:

Word What it means
OK Done, tested and landed.
PARTIAL Some of it is done; it lists what's missing.
FAIL It didn't work; here's the error and what was tried.
BLOCKED The builder has a question for you.
BUDGET / TIMEOUT / CONSENT Something outside the code stopped it.

Opus reads about ten lines instead of the whole diff. That's the second big saving.

Step 10: Stopping the architect from double-checking 🙅

Opus loves to double-check: re-run the tests, re-read the diff. After an OK that burns tokens for nothing, because the inspector already checked. So Cheap Agent installs a hook, a small script Claude Code runs before each tool call, and it blocks those re-checks.

And on a FAIL, Opus doesn't pick up the keyboard either. The step goes to a Sonnet helper, the standby from the cast, which finishes it.

The whole thing in one picture

You ──▶ Opus (your Claude plan: only plans and ten-line reports)
          │
          ├──▶ research ─▶ cheap model reads files     (cents, your API key)
          └──▶ delegate ─▶ cheap model writes code     (cents, your API key)
                             ├─ Cheap Agent runs the tests   (free, plain code)
                             └─ still failing? ─▶ Sonnet     (rare)

That's where the 55–63% fewer Opus tokens come from: Opus stops reading and typing, and only thinks.

The thing I tried and deleted

Early on I had Opus review every diff the builder produced. It felt responsible. It also cost about 3x the tokens and caught nothing the tests hadn't already caught, so I removed it. Now the tests plus the repro check are the gate, and you still review the diff yourself before you commit, same as any other change.

Why isn't Cheap Agent just a subagent?

Because a subagent still spends your Claude plan, and Cheap Agent's worker doesn't. It's the question I get most, so here's the long answer.

A subagent is a helper Claude that the main Claude in Claude Code can spin up to do a side task. You can even tell it which model to use. So "make a Haiku subagent do the reading" sounds like the same idea.

Left: a Claude Code subagent sits in the same box as Opus, labelled your Claude plan, so both drain the same pot. Right: with Cheap Agent, Opus is in the Claude plan box and the worker is in a separate box labelled your own API key, billed in cents.

Three things are different, and the first one is what matters for your bill.

Where the tokens are billed. Claude Code subagents run on Claude models (Haiku, Sonnet or Opus), so they draw from the same plan limit: the same 5-hour window and the same weekly cap. Cheap Agent's worker runs on a separate API key, so its tokens never touch your Claude plan. In the feature-add benchmark, the cheap model's whole bill was $0.005.

How the result is checked. A subagent reports back in its own words, and the parent Claude very often re-reads the files to double-check, which spends the tokens you were trying to save. Cheap Agent's result is checked by code: tests it runs itself, plus the fail-without-fix check. It lands as a real diff from an isolated copy, and the hook stops Opus from re-checking an OK.

Where it works. A subagent works in your actual checkout. The builder works in its own git worktree, and only work that passed the checks comes across.

The "Haiku reads, Sonnet writes" line people put in their CLAUDE.md still draws from the same token pot. A head-to-head benchmark against that setup is planned, but I haven't done it yet. When I have the numbers, I'll publish them either way.

The other shortcuts people suggest

Each of these works. Each one also gives something up:

Setup Who plans Who pays for the coding tokens The catch
Subagent, or "Haiku reads, Sonnet writes" in CLAUDE.md Opus Your Claude plan Same 5-hour window and weekly cap
Claude Code pointed at DeepSeek DeepSeek Your DeepSeek key You lose Opus as the brain
DeepSeek called from a Bash script Opus Your own API key You glue the copy, the tests and the verdict together yourself
Cheap Agent Opus Your own API key, in cents Slower, and Opus alone is a bit better on the very hardest bugs

"Just point Claude Code at DeepSeek." You can, with ANTHROPIC_BASE_URL, and it works. But then the whole session runs on DeepSeek, planning included, and you lose Opus as the brain. Cheap Agent exists to keep both: Opus for the decisions, DeepSeek for the typing.

"Just call DeepSeek from a Bash script." That works too. It's literally how I ran it by hand for four months. MCP is only the plumbing. What you get from Cheap Agent is the pipeline around the call: the isolated copy, tests run by code instead of by the model, the repro check, the ten-line verdict, and the hook that stops the re-read. MCP also handles minute-long jobs, with progress updates and questions back to you, much better than a single Bash call that blocks.

"Cheap models write bad code." It's a fair worry, and I have two answers.

First, the pipeline assumes the builder might be wrong. That's why code runs the tests, why the fix gets removed to prove the test bites, and why a failing step escalates to a stronger model instead of landing. Bad work doesn't reach your project; it comes back as FAIL.

Second, the gap is smaller than people think. Bito ran an outside benchmark of long agentic coding sessions:

Bar chart of score and cost per session from Bito's benchmark: DeepSeek V4.1 Flash 77% at $0.14, Sonnet 5.5 77% at $1.28, Haiku 5.5 76% at $0.69, Opus 5.5 87% with no cost shown.

DeepSeek V4.1 Flash scored 77% at $0.14 per session. Sonnet 5.5 scored the same 77% at $1.28. Haiku 5.5 got 76% at $0.69. Opus 5.5 scored 87%, clearly ahead, and that's exactly why Opus keeps the architect job.

How much does Cheap Agent save? The SWE-bench numbers

On SWE-bench Verified, Cheap Agent used 55–63% fewer Opus tokens, and it solved the everyday bugs just as often.

SWE-bench Verified is a set of real bugs from real open-source projects, graded by the official harness. That means a fixed script decides pass or fail, not a person or a model.

Test setup: Claude Code with Opus 5.5, once on its own and once with Cheap Agent. For the median, I did 3 full runs of 24 bugs, with a fresh session each time.

Bar chart of Opus tokens: adding a feature 154k alone vs 57k with Cheap Agent (63% less); 7 everyday bug fixes 1.6M vs 655k (59% less); 9 of the hardest bugs 3.0M vs 1.3M (55% less). Median per bug over three runs of 24: 214k vs 87k.
  • Adding a feature: 154k Opus tokens alone vs 57k with Cheap Agent, 63% less. Both versions pass all the tests. The cheap model's bill was $0.005.
  • 7 everyday bug fixes: 1.6M vs 655k, 59% less. 7 of 7 solved both ways.
  • 9 of the hardest bugs: 3.0M vs 1.3M, 55% less. On these, Opus alone still does a bit better. More on that below.
  • Across 3 full runs of 24 bugs, fresh session each: the median was 214k Opus tokens per task alone (range 70k–865k) vs 87k with Cheap Agent (range 57k–808k).

I also built Cheap Agent with Cheap Agent. Native Windows support touched 36 files (+753 / −278 lines), and the cheap model wrote it in 30 jobs for $0.29 total.

How is Cheap Agent different from T3 Code?

T3 Code is a general remote control for your agents, and Cheap Agent is one narrow pipeline with a test gate. People ask about this one a lot too, so I want to be fair to it.

T3 Code, by Theo at ping.gg, is an open-source "agent harness control surface": web, desktop and mobile apps that let you drive the agents already on your machine (Claude Code, Codex, Cursor, Grok Build, OpenCode, Antigravity). It uses the subscriptions you already have, and it sells nothing. Its orchestrator is an MCP server that lets one agent create a sub-agent on any supported provider, wait for the result, cancel it, and read its thread. So yes, through T3, Opus can hand a prompt to another agent.

Two-column comparison: T3 Code is a general remote control for agents on your existing subscriptions; Cheap Agent is one narrow pipeline with a git worktree, a test gate run by code, and a ten-line verdict. T3 does better on UI, mobile and remote control. They can run together.

The difference is scope. Cheap Agent does one job in a strict way: the cheap model writes in its own copy, Cheap Agent runs the tests itself before anything lands, and Opus gets a ten-line verdict instead of reading the work. T3's docs don't describe a test gate or isolated copies. I'm only going by its docs here, so that's the whole claim.

T3 does several things better than I do. It has a polished UI, mobile and remote control, and it can use subscriptions you already pay for (like Codex on a ChatGPT plan) as the worker. Cheap Agent lives in your terminal and needs an API key with a few dollars on it.

In practice they aren't rivals. Claude Code with Cheap Agent runs fine inside T3 Code.

Where it loses

I'd rather you hear the downsides from me.

It's slower. Small tasks take about the same time, but real bugs took roughly 2x the wall-clock time in my benchmarks (wall-clock means the time you actually sit and wait). The very first job takes about two minutes while OpenCode sets itself up. Making it faster is what I'm working on now.

On the very hardest bugs, Opus alone still does a bit better. The 55% token saving on that set is real. But if you're chasing one nasty bug and care more about solving it than about your limit, let Opus do it directly. Cheap Agent is for the everyday work around it.

On tiny jobs there's nothing to save. A change of a few lines is already cheap, so the plumbing has nothing to win back.

Windows support is in beta. It was built with Cheap Agent itself, as I mentioned above, but expect rough edges, and please report them.

Try it in two commands

You need Claude Code, Node.js 20 or newer, and an API key with a few dollars on it. I recommend OpenRouter. A few dollars lasts hundreds of tasks.

npx cheap-agent

It walks you through picking a provider and pasting the key into the terminal. Then, in each project you want to use it in, run this once inside Claude Code:

/cheapag:allow

After that, ask Claude for changes the way you already do. It now has research and delegate as tools.

Cheap Agent is MIT licensed and free. The only cost is the cents the cheap model's API charges you. Since the repo went public, it got 1,000+ npm installs in the first week. The first outside pull request (a Command Code provider) was merged, a team at a Danish company started using it at work, and a few people on Reddit borrowed parts of the design. That last one made me happier than the install count.

If something breaks, or you want a provider that isn't there yet, open an issue or send a PR. You can add it yourself too; I'm more than happy to merge it.

FAQ

Is Cheap Agent free? Yes. It's free and open source under the MIT license. You only pay for the cheap model's API, which is a few cents per job.

Does Cheap Agent use up my Claude plan? Opus still plans, and that comes out of your plan. The cheap model runs on your own API key, so the reading and typing never touch your Claude plan.

Does my code get sent to another model? Only after you run /cheapag:allow in that project. That's a human saying "this repo's code may go to that model." Claude is never allowed to approve it itself.

Do I have to change how I use Claude Code? No. You ask for changes the same way. Claude gets two new tools, research and delegate, and changes land uncommitted, so you review the diff like any other.

Does it work on Windows? Yes, natively, but Windows support is still in beta.

About me

I'm Muaaz Khan, a software engineer from Pakistan. I work as a Forward Deployed Engineer, mostly in Go and Node. The easiest way to contact me is @realMaazy on X, and my code lives at muaaz9329 on GitHub.

This was built to help our dev community a bit. Everyone is going through a hard time, and if a student somewhere gets a few more hours of Opus out of the plan they can afford, that's the whole point.