Building token efficiency that refuses to trade away code quality

A coding agent's cost is not mostly the answer it writes. It is everything the model has to read before it can answer — growing conversation history, repository evidence fetched again and again, command and validation output, the recovery cycles after a failed step, and the several physical model calls a single task can require. Visible verbosity is the part users see. It is not the part that dominates the bill.

That makes efficiency a harder problem than it first appears, because the obvious levers are the wrong ones. Sending every model less context, capping every response, or stopping every long-running task would all reduce tokens. They would also remove evidence that some tasks genuinely need, and the correction cycles that follow cost more than the savings.

So we started somewhere else.

01Quality is the hard boundary

Every efficiency decision in the Workbench sits inside the protections that were already there: architecture, security, concurrency, approvals, validation, rollback, review, and the operator's own model choice. An efficiency change cannot lower any of them to save tokens. Quality is a veto, not a metric to be traded against a percentage.

A token reduction is not an improvement if it increases bugs, weakens architecture, loses validation evidence, or requires more correction later.

That reframes the question. Not “how many tokens can we remove?” but “what information does this exact task actually need to reach a safe outcome — and what is it currently paying for that it doesn't need?”

02Why one efficiency mode failed

V1 tested one model-efficiency treatment contract, using the preregistered context posture for each model class. Within every pair, baseline and candidate differed only by that directive. Every arm was safe. The interesting result was not safety — it was that the same contract produced different outcomes depending on where it landed.

There is a pattern worth naming in the architecture-sensitive column, though it must be stated as a hypothesis. Across that group, aggregate input and physical calls fell while uncached input rose 1.53%. That is consistent with fewer, more information-dense calls — but V1 did not establish the mechanism, and independent review remains open. It is a shape worth investigating, not a finding.

03How the study was controlled

Two separate experiments ran, and their results are never combined. The runtime treatment study ran 18 paid comparison arms; a separate benchmark of static context curation ran 54. Seventy-two paid arms in total, two distinct questions, two distinct conclusions.

Each comparison held everything constant except one thing:

• Deterministic workload fixtures, so the same work can be run again and recognized as the same work.
• Identical repository state, request, model, reasoning level, policy, tool authority, and validation surface across baseline and candidate.
• Exactly one treatment difference per comparison.
• Counterbalanced execution order, because cache state is itself a variable.
• Receipt-backed token and cost accounting for every physical model call.
• Terminal validation and rollback evidence required on all build work.
• Independent review for architecture-sensitive comparisons.
• Explicit spending ceilings authorized before any paid arm ran. Every arm finished inside its ceiling.
• Fail-closed promotion: absence of evidence blocks activation rather than deferring to judgement.

Cheap, bounded experimentation is what makes that last rule affordable. When refusing to activate something costs almost nothing, there is no pressure to talk yourself into a weak result.

04The primary result

Across the ordinary efficiency endpoints — the group the promotion decision actually rests on — the treatment produced a modest, safe benefit that did not reach the bar set before the study began.

The decision was to keep the existing production path. Not because 4.85% has no value — at sustained volume a repeatable few percent is worth having — but because the sample was small, the effect varied materially by model and workload, one stratum regressed outright, and a single comparison per stratum cannot establish that a result will hold.

05The finding that changed our priorities

Alongside the controlled study we analysed a window of real governed work to decide where measurement effort should go next. It reordered our assumptions.

The long-running tasks looked like the obvious target, and they were the biggest single pool of input. But attributing that cost by cause did not support the story we expected. Among the 47 outliers with complete activity coverage, none met the strict strong-no-progress definition, and command, validation, and mutation evidence dominated continuation input. That did not justify a new volume-only stop — existing hard ceilings and safety guards remain in place regardless.

So we did not add one. The finding pointed somewhere less obvious and more useful: the cost is in how evidence is represented between steps, not in the number of steps. Future work will study whether that evidence can be carried more efficiently while retaining exact, governed access to the original material. Long-run monitoring stays advisory, and warnings key on absence of progress rather than on volume.

06Long-session summaries are an economic decision

Long conversations genuinely benefit from durable summaries. But producing a summary costs tokens too, and a summary that costs more to write than it later saves is not efficiency — it is a second bill. The Workbench therefore treats summarization as an economic and quality decision rather than an automatic cleanup step.

• Raw history remains immutable and exactly retrievable. A summary never replaces the record.
• Summaries are genuinely useful for navigating long sessions, independent of any token argument.
• Manual summarization is available, with its cost and expected effect shown before anything is charged.
• Automatic summarization stays off until its generation cost and downstream quality are demonstrably justified for the work it is applied to.
• For eligible repository-question continuation, a bounded continuation state remains the cheap fallback; other surfaces retain their existing context path.

Our current measurements do not support an automatic savings claim, so we do not make one.

07Active versus experimental

The useful distinction is not a completion percentage. It is whether something can affect real work today.

08Why this looks different from a general agent platform

General-purpose agent platforms increasingly combine multiple models, tools, persistent state, and isolated execution to complete broad workflows. AIGIS is narrower by design: it is a governed software-engineering runtime, where an efficiency result is accepted only when the resulting code, architecture, evidence, validation, authority, and rollback all remain safe.

That produces five concrete differences in how efficiency is even defined.

09What the study proved

The study did not produce a universal efficient mode. It produced something more useful: a governed way to discover which optimizations are safe, effective, and appropriate for each kind of work.

10Where this goes next

• Improve how evidence is represented between steps, while keeping exact retrieval of the original material.
• Continue treatment experiments at the level of specific model and workload pairings rather than global modes.
• Study the economics of long sessions and summarization further before changing any default.
• Expand evidence coverage to additional providers; a result measured on one provider does not transfer to another.
• Keep quality, validation, and rollback as non-negotiable gates in every future round.