Seven days of agentic development, with the receipts.
A week of building with AI agents, measured rather than remembered — including the parts where the measurement doesn't flatter us.
Published · 7 minute read
We write down what we do with AI, so it should hold that we also measure it. This is a post-mortem of one ordinary week, reconstructed from our own tooling rather than from memory: every session, every message, and the bill.
A caveat sits on top of all of it, and it is the most interesting part. Partway through the week we removed a second, redundant coding agent from the machine and took a handful of configuration files with it. Message text survived, because it lived in a second index. Model names, token counts and costs did not. So the first half of this week is a floor, not a total — we know what was said, not what it cost.
The shape of the week
Three threads ran in parallel: the Brew Room client portal going from idea to live deployment, a 3D game development experiment, and the tooling underneath both. The recurring pattern was that every project stalled on infrastructure, never on ideas.
Two of those threads produced almost opposite working styles, and comparing them is the actual finding.
| Effort | Sessions | Messages | Human : agent |
|---|---|---|---|
| 3D game development experiment | 5 | 3,040 | 1 : 39 |
| Brew Room client portal | 15 | 2,018 | 1 : 11 |
The 3D game development experiment sounds heavier, and in raw volume it was. But it involved 77 messages from a human across the entire week. One session of 1,907 messages ran overnight while the human slept. The portal work involved 177 messages of human input across fifteen separate sessions — a conversation, not a dispatch.
Art and content work survives long autonomous runs. Product logic does not. The contracts, authentication, billing and database semantics needed a person every few messages, because those turns were judgment calls rather than generation problems. No amount of harness fixes that: deciding how a retainer behaves when a contract is signed on the 31st is not a task you hand over and check back on.
What the bill says
For the half of the week we can measure, the total across 46 sessions and 9,320 assistant messages was $14.44, captured on 11 November 2026. The distribution is lopsided in a way that took us a while to understand.
| Day | Sessions active | Cost | Tokens in + out |
|---|---|---|---|
| Saturday | 13 | $0.98 | 1.8M |
| Sunday | 13 | $1.56 | 1.8M |
| Monday | 12 | $5.08 | 4.8M |
| Tuesday | 19 | $6.83 | 3.9M |
Monday and Tuesday carried 82% of the week's spend, and Sunday — the day the big run was started — was one of the cheapest. That is not a mistake in the numbers; it is the shape of the work. A single session, the overnight visual overhaul, was 43% of all measured spend at $6.24, and it drew its cost across three calendar days: $0.12 on Sunday, $4.03 on Monday, $2.09 on Tuesday.
The reason is prompt caching, and it is worth understanding if you are budgeting agent work. That one session read 1.64 billion cached tokens against 4.1 million fresh input tokens — roughly four hundred times its input volume. Long autonomous runs live almost entirely inside the cache, so the 1,907th message costs a fraction of the first.
Model choice mattered more than volume. Here is the same spend split by model, and the per-message cost is the number to look at rather than the total:
| Model | Messages | Cost | Per message |
|---|---|---|---|
| deepseek / deepseek-flash | 8,790 | $11.48 | $0.0013 |
| anthropic / claude-haiku-5-5 | 185 | $2.94 | $0.0159 |
| openai / gpt-6.1-terra | 257 | $0.01 | — |
| openai / gpt-6-luna | 12 | $0.01 | — |
| deepseek-v4.1-flash-free, gpt-6.1-sol, gpt-5.6-sol | 75 | $0.00 | — |
The mid-tier model handled 2% of the messages and 20% of the bill, at roughly twelve times the cost per message of the low-cost model that did the 3D work. That is the trade in one line: when the task is generation against a fixed brief, a cheap model grinds happily for hours. When the task is reasoning about contracts and state transitions, you pay for the better model, and you get the specification that the rest of the project depends on.
The lesson is not "agents are cheap." It is that cost tracks how often you change what is in context. An agent grinding on a stable brief gets cheaper by the turn. An agent being redirected every four messages pays full price every time, and the harness that keeps resetting state pays it again in waiting.
What actually made the work slow
Three things, and none of them were the models.
Test infrastructure. End-to-end suites running 99 seconds a turn, local database resets taking over a minute. One afternoon went to moving icons and changing copy, and took an hour, because each change re-ran a suite that had nothing to do with it. The fix was not faster tests — it was running the right test for the change, which is a tooling problem, not a model problem.
Per-session context overhead. Starting a session and asking one simple question consumed 18,500 input tokens before anything was answered. Every installed skill sat in context whether or not it applied. Scoping skills to the projects that needed them cut it immediately.
Cross-model drift. Pasting one model's advice into another's session worked, but only after the second had already gone the wrong way and been corrected. Model switching mid-task is cheap in tokens and expensive in direction.
What worked
Interrogating the domain before writing any code. The most valuable output of the week was a specification nobody would have written by hand: flat rate versus hourly projects, retention anchors, discounts for paying up front, refund language. It came out of one continuous session of being asked hard questions about a business process. It is applied domain modeling, and it is the thing we would keep if we threw the rest away.
Two long runs in parallel, overnight. Both produced artefacts by morning. Neither needed supervision, because both had a written brief with a definition of done and a fixed reference to compare against.
Re-scoping instead of pushing. When the 3D game port stalled on visual parity, the correction was to judge the work by captured frames instead of by an abstract luminance threshold. Judging by the artefact, not by proxy metrics, is what pulled it back.
What we would tell another team
Agentic development has two regimes and they need different harnesses. Art and content want long, checkpointed, unsupervised runs with a fixed brief. Product logic wants short, interrogative loops with a human approving each judgment call. Most of the friction we felt all week came from running the second kind of work through a machine built for the first.
The model table says the same thing from the other direction. The cheap model that ground through hours of visual work was the right tool for that job and the wrong one for deciding how a retainer behaves at a month boundary. Matching model to regime is cheaper and better than picking one and insisting it fits everything.
The tooling that helped most was the most boring thing in the stack: an index of every session we had ever run. It let us check what we thought had happened against what actually did — including the week we lost, and the money we stopped being able to account for. A process you can describe is a process you can audit. It turns out the same is true of one you can query.
Building something that needs this kind of care?
We bring the same measurement to client work: written design, reviewed changes, and numbers rather than impressions.
Start a Conversation