← All writing

Field report · agentic engineering

Tokenmaxxing in the Agentic Era. Frontier models and harnesses turn it into parallel development work.

In one 37-day window, my agent workflows processed 21.5 billion input tokens. The models mattered. The larger shift was the harness: six parallel Git worktrees, agent-led workflows and dozens of specialist subagents working at once.

The industry signal

GitHub’s capacity plan went from 10× to 30× in four months. Its CTO says the driver was a sharp acceleration in agentic development workflows.

10×original capacity plan
30×revised scale target
4 mo.from plan to revised target

Source: Vlad Fedorov, GitHub CTO, 28 April 2026

That is the context for tokenmaxxing. More model capacity can produce more useful work when frontier models are capable enough to use it well.

The leverage does not come from asking one model to write more code. It comes from the harness: a system that directs many agents, gives them isolated working state and turns their output into reliable releases.

This is a field report, not a benchmark. It documents the first 92 days of building a production, multi-tenant B2B SaaS platform that I continue to develop daily. The git history covers all 92 days; detailed token telemetry covers the final 37.

The harness changed the throughput

Frontier models supplied the capability. The harness supplied the operating model: parallel Git worktrees, agent-led workflows, specialist subagents and release guardrails. Commit volume is not a measure of business value, especially when agents encourage small, reviewable changes. It is still a useful trace of how the work moved. The project started at roughly 65 commits per week; it peaked at 911 after I changed how the agents worked.

Velocity Weekly commits Peak: 911 Full git history · final week is two days
What changed: I began using parallel Git worktrees to run up to six isolated workflows at once. Each workflow is led by one agent, which can direct dozens of specialist agents to research, implement, review and test a task. Automated deploys and higher model capacity made the new operating model practical. The changes coincide with the step-up; they do not prove causation on their own.
The operating model behind the jump Six isolated workflows can move at once Each Git worktree has a lead agent that can coordinate specialist agents safely.

The worktrees were the enabling constraint. They gave each workflow an isolated branch of the codebase, so several substantial changes could move without agents trampling each other’s working state. Inside each worktree, a lead agent could dispatch reviewers, researchers and testers while it continued to coordinate the next decision.

Most of the compute protected the code

Only 13.8% of measured subagent compute was classified as implementation. The majority went to adversarial review and verification. Another quarter went to research and planning. Quality wasn’t an afterthought tacked onto speed; it was the mechanism that allowed speed to rise without handing the risk to users.

Where the agent work went Share of subagent compute · 8 June–14 July
  • Review & verification49.8%
  • Research & planning24.8%
  • QA & release audits11.6%
  • Writing code13.8%

Quality kept pace with output

The test suite grew from 16 files to 1,643. By day 92, it contained 11,874 passing tests. Over the same period, bug-fix commits fell from roughly 38% in the early project weeks to roughly 24% in the final month, even as weekly volume grew by more than ten times.

Test files16day 1
Test files1,643day 92

11,874 passing tests · 177 versioned database migrations · CI checks and adversarial QA before releases

The price comparison needs a caveat

For the 37-day telemetry window, the agents consumed 21.5 billion input tokens and 61 million output tokens. At public API list prices for the recorded models, that usage was worth US$18,296. The actual outlay was US$570 (A$870): a Claude Max subscription plus top-ups.

That is a useful comparison of list-priced token value with actual subscription spend. It is not a claim of cash saved, and it is not a total project cost. The first 55 days of token consumption are unmeasured because the local session history rolls over.

Economics 32× API-equivalent list value vs actual paid 37-day telemetry window · US dollars
US$570 actual paid
A$870
US$18,296 API-equivalent list value

The wider lesson

Tokenmaxxing is not a strategy.

Token usage is exploding across the industry because more model capacity really can produce more work. I saw that directly in this build. As agent capacity increased, I could ask more questions, run more reviews and move more changes through the system at once.

But more tokens only create leverage when the workflow around them can keep up. In my case, the next bottleneck was coordination. Parallel Git worktrees removed it. Then the bottleneck became verification, deployment and release confidence. Each constraint had to be challenged before the additional capacity could turn into useful output.

More tokensMore work in flightNext bottleneckImprove the system

Use more tokens when they remove the real constraint. Then find the bottleneck in front of you and challenge that next.

Methodology and limitations

Scope. This report covers the first 92 days of building one production, multi-tenant B2B SaaS platform solo, from 13 April to 14 July 2026. Development continues beyond this period. Git data covers all 92 days: 3,154 commits and 1.25M insertions, excluding lockfiles, vendored and binary files.

Telemetry. Detailed token data covers 8 June–14 July (37 days): 176,045 unique model responses, deduplicated by message ID and duplicate transcript files. April–May token use is not measured, so all token totals are undercounts for the whole project.

Role classification. Subagent work was classified heuristically from task prompts. Treat the role split as directionally accurate, not exact. API-equivalent cost uses public per-model list pricing, including cache-read discounts.