Built to be the most efficient harness on the market.

Ultron finishes the same task on a fraction of the model calls. Not by picking a smaller model, but by never spending one on work a script, a workflow or the cache can finish correctly.

3.2
AI calls per task
6.1x
inference cut
78%
work offloaded
83%
cache hit
$0.011
cost per task
$4.15
to serve a heavy seat
The trajectory. Inference cost per task against daily throughput, over 8 nightly runs on the same workload.

Why the others cannot follow.

Claude Code, Codex and Gemini CLI are good harnesses. They are also shipped, free, by the three companies that sell the tokens those harnesses spend. That single fact decides which optimisations each of us is even able to consider.

Their economics
Sold by the token.

The harness is given away; the tokens are the product. Every step moved off the model is revenue removed from the company that wrote it. They all cache aggressively, because a cheaper turn sells more turns. What none of them do is remove the turn: the loop still asks the model to decide what comes next, still grows its context as it goes, and still reasons about work a function could have finished.

None of this is bad faith, and caching proves it: they will happily make a call cheaper. Making the call not happen is the one move that shows up as lost revenue rather than a better product, so it sits permanently at the bottom of the list.

Ours
Sold by the month.

Ultron charges a subscription, so inference is a cost line rather than the product. Every step that runs as a script, a workflow or a cache hit is margin we keep rather than revenue we forfeit. The incentive points at fewer rounds, smaller context, and as much work as possible never reaching a paid model at all.

The same engineering that would be self-harm for an inference business is simply the correct move for a subscription one. We are not solving a harder problem than they are. We are solving the one they are structurally not allowed to solve.

And the layer above them runs on subsidy.

Copilot, Cursor, Perplexity, Lovable, Replit and Manus resell inference they buy, at a flat monthly price a heavy user can burn through well before the month ends. Gross margins across the category are widely reported to sit far below what software normally earns, and to go negative on the heaviest accounts. Where that happens the best customers are the most expensive ones, and every new one widens the gap.

A gap covered by funding rather than margin is a growth strategy, not a business, and it has three exits: the price goes up, the caps come down, or something smaller quietly starts answering behind the same label. Users tend to find out which one in an email.

We would rather not need the subsidy. Spending less inference per finished task is the only version of this that survives its own success, and it is the one thing a company selling inference can never build.

Work per dollar, not price per call.

The unit that matters is not what a call costs. It is how much of a task one call finishes. Chasing the per-call price alone hits a floor almost immediately, because the calls that were never reasoning in the first place still get made.

The roundtrip tax.

In a multi-step task, most steps are not judgment calls. They are searches, transforms, lookups and formatting sitting between the 2 or 3 moments that genuinely need thought. Paying a full roundtrip for each of them is the tax the harness exists to remove.

The ceiling is honest.

You cannot compile reasoning away, so the reduction is bounded by how much of a task was deterministic to begin with. On a batch of repeated work that fraction is almost all of it. On original design work it is close to none. Both are true at once.

Caching is not enough.

A cache attacks the price of a repeat. It does nothing about the count of first-time calls inside a single task, which is where the bill actually comes from. Cutting the count is a different problem, and it is the one worth solving.

Cost per successful outcome.

Spend per call is the wrong denominator. A task that takes 3 attempts to stick costs 3x the tokens, 3x the tool calls, and whatever it takes to undo the first 2. What matters is what a finished, correct outcome costs, including everything spent on the ones that did not finish.

10 attempts at the same job. 7 land and cost $2 in calls between them. 3 fail, burning $1 more and an hour of someone’s afternoon to put right.
Spend per attempt$0.20
True cost per success$2.57

$18 all in, spread across the 7 that actually finished.

Why it changes the decisions.

Optimising per-call spend rewards the wrong things. It makes a step that is fractionally leaner but fails 1 time in 3 look like an improvement, when it is the most expensive option on the table. Measured per outcome, reliability stops being a separate virtue from cost and becomes the same thing: the fastest way to make a task cheaper is usually to stop it failing.

It also prices the invisible half. Tokens burned on a dead end, a tool bill run up on work that got thrown away, and the human minutes spent cleaning up afterwards all belong to the outcome that eventually shipped. Left out, they simply move the cost somewhere nobody counts.

How the cost comes down.

Across 8 nightly runs, inference per task fell to a sixth of where it started while the graded quality score stayed flat. Three things did that, and none of them involved a better model.

Fewer calls.

A task that once took 10 round-trips to the model now takes 3 or 4. The harness plans the whole task before it starts, batches what it can, and stops asking the model to do anything a function can do on its own.

Offload the rest.

Anything deterministic leaves the model entirely. Data shaping runs as a script, multi-step jobs run as Cloudflare Workflows, and repeated work is served from cache. The model is left with only the judgment calls that actually need it.

Compile what repeats.

Work that recurs runs as a pre-verified routine invoked by name. Recognising the shape and filling in a few parameters costs a fraction of reasoning the same steps through from scratch, and the result is checked against its invariants before anything downstream trusts it.

How the offload actually works.

One task, decomposed once, then every step routed to the cheapest surface that can execute it correctly. The bars are the share of steps taking each path, so the only lane that costs anything is also the shortest.

01Plan the whole task, once
1 call

Decomposed up front rather than discovered a step at a time. This is the one call that always happens, and it is why nothing later in the run has to ask what comes next.

02Route each of the 24 steps
24 steps
Script on the pod14
Cache4
Workflow3
The model3
03Check every result against its invariants
22 hold · 2 escalate

Each offloaded step promised something about its output: a row count, a schema, a constraint that still holds, a build that completes. That promise is asserted in code, so a fast path that produced a confident wrong answer is caught here rather than downstream. The 2 that fail go back to the model carrying what was expected and what actually returned, once each, and are never re-run blind.

04Return structured data
0 calls

The model never sees the intermediate output, so it never enters the context and never gets re-sent. A step offloaded once stays offloaded for every turn after it.

Script on the pod

ripgrep, codemods, SQL, jq, the build itself. Every tool is a local command on a pod that is already warm, so a pass over 2,000 rows is one process, not 2,000 turns.

Cache

Keyed by content hash. Reads and decisions resolve without executing anything. A write is deduplicated by idempotency key, never replayed from cache.

Workflow

Durable and out of turn. Survives a restart, retries itself, and can be scheduled, so the turn does not have to stay open waiting for it.

The model

The plan, a design decision, an outlier the rubric could not settle, a failure that is genuinely new. Everything else was never reasoning.

3 of the 24 steps were planned onto the model, and 2 more arrived there because they failed their check. 5 calls across 24 steps, and the escalations are counted rather than hidden, because a fast path that quietly hands its work back is the one failure mode that would make every other number on this page a lie.

The same 6 steps, two ways.

Drawn to one scale. An inference-first harness carries its history into every round, so the total is far more than the sum of the work in front of it. Caching makes each re-read cheaper and is worth having, but the tokens are still read and the history still grows. Hand the same 6 steps to the pod as one execution and there is no history to carry.

Inference-first322k

6 rounds, each carrying everything said before it. The last round reads more than the first 2 put together, whatever the cache does to the price.

Ultron48k

1 round out to write the script, the pod runs all 6 steps locally, 1 clean result back. Same work, 15% of the tokens.

Loops, maths, retries
the pod
Parsing and pruning
the pod
Repeat sub-queries
the cache
Planning and synthesis
the model

Compiled, then checked.

The tenth time a task shape appears, nothing about it is new. It runs as a routine that was verified once, and the result only stands if it survives a check. Skipping that check is how you get a wrong answer delivered confidently, with no reasoning to inspect, so the escalation path is not optional.

Recognise the shape.

Recurring work is matched to a routine that already exists and has already been verified, so what is left to decide is a handful of parameters rather than an entire procedure.

Run it as code.

The routine executes on the warm pod where every tool already lives as a local command. A loop over 200 records is 1 execution, not 200 roundtrips.

Escalate on surprise.

Output is checked against the invariants the routine promised. Anything that fails, or looks unlike what was expected, is handed back for real reasoning rather than passed along.

The number that decides whether any of this is working is the escalation rate: how often the fast path gives up and hands the work back. Under about 15% it is a clear win. Past about 40% the routine costs more than it saves, because the work is being done twice. It is tracked per kind of task, because the answer differs wildly between them.

Where the cost leaks.

Five patterns account for most of what a task overspends. None of them are exotic, and all of them are visible in the trajectory log before they are visible on an invoice.

Re-sent history

Prompt tokens climbing every round while the work in front of the model stays the same size.

Prune before the call and hold the stable prefix in cache, so a step pays for what changed rather than for everything said so far.

Raw payloads

50k tokens of HTML, JSON or log output going in for 2k tokens of relevance.

Parse, filter and aggregate on the pod. Only the extracted fields travel.

Repeat work

The same file read twice, the same endpoint queried twice, inside a single task.

Results are cached by content, so the second read resolves without a call at all.

A roundtrip per step

Steps to solve far above what the task needs, most of them mechanical.

Deterministic runs of steps compile into one execution and return a single structured result.

Blind retries

The same step attempted 3 times, each attempt paying full price.

Check the invariants, escalate once with what went wrong, and never re-run the same failing shape hoping for a different answer.

What a step really costs.

Two things make a task expensive, and neither is the headline price of a token. Context grows with every round and gets re-read on every one after it, and caching discounts that re-read rather than removing it. Then an attempt that fails still pays in full on its way to delivering nothing.

Cumulative tokens across one task. Thousands of tokens read per step, cached or not. Caching changes what they cost, not how many there are.
What a success actually costs. Cents per resolved task, split by where the money went.

Fewer calls, same work.

Every run, more of the task runs as code. Steps per task actually go up while calls per task come down, which is the whole trick: the work is not shrinking, the share of it that needs a model is.

Steps per task, and who runs them. Model calls against offloaded steps, run over run.
Cost against offload rate. Inference per 1k tasks as offload climbs.
Cache warming. Share of task work served from cache.

Where the work runs.

Chat, automations and canvas all funnel into the same four surfaces. Follow the volume and almost none of it terminates at a paid model, because a step that a script can do correctly is a step the model is never asked about.

Work routing, per task. Sources into surfaces, billed against free.
Calls avoided this month. Cumulative, day by day.
Offloaded steps by surface. Workflow, script and cache, run over run.
Spent against saved. Cost per task against what the model would charge.

Every shape of task.

This is not a trick that works on one convenient workload. Migrations, scrapes, builds, enrichment and digests all collapse, and paid inference ends up the smallest slice of every one of them.

Calls per task, before and after. By task type.
Execution by surface. Share of task work.
Cost share by surface. As a full 100 percent, run over run.

Inside a run.

Telemetry from the harness itself rather than a benchmark built to flatter it. How deep a turn goes, how long it takes end to end, and what it spends those rounds calling.

Rounds per turn. How deep a turn goes, bucketed. The long tail is what used to cost.
Turn duration by percentile. End to end seconds. The median is what a user feels, the p99 is what they remember.
Calls by tool. Where the rounds go. Most land on tools that cost nothing to run.

Cheaper is only interesting if it still works.

Quality is graded by code against the real surface, not by asking the run how it thought it did. It stays flat while cost falls away underneath it, and the reduction lands squarely on work that was never judgment to begin with.

Quality against cost. Graded out of 100 while cost per 1k tasks drops.
Latency, cached against fresh. Seconds per task type.
Where the reduction comes from. Shares of 100 units of work. Judgment does not move.

Efficient across the board.

Six axes, each scored against the floor a run has to clear before it is allowed to ship. They roll into one composite that gets tracked night to night, because a harness that wins on cost and loses on correctness has not won anything.

Efficiency axes. Harness against the passing floor.
Composite score. Out of 100 per axis.

Does a heavy user break the business?

For an inference-first harness, yes: the users who love the product most are the ones it loses the most money on, which is why the subsidy exists. The same seat, the same activity, costed both ways against what that seat actually pays.

One heavy seat, through the month. Cumulative cost to serve against the subscription it pays. An inference-first harness spends the month's revenue around day 11.
Cost to serve, by how hard the seat is used. Same activity, costed both ways. The dashed line is what the seat pays.
Cost to serve, against what the seat pays. Anything over the dashed line costs more to serve than it brings in. Their typical user is already past it.
What is left to pay for. The heaviest seat, $4.15 a month. Paid inference is a little over half of it; the rest does not grow when the user works harder.

Two tasks, traced.

The reduction is not uniform, so here are both ends of it. One task where the judgment is the work and only the loop around it compresses, and one where nearly the whole thing is a fixed transform repeated across a collection.

A schema change, shipped.

The case that only partly compiles. The thinking stays; the loop around it does not.

An inference-first harness12 calls · ~$0.31
  • 1Read the schema · model
  • 2Write the migration · model
  • 3Apply it · model
  • 4Read the constraint error · model
  • 5Patch and re-apply · model
  • 6Regenerate the types · model
  • 7Run the build · model
  • 8Read the type failure · model
  • 9Patch the call sites · model
  • 10Re-run the build · model
  • 11Ship it · model
  • 12Poll the health check · model
Ultron3 calls · ~$0.024
  • 1Introspect the schema · query
  • 2Plan the change · model
  • 3Write the migration · model
  • 4Apply, then verify the constraint holds · script
  • 5Regenerate the types · script
  • 6Build and triage the output · script
  • 7Fix the one real failure · model
  • 8Ship, then hold the health check · script

The build loop runs as code and escalates only when a failure is genuinely new. Reading its own compiler output back to itself was most of the old bill.

A dependency bump, 40 call sites.

The case that compiles almost entirely. One pass over the repo, not a roundtrip per file.

An inference-first harness~90 calls · ~$2.40
  • 1Read each call site · model, one per file
  • 2Rewrite each call site · model, one per file
  • 3Run the build · model
  • 4Read the failures · model
  • 5Patch them one at a time · model, one per file
  • 6Re-run the build · model
Ultron2 calls · ~$0.03
  • 1Plan the change · model
  • 2Find all 40 call sites · script
  • 3Apply the codemod · script, one pass
  • 4Build and triage the output · script
  • 5Fix the 1 site the codemod could not · model
  • 6Re-run and ship · script

39 of 40 sites are rewritten by a codemod that was verified once. Only the site that did not match the pattern is worth a call.

Every step, and where it ran.

Four real workloads, one segment per step, coloured by the surface that executed it. Only the champagne segments reach a paid model. Everything else is a script on the pod, a workflow, or a result that was already in cache.

Model
Script on the pod
Workflow
Cache
Dependency bump across 40 call sites
3 of 25 steps on the model
Find, codemod, build, triage, ship
Schema change, build and ship
3 of 14 steps on the model
Migrate, regenerate, triage the build, deploy
Provision a preview environment
2 of 18 steps on the model
Container build, secrets, migrate, health check
Nightly regression sweep
0 of 12 steps on the model
Standing automation, no model in the loop at all

8 of 69 steps across these four reached a paid model. The rest ran as code on a pod that was already warm, or never ran at all because the answer was already sitting in cache.

What gets measured.

A number nobody can check is a claim, not a result. Every run is instrumented on three layers, and nothing counts as a success unless the third one says it is.

Accounting.

Input against output, what the tools themselves billed, and how much of each prompt was served from cache rather than paid for again. Most of a long task is re-reading its own history, so the split matters more than the total.

Trajectory.

How many steps it took to reach a terminal state, how often the same file was read or the same endpoint queried twice, and what was spent compacting the conversation to keep it inside the window. Waste shows up here long before it shows up on the bill.

Verification.

A hard pass or fail decided by code: assertions that run, a build that either completes or does not, the state of the record afterwards. Never the run's own account of how it did, which is exactly what a confident wrong answer would offer.

On provenance: the routing counts, the traced tasks and the per-seat economics on this page are modelled from the harness benchmark and our own cost lines. The comparison figures are what an equivalent task costs when every step goes through the model, not measurements taken from anyone else’s product. The nightly run is still filling in, and these numbers move when it does.

The point is not that the model is cheap. It is that the model does less.

A step that runs as a script is a call that never happens. A step served from cache is a context that never gets re-sent. Nothing here is clever.

A dependency bump across 40 call sites
~90to2calls
A schema change, migrated and shipped
12to3calls
A preview environment, provisioned
~40to2calls
The judgment inside any of them
unchanged, and it always will be

Judgment is the floor. Everything above it was roundtrips, re-sent history and retries, and those are engineering problems. They get fixed by building, not by waiting for something better to be released.

None of it is secret either. It is written down on this page. Copying it would cost a company that sells inference its own revenue, and would force a company subsidising inference to admit what a heavy user really costs.

So the number holds. Not because we found a cheaper model, but because the expensive thing now happens twice instead of ninety times, and it will still be twice next month, and the month after, whatever a token happens to cost by then.

Ready to grow?

Start to see what success looks like for you within 6 weeks.

Try for free