Open-Model Coding Agent Blueprint

Your team has probably run the pilot by now. A coding assistant fixed in minutes a bug that had sat in the backlog for a month, and everyone agreed this changes things. Then the second week arrived, with harder questions. What did that fix actually cost? Who decided the work could touch those files? And who checked the answer, beyond the assistant saying it was done?

Open models have moved the ground under those questions. Models you can rent by the call, served by providers like Baseten, now do serious coding work at a fraction of frontier prices. The price of a token stopped being the interesting number. What decides whether this works in a real engineering organisation is governance and unit economics: who approved the work, how the result was proven, and what a finished task costs, failures counted too.

This open blueprint, the Open-Model Coding Agent, is our answer built as working software. It takes scoped work orders, runs them through a plan a person approves, does the work in isolation, and returns a proposed change with the evidence attached. The model inside is the current DeepSeek model the blueprint is built with, served by Baseten. Nothing about the arrangement depends on that model being right forever. That is rather the point.

Work arrives as an order, not a chat

Every job enters as a work order: a plain-language description of the task, the codebase it targets, and an approved list of the files the work may touch. Scope is a decision a person makes up front, instead of a surprise discovered afterwards in a sprawling diff.

The model then drafts a plan: an ordered set of steps, each saying what it intends to do, which files it touches, and which checks it expects to run. A person approves or rejects it, on the record. No approval, no work. If the codebase moves inside the approved scope after approval, the plan goes stale, and no run starts until a fresh plan is drawn against the code as it stands. Changing an approved plan means a new version, with its own approval; the old one never quietly stretches.

The work happens in a room with no keys in it

The model works on an isolated copy of the codebase, and can only change files inside the approved scope. Attempts outside it are refused and recorded, so the trail shows the attempt, not just the outcome. The workspace carries none of the team’s credentials. The model can run the checks the plan names, and nothing else.

Each order works against set budgets: how many model calls it may spend, how much usage, how much working time. A run that hits its ceiling stops and says which ceiling it hit. Work interrupted mid-task, say by a provider outage, leaves a checkpoint behind. It resumes only if the plan, the codebase, and the half-finished work still match what was approved. If the ground moved, it restarts honestly rather than papering over the difference.

Passing its own tests proves nothing

Here is the habit we would defend hardest. The agent’s own checks during the work are its scratch paper. They are never the verdict.

When the model finishes, its proposed change is applied to a fresh, untouched copy of the codebase and graded there, where a change that merely looks right fails out loud. And once the visible checks pass, a second set the agent never saw while working is applied too. A fix that has learned the examples instead of the problem is a familiar failure in this field; it should be caught by design, not by luck.

Passing tests leaves one question open: is this the change that was asked for? A second, colder read compares the finished change against the approved plan and the original request. It flags work on code nobody named, figures that appear in the change but nowhere in the request, and new public surface nobody asked for. Serious flags block acceptance until a reviewer answers them on the record. The reviewer can overrule the challenge. They cannot make it disappear.

That picture is drawn from a real recorded run: a stock-reservation defect, where the system could promise more stock than it actually held. The model drafted the plan, took nine steps, and produced a change confined to the one file in scope. The independent re-check passed on both sets of checks. The whole task, planning and work together, came to eight model calls and a recorded cost of $0.00281619, less than a third of a cent.

One run proves little, and we would not ask you to take it as a rate card. What it proves is that the accounting exists: every call priced, the failures kept in the count, the cost of a finished task stated instead of implied.

The number that matters is per finished task

Cost per token is the wrong unit for a buying decision, because tokens are an ingredient. The measure a budget holder needs is cost per successful task: all of a model’s spend, the failed attempts and the interrupted runs included, divided by the tasks that passed independent verification. A cheap model that needs three attempts and a senior reviewer’s hour is not cheap. An expensive one that lands verified work first time might be.

So the blueprint keeps a governed price book, prices every call against it, and reports that per-task figure per model. Prices the team has not verified stay blank rather than guessed — a small discipline, until you watch a dashboard built on invented numbers.

A new model has to earn the job

Swapping the model behind all this is treated as what it is: a promotion decision, with evidence. The benchmark suite is split in two: one part for tuning, where a candidate’s behaviour can be studied, and one part held back, untouched, reserved for judgement. A candidate is scored on the worst of repeated runs over that held-back set, not its best day, because one good run is weather and the worst of three is closer to a promise. Promotion needs that record, current against the suite as it stands, judged by someone who did not run the evaluation, with no regression against the model doing the work now. Rollback is a recorded act too, so a bad promotion is a bad afternoon, not a bad quarter.

The team’s written guidance to the agent is governed the same way: a house method is published only after it has been measured against the work, by someone other than its author. Untested advice is just prose with confidence.

In serious deployments, acceptance itself takes two people. Exporting a finished change, and promoting a model, each need two different people, neither of them the person who requested the work or approved its plan. The first decision waits, recorded, until the second lands. It slows the happy path by minutes, and makes the unhappy path much harder to walk by accident.

Where this stops

Honest limits. The benchmark suite is small, six tasks, and it earns authority only as a team grows it from its own finished work. The isolation is confinement by construction, separate copies and enforced scope, not a hardened security boundary. The names on decisions are recorded rather than proven by sign-in; a deployment exposed beyond a trusted team needs authentication in front of it. None of this removes the reviewer. It removes the reviewer’s excuses: plan, evidence, challenges, and cost sit on one record when they decide.

Open models made the labour cheap. The scarce things now are approval, proof, and honest accounting, and those are engineering decisions, not model features.

Work with us

If your team is weighing open models and the open questions are the ones above, who approves, who checks, what a finished task costs, start with Trida AI’s intake: a few questions about your codebase and how your team reviews work, then a conversation with the founders and engineers who would build it with you.

Get the Code on GitHub: github.com/tridaai/blueprint-open-model-coding-agent