The result was excellent, well reasoned and the challenge rounds found and fixed genuine bugs. The cost however was not sustainable. I set out to make Foundry affordable not to create a token bonfire so this needed a good old-fashioned human intervention.

If you've been following along, Sol Wilds is the massively multiplayer online roleplaying game I've been building at nights and weekends. It is still pre-alpha, still written in vanilla HTML, CSS and JavaScript, and still the most ambitious thing I've ever tried to make by myself. The only reason I can move at the speed I do is that I don't work alone. Fable, the Claude model I run inside Cursor, does most of the raw engineering work while I direct, review, argue and occasionally throw virtual rocks at it.

Folks have been asking so I’m going to clarify one important distinction about my AI usage. All the stuff the player interacts with on an emotional level is hand built. The GUI, the artwork, the story and the sound design. There are a few placeholders as the scaffolding remains very much a WiP but the final artifacts will have been designed and crafted by real humans. I plan to hire in additional support for the artwork and sound design as we get closer to a closed alpha. The only thing AI ever touches is the code and some occasional fun concept visualizations like the graphics I use in these posts.

Over time I’ve looked at my use of AI more like a traditional partnership between product and engineering. It’s rarely a discussion about the merits of creativity and tends to drift more into the nuts and bolts of dry implementation details. I’m not casting judgement on the use of generative AI for art and design but I am saying (after 3 years of playing around in the sandbox) it’s not for me.

Our partnership and the basis of Foundry follow a well defined process with specific guardrails that I built after battle testing this thing over and over for the last 8 months. A feature starts with research and a proper plan (your PRD). The plan gets challenged five times from different angles before any code is written. Fable builds it, writes tests against what we meant to make, and hands the result to a second model whose job is to prove it wrong (always a different model). Sensitive work gets a security pass. The finished code then goes through five more review rounds before it can reach staging.

It sounds excessive until you see what those reviews catch. They find real bugs in round five. The second model regularly finds things Fable and its five self-reviews missed. I have no interest in saving money by removing the part that keeps my work from becoming bug ridden slop.

So back to the problem of spend and how to fix this excessive token burn. There was a question that kept nagging me (because it never used to be this expensive): why had the process become so costly, and could I fix it without making the output suffer?

What a long conversation actually costs

My first thought was a fairly logical one that most of you are likely thinking. Bigger model means bigger bill. More output means bigger bill. Independent reviewers must be expensive because they are extra models.

But here’s the rub, almost none of that actually explained what I was seeing.

Cursor was charging for the same conversation being read over and over again. Every time Fable took another step, it needed the history of the session: my original request, the plan, all the review rounds, every tool result, every file it had opened and everything it had already said. As I discovered Cursor caches much of that history, which makes rereading cheaper than reading it cold. Cheaper is doing a LOT of work in that sentence though as I’ll explain.

One of the first disastrous chains contained 461 agent turns. Think of a turn as a single complete cycle of work executed by your agent in response to a your prompt. Late in the chain, each of those turns was carrying a conversation hundreds of thousands of tokens long. The history grew with every step and then that larger history would simply blow up the next step after it. And so it went, on and on. By the end, around 39% of the working memory was process rather than project work: rules, tool descriptions, startup documents and the instructions for every stage we had already run.

The independent reviewer was fortunately unaffected (by design), it spins up with zero context on purpose so it can try to disprove the work without carrying any predisposition. This turned out to be my ‘canary in the coal mine’ moment. It basically proved that the issue was overhead.

So I ran more runs with this in mind and the clearest of those confirmed it. Cached context reads made up roughly three quarters of the cost. Output was around 5%. So even something as innocent as the handoff message had to rewrite almost the entire conversation which cost roughly ten dollars by itself.

This is the thing I had missed and I imagine many of you are probably making the same incorrect assumption about your work. Cached does not mean free. A cheap reread multiplied by a huge conversation and hundreds of turns becomes expensive as hell.

Our first test lied

Fable and I set to work building an analyzer to read Cursor's session transcript and estimate how much each stage was costing. This included a comparison with Cursor’s own dashboard usage and cost breakdown by model etc. It counted all the turns, measured what text we could actually recover, found a metric ton of repeated file reads and eventually pinpointed precisely where the conversation was overloading itself.

So there it was, the root cause with a clear path to optimize. It seemed almost too good to be true and of course that’s precisely what it was.

The first version basically spun out a bunch of BS about the full cost of the chain it missed several key nuances and some how managed to under sell the impact of rereads despite it being previously identified as the lead culprit. So I went back by hand without Claude and ran the numbers in Excel. I pulled the usage export and matched it against three completed sessions. Turns out Claude’s meter had been undercounting by somewhere between two and four times. The lesson of AI being bad at math once again relearnt by me the hard way.

There was another problem and that is Cursor writes conversation transcripts asynchronously. This matters because no two runs are the same and no two agents ever behave exactly the same way. So some agent transcripts appear immediately and sometimes they stay invisible until the end of a turn. This meant that the meter we built could report almost nothing while the account had already been charged. One session closed with only a few dollars visible in our meter, then appeared in the export later at approximately ~$40.

That was a useful slap in the face if I’m being honest. We stopped calling modeled numbers billing. From then on the transcript meter just became an early-warning instrument and nothing more. The usage export verified in Excel became the authority. We also started separating three kinds of claim in every cost review: what we had measured, what the tool had estimated, and what we simply did not know yet.

This sounds needlessly pedantic I’m sure but it changed the whole investigation. If you take nothing else away from this essay let it be this: An AI agent is extremely good at building a clean story from incomplete evidence. If you let your agents cosplay they will gleefully and then they’ll shower you with overconfident “receipts”.

Cutting the obvious waste

Once I got the agent (and in turn the measurement) to stop lying to me, the first set of problems looked almost mundane.

The ten plan and implementation review commands repeated huge chunks of the same instructions:

• The startup notes had slowly turned into a diary.
• The agent kept reopening large files it had already read.
• It spent sixteen turns rediscovering how to start the browser test rig even though the answer already existed in the repo.
• The final wrap-up took more than sixty turns at the exact point where every turn was most expensive.

The shift at this point was really to start treating the build process like a product performance problem. Measure the shape, form a hypothesis, change one class and then observe.

And of course things moved, dramatically. The command chain lost about a quarter of its injected text. The challenge instructions alone dropped by almost half, mostly by giving shared rules one home instead of copying them into ten different commands. We cut more than ten kilobytes from the status document read at the start of every session. Deterministic chores such as branch setup, closing checks and merge polling moved into small scripts that return one clear result instead of making Fable narrate every step.

The wrap-up fell from roughly sixty-plus turns in the early samples to somewhere in the thirties and low fifties in later builds. After more optimizations we managed to get that down to the twenties. We added a simple set of instructions around the browser rig so the agent didn’t have to reread its source code every time. We also built in a process that automatically moves the plan, the branch details and the current review state into their own files as the chain progresses so their weight isn’t automatically inherited every turn. That was a pretty cool find because it meant that if Cursor crashed or compacted the conversation, the next agent could recover from Git rather than spend another sixty turns reconstructing history by hand.

Then we changed the rhythm of the agent itself, how it actually decides to sequence the work. That resulted in independent tool calls running together in one turn. Files were reread when they had changed or when a new review angle genuinely needed them, not because every command ritualistically said "read everything again”. The plain-English jargon checker I built to stop the god awful spewings of Claude also stopped running on every single response and I moved it to the four places where it genuinely serves a purpose.

The result of all this still wasn't quite the triumphant “line goes down” chart I wanted, we’d made real gains but some things just weren’t shifting. For example the median number of agent turns stayed almost flat while tool calls rose a little. One of the forensic builds we ran blew straight through the estimates because the difficulty level for that task spiked and I hadn’t properly accounted for that type of scenario. But importantly the safety net stayed strong, the challenge rounds kept finding and fixing real bugs so we’d definitely made some headway without losing Foundry’s true value.

The cheaper model that cost too much

The next experiment was more obvious. If each turn is expensive, use a cheaper model for the main build and let the stronger model review it.

For two large chains I moved the main work from Fable to Opus. On paper the per-token price looked roughly half as expensive and Anthropic made a whole song and dance about how Opus 5 was practically on par with Fable 5. In practice either I just don’t get Opus 5 or I was experiencing its blind spots. Either way both sessions expanded to nearly five hundred turns. One run's five implementation reviews found twenty issues and the independent grader STILL found more afterwards. Opus was cheaper but it needed far more thinking and correction to reach the same bar as Fable.

One caveat: I can't honestly say Fable would have completed those exact jobs perfectly. They were unusually large process changes and this was less a controlled laboratory test and more me just throwing things against the wall. But what I can say with confidence is that the workload was still rising at the end of both runs and that matters.

So I put Fable back into the captain’s chair. Opus was replaced by Grok which took its place as the independent grader where a narrow/fresh context window actually suits it just fine (before the Claude purists come for me). For the later cost pilots I also ran Fable at Medium effort rather than High. The drop in quality was so minuscule that I, as a simple human, reason that model effort is best thought of as dial you SHOULD move not a first principle that stays static for every task regardless of difficulty or cost.

The context-window trap

I had one other sacred cow that I had been refusing to let go of: the one-million-token context window.

I liked the idea that a session could hold everything. One difficult run on average reaches about ~750k of that window without being compacted, which proves the capacity is real and useful. The problem is that capacity and economy are different questions and keeping more history available also means there is more history to reread.

So I didn't remove the million-token option for Fable, instead I looked for ways to optimize the amount of times that context might get reread.

That led to an interesting experiment which also happened to fail with enough empirical evidence that I finally learnt a valuable lesson about how Cursor handles context squishing.

Cursor has a /Summarize command that compresses the conversation into a shorter working memory (the squish). So the theory went, if repeated context reads were the dominant cost, summarizing at two safe points in the build should lower the price of every later turn. There was one small rub though, /Summarize cannot not be queued, so I had to come back to the computer and trigger it manually in the middle of an otherwise auto driving chain.

Before trying it though, we needed to make the chain recoverable without chat memory. So we added two durable checkpoints recorded the plan, branch, exact changed files and completed stages. Every later command learned how to rebuild its state from those records whilst avoiding the numerous rereads of bloated conversations. Then finally we wrote the economic test before running it.

Across three ordinary chains we would compare the five billed Fable events before and after each summary. At least five of six boundaries needed a 20% drop in per-event cost, the median net saving needed to clear 15%, and quality had to stay flat. Any lost stage, missing state or median saving below 5% killed the idea.

The summary appeared to work beautifully. Five of the six planned boundaries fired, and all five made the following events between roughly 30% and 65% cheaper.

Then we included the price of summarizing.

At the early boundaries, Cursor reread the full conversation at ordinary input price in order to create the shorter version. Those summary operations averaged a little over six dollars across the five attempts. Four of the five boundaries lost money once that cost was charged back against the cheaper turns that followed. The median net result was about 19% worse than doing nothing. Bummer.

At the early boundaries, Cursor reread the full conversation at ordinary input price in order to create the shorter version. Those summary operations averaged a little over six dollars across the five attempts. Four of the five boundaries lost money once that cost was charged back against the cheaper turns that followed. The median net result was about 19% worse than doing nothing. Bummer.

There was one promising summary though that we discovered by accident. The second boundary in one of our chains never ran because I forgot to trigger it (I am after all only human). It changed the math and indicated in particularly heavy sessions running one /Summarize can net the promised gains directly after running /test-it. Why after /test-it and not /build-it? That’s actually just because we ran into a weird Cursor bug where the option to call in a predefined subagent directly after running /Summarize fails and the agent can only see Composer as an option.

But in short the experiment taught us that while the quality can stay intact using /Summarize, the economics fail to pass the bar. In most runs it’s simply not worth the effort that the manual intervention requires and in lighter sessions you’re actually making the cost worse.

The durable checkpoints stayed however, so it wasn’t an entirely wasted trip. They genuinely protect the work from crashes and Cursor's own automatic compaction. Plus I can still summarize manually with confidence if I see the context is genuinely under pressure on heavy sessions.

Where the numbers landed

Here is the comparison that will resonate with everyone sweating over their runs and watching the allowance bar fill. The first three fully measured chains averaged a little over $250 of API-priced usage each. The final three Medium-effort pilot chains averaged a little over $60.

Those figures are real, I’m not blowing smoke. The jobs varied in complexity and were battle tested thoroughly so I’m left with high confidence that the changes resulted in a ~75% reduction without any meaningful loss in quality. As a small bonus my builds are now faster as well, which I used to worry meant worse but the numbers are actual fact (not based on my feelings) and they tell a different story.

So what can I can now take to my hill and die on?

Well we found the root cause, it was repeated context and we shipped real ways to deal with it:

We cut duplicated instructions and expensive mechanical turns.

• We stopped paying Fable to rediscover the same tools.
• We gave interrupted sessions a cheap recovery path.
• We tested a cheaper builder and reversed the decision when it didn’t pan out.
• We made the large context window and effort optional rather than habitual.
• We tested summarization and determined it can be useful in rare cases but not by default.

The build chain still plans, tests, challenges and grades every feature. It still runs the full repository check twice. Most importantly I still trust it even though it’s ~75% cheaper to run.

Here’s the thing, there was no magical switch that made this happen. The cost lives in the relationship between turns and memory, which meant the answer lived in the process itself rather than a setting. That isn’t as exciting as a clickbait headline “here’s the one secret model companies don’t want you to know about”, but it is the kind of lesson that will help you recognize how your own process works.

I went into this just simply wanting a smaller bill but as usual on my road to becoming a Jedi Master I came out with something much more valuable.