Open Models for Coding Agents

Teams use coding agents across the whole backlog now: lint warnings and formatting, docstrings and type hints, tests, one-line bug fixes, new features, refactors that touch a dozen files, and the bug nobody can reproduce. It’s easy to send all of it to one frontier coding agent, because that’s the one that can do everything. It works, until the rate limit kicks in on a busy afternoon right when someone needs the agent for the hard bug, and part of the quota went on sorting imports.

Teams keep asking me about GLM for coding, and in October the question got a real answer. At AI Engineer NYC, David Abitbol, who leads AI operations at Revolut, said they had moved about 2,000 engineers onto GLM served on 56 Nvidia B200s, at a blended 30 cents per million tokens. That’s roughly a tenth of what they had been paying Anthropic and OpenAI, and Claude Code and Codex are now the exceptions rather than the default. GLM is a large general-purpose open model in its own right, so Revolut’s argument is open weights on your own GPUs against a frontier API. Mine is a similar one, though not the same: most of a backlog doesn’t need a model that size either, so try a much smaller open model picked for the job, and let each task’s tests decide which work it can have. I wanted to see whether that holds up on something small enough to read in one sitting, so I built a small recipe in the SIE cookbook that tries to reproduce it on a made-up backlog of 15 issues.

I’ll start with why teams look at this, and what companies that have written about moving work to smaller models do. Then how I’d test the idea on a backlog, with the tests deciding which tasks can move, and what happened when I ran it, including where the open model got it wrong. I’ll finish with what I’d try next and how to run it yourself.

Why Teams Move Coding Work to Open Models

Frontier compute is costly. A coding agent is billed per token, and it rereads the files and the conversation on every turn. Paying that rate for a lint warning is like calling your most senior engineer to rename a variable. They’ll do it well. It’s still a strange use of the afternoon.

Frontier capacity is limited. Hosted APIs cap how much an organization can send per minute and per month; Anthropic’s rate limits are set per organization and per model, by usage tier. Every easy task you send there uses up quota the hard tasks need.

You want to decide when the model changes. A hosted model is whatever the provider serves under that name, until it’s retired. With open weights on your own deployment, you pin the exact model and it stays there until you change it. That cuts both ways, because when you do upgrade, every regression is yours to find. You can also fine-tune it on your own code and its merged pull requests, and end up with a model that knows your code’s conventions, which no hosted model will.

None of this means the frontier model should go. Some tasks need it, and the point of the exercise is to find out which ones.

What Companies Do With Narrow, Repeated Work

Revolut moved to a cheaper open model. The clearest published example of moving one repeated job down to a smaller model isn’t about coding at all. Cisco’s Splunk AI Assistant in Security now runs its summary skill on a custom-tuned Foundation-Sec-8B-1.1-Instruct, “replacing previous Llama‑3.1‑70B model calls” and “delivering better latency and more consistent results for this critical workflow” (February 2026). It’s the same move: one job the assistant does over and over (writing summaries) goes to a smaller model picked for it, and the large one is kept for what’s harder. The hub post has more companies doing the same, and Give Your Agent Small Open Models as Tools goes through how to divide an agent’s job between model sizes.

How I’d Test the Idea on a Backlog

Most of a backlog isn’t hard. Linting and formatting are rules a tool already knows. Docstrings, type hints and a bug with one obvious place to fix are small changes that a smaller model can often make, and a test tells you whether it worked. What’s left, the vague issue or the change that touches five files, is where the frontier model earns its price. Superlinked’s CEO Daniel Svonava made a similar case on a podcast, in Carve Off Tasks, Not Models: the unit you move is the task.

You could try to answer “which tasks can move?” from benchmarks or a model’s spec sheet. I’d rather ask each task directly: give it to the least expensive option that might do it, run its tests, and move it up only when they fail. The recipe has four levels, each cheaper than the one above it:

1. No model. If a deterministic tool does the job, it gets the job, and here that’s ruff for lint and formatting (free, instant, and it can’t make anything up).
2. An open model. Qwen3.8-27B on SIE, which at 27B is on the verge of large, but far smaller and cheaper than Opus. It isn’t a coding specialist; when I checked SIE Serverless on 7 and 8 Nov 2026, it and Qwen/Qwen3.5-4B were the only chat models there that answered tool calls.
3. The frontier model. Claude Opus 5.5, the model you’d otherwise send everything to.
4. A person. A task the frontier model can’t pass goes back with the last test output attached.

A small classifier reads each issue and picks where it starts, and a task it isn’t sure about starts at the frontier model. Python then tries each level in order. Some tasks also have checks the model never sees, the kind a team keeps back for CI, and those run after the task’s own tests pass. Inside a model level, the model works on a fresh copy of the code with five tools (list_files, read_file, write_file, run_tests and finish) until it says it’s done, and then Python runs the tests itself. In pseudocode (the recipe’s real code is longer and stricter):

LEVELS = [ruff, open_model, frontier_model]          # cheapest first

def solve(issue):
    start = router.pick_start(issue)                  # small classifier; unsure means frontier
    for level in LEVELS[start:]:
        copy = fresh_copy(repo)                       # every level starts clean
        level.work(copy, issue)                       # its "done" proves nothing
        if not run_tests(copy, issue.tests) and level.is_model:
            level.retry(copy, last_test_output)       # one more try, with the failure
        if run_tests(copy, issue.tests):              # Python decides
            ci = run_tests(copy, issue.ci_checks)     # checks the model never saw
            return review_queue.add(issue, diff(copy), level, ci)
    return back_to_person(issue, last_test_output)

So the recipe as a whole is a workflow: Python picks every level, in a fixed order. Only inside a model level is there an agent, the model picking its next tool call until it says it’s done.

A model saying “done” is the least useful signal you have, so no model gets a vote; Python puts the tests back as they were and runs them. And a person still reads every diff before it merges. A cheap model that gets the tests passing with wrong code saves nothing once a reviewer has to go find the mistake, so I’d only count a task as moved off the frontier model when the reviewer approves it. (If you’re wondering whether a job like this needs an agent at all, When to Use a Workflow and When to Use an Agent has the test I use.)

What Happened on a Made-Up Invoicing Library

The recipe runs 15 made-up issues against Ledgerline, a made-up invoicing library of about 100 lines (agentic/route_coding_tasks_to_open_models_first). Every task also goes to Claude alone, from a fresh copy with the same tools, so you can see what the routing saved.

On cost, starting each task at the cheapest level mostly held up on this backlog. The tests passed on all 15 tasks, both through the levels and with Claude alone. Through the levels, ruff did 2 tasks, the open model 9 and Claude 4, and a run cost $0.22 to $0.25 in all (Claude plus the SIE credits), against $0.57 to $0.61 for Claude alone, so about 40% of the cost, and it was a little quicker too. By my own rule above, though, only 7 of the open model’s 9 count as moved: two of its changes pass their tests and are wrong (more on those below), and a reviewer would send them back. Redoing those two on Claude would add a little to the 40%, so read it as a floor rather than the final number. The classifier itself cost 4 to 6 SIE credits a task, which is next to nothing.

Fifteen made-up tasks in a library that small aren’t a benchmark, though. Each file fits in one read and every issue says what to change. Real issues are vaguer and real code is bigger, and I’d expect the open model to fail more often there. And “cheaper” depends on which models you compare: on this mix of tokens, Claude Haiku 5.5’s list price works out cheaper than the 27B (and the 4B I tried first) on SIE Serverless. I haven’t tried Haiku as a coding level, so the comparison I can actually stand behind is the open model against Opus.

Pro-tip: the tests import the code the model wrote, so that code runs on your machine. The recipe stops a model writing anywhere outside ledgerline/, resets every other file before each test run and gives the tests no API keys. Run it in a container anyway.

Where the Open Model Got It Wrong

The worst failure was on the task that adds a discount on the whole invoice (T07), because nothing caught it. Along the way, the open model changed the default tax_rate from 0.20 to 20 and worked tax out as a percentage, and the task’s test passed. Every caller who passes a rate like 0.07 would now be charged 0.07% tax. It made the same mistake on all three runs, so at least it’s a mistake you’d find again.

Installments were the near miss. The issue asked to round each part down to the cent, and the open model rounded to the nearest cent instead. That happens to come out right for 120.01 in three parts, so the visible test passed, but 100.00 in seven parts came out as 100.03, and only the checks kept back for CI caught it.

So “the open model’s change passes the task’s tests” is only as strong as the tests. If they’re going to decide which tasks can move, they have to check the thing that matters (the tax rate a caller passes in, the rounding rule the issue states), and the reviewer should read the open model’s diffs with extra care.

The classifier was the other weak spot. I used fastino/GLiNER2.5-Decide to pick one of five kinds of task (style, docs, small fix, change or broad), and five loose kinds of coding task are a hard set of options for it. It was rarely sure, so three tasks the open model might well have done went straight to Claude because they scored under the 0.35 bar. It also called three tasks style, so ruff tried them first and couldn’t help, which is why the tax-rate task went through ruff before the open model. And one task, the amount parser with a dozen rules, outgrew the 8,192-token window SIE Serverless gives the open model and moved up to Claude.

I also started with the 4B Qwen as a level below the 27B, expecting it to be the cheap one. It cost more per token, needed more requests per task, and made the whole run slower and dearer, so I dropped it. The smallest model isn’t always the cheapest one to run.

What I’d Try Next

Have Claude review only the open model’s diffs. Claude reading just the diff would cost a cent or two a task, and the tax rate is the kind of mistake a review catches and tests don’t.

A better classifier. Every task ends with the level that passed it, so the recipe produces its own labels, and a classifier tuned on those should pick better than five generic kinds. Superlinked’s train-a-router example measures that idea.

A longer window and a fine-tuned open model. On SIE Cluster you can serve the 27B with a longer context, which the parser needed, and the same idea as the classifier works one level up, fine-tuning the open model on your own merged pull requests.

GLM-5.3-Flash as the open model. It’s the one teams ask me about, and the closest to what they use for coding. It’s in SIE’s compatibility matrix for SIE Cluster, but SIE Serverless answered “Generation route is unavailable for this deployment” when I tried it, so I haven’t run it yet. Swapping it in is one line in rules.yaml.

Run It Yourself

The easiest way to try this is on SIE Serverless, with no GPUs to manage. You need uv, an SIE API key and an ANTHROPIC_API_KEY:

git clone https://github.com/superlinked/cookbook && cd cookbook
cp .env.example .env   # set SIE_API_KEY and ANTHROPIC_API_KEY
cd agentic/route_coding_tasks_to_open_models_first
uv run recipe.py                 # all 15 tasks, routed and Claude alone
uv run recipe.py --task T12      # one task

The first run of the day can wait minutes while SIE Serverless starts a cold model. Each run writes a page per task with the diff, which level did it, what failed first and what it cost, which is also what your reviewer would read. If you want the open model on your own GPUs (or a longer window for it), the cookbook’s self-hosting guide has the setup.

Conclusion

On a small, made-up backlog, sending each task to the first level cheaper than Opus that passes its tests did the work for about 40% of what Opus alone cost, and 7 of the open model’s 9 changes would survive a reviewer. Whether that holds on your backlog depends on four things I’d answer before building a ladder like this: what checks the result and whether a model can fool it, which steps a plain tool can do, what’s the cheapest model that can do the rest with tools, and what a person still reads. I’d say every diff, because the tax rate got through.

If you try it on your own backlog, I’d love to hear which kinds of task moved and which ones stubbornly needed the big model. Until next time.