Choosing which model to build with

You can hand a seat in a skirmish to a language model. It gets a commander portrait like any other opponent, reads a written description of the map, and issues orders through the same channel a player's own clicks travel down.

That is a separate post, and it is a different question from this one. This post is about the model that wrote the game rather than the models that play it. Every line of it was written by an Opus-tier model, four generations of one appear across the project's own record of what was used, nothing in that record names a smaller model, and this project has never run a controlled comparison to justify any of that.

Both halves of that matter. The useful content here is the reasoning about what kind of work rewards a more capable model, not the verdict, because the verdict is a preference Adam formed on one project and it should not be read as a recommendation.

What the record shows, and what it does not#

Five distinct model names appear across the months:

That table has to be read carefully, because the record was not kept from the beginning and plenty of work carries no entry at all. So the absence of a name is not evidence that a model was never used, and no count or proportion taken from it means anything about who wrote how much of the game. What the table does show is the succession, and that Claude Fable 5 is present across two months rather than tried once and dropped. It is used deliberately and it is not the default. Who actually wrote what, and who decided it is the first post in this series.

What kind of work rewards a more capable model#

The clearest case is the pathfinding rewrite, the code that works out how every unit walks around a rock. Typing that change is not hard. Data structures get flatter, a queue gets rebuilt, some indirection disappears. Any model can produce that code.

What is hard is knowing which parts of it are not free. Two decisions in that work look like missed optimisations and are the opposite.

The first is that route costs are stored at full precision when half would be smaller and faster. Half precision would occasionally make two equally good routes compare as equal when they previously did not, which changes which one gets picked, which means two players running the same match would see units walk different ways, which breaks multiplayer outright.

The second is that the search keeps a slightly wasteful way of handling stale entries in its queue instead of the textbook improvement. The textbook version is faster and it also reorders equally good routes, so it is a route change wearing an optimisation's clothes.

Neither of those is caught by a type checker or a test, because both produce a perfectly valid pathfinder. They are caught by holding the whole failure surface of the game in mind while making a small local change, and that is the specific thing a more capable model buys. The same shape shows up in the work on hidden model faces, where the value was refusing to make a free-looking change until the risk had been measured across all 633 models the game draws, and in a sweep of stale comments that found two real bugs, reported them, and deliberately did not fix them because they were outside the scope of a comment-only change.

Sorting your own work: one question per task#

The test is not how hard a task is. It is what would tell you if it were done wrong. Ask that of the work in front of you and the answers fall into three buckets.

A compiler, a test or a crash would tell you. This is a throughput problem. A cheaper model plus the check is the right shape, because capability is buying you a faster route to an answer something else was going to verify anyway.

The screen would tell you, or a user would. Still catchable, just later and more expensively. Capability shortens the loop rather than changing the outcome.

Nothing would tell you. The change is locally correct, globally wrong, and the only thing that catches it is holding the whole system in mind while making the change. This is the bucket where a more capable model earns its rate, and it is narrower than it feels.

Sort a week of your own work that way before changing anything about your setup. If nearly all of it lands in the first bucket, the model tier is not your lever, and the next section is.

The inverse is just as real. Bulk mechanical edits, renaming something across a hundred places, or reading forty files to answer one narrow question are throughput problems, not reasoning problems. Anthropic's own guidance for multi-agent work says the same thing from the other direction: put the reading-heavy sub-tasks on a cheaper worker model, keep the expensive one for planning, checking and pulling the answers together, and note that each worker is billed at its own model's rates rather than the coordinator's.

The prices, stated as prices#

These are Anthropic's first-party list rates per million tokens, from the current model catalogue:

Claude Sonnet 5 carries introductory pricing of 2.00 and 10.00 through 31 August 2026. Claude Fable 5 is described as the most capable widely released model, for the most demanding reasoning and long-horizon agentic work. Claude Opus 5 sits at half its input and output rate with the same one million token context window.

Adam's position is an experience rather than a benchmark, and it should be read in those terms: he tried Claude Fable 5 and found it too expensive for the volume of work this project generates. That is a statement about this project's shape, which is a very large number of medium-sized changes across a very large codebase, and it is not a claim about value per token on anyone else's work. No quality-per-pound measurement was taken. He looked at the bill.

The lever that is cheaper than changing models#

Model tier is the coarse knob and it is usually not the first one worth turning. Claude Opus 5 offers five effort levels, low through max, with high as the default and xhigh recommended for coding and agentic work. It is also documented as performing unusually well at low and medium, which makes trying your own tasks across those levels a cheaper experiment than a model change and often a bigger saving.

It is one field, and it lives nested inside the output configuration rather than sitting at the top level, which is the detail people get wrong first.

# pip install anthropic
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},   # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": task}],
)

The sweep to run is dull and takes an afternoon: take twenty tasks you have already done, so you know what the right answer looks like, run each at low, medium and high, and record two things per run, whether the output needed correcting and what the reported token usage was. You are looking for the level at which the correction rate starts to climb, and that level is your default.

Two caveats before you start. At xhigh or max, give the output limit real headroom, because the model's thinking and its answer share that ceiling and a tight limit truncates the answer rather than the thinking. And stream large outputs, or a long request runs into a connection timeout rather than a token limit.

Thinking on Claude Opus 5 is on by default rather than opt-in, and turning it off is only accepted at high effort or below. Check both before assuming a request behaves the way it did on an earlier model, because a path that previously ran without thinking now spends tokens on it and shares one output ceiling with the answer.

The rule that matters more than the tier#

Whatever you land on, there is one shape of bug to design against, and it turns up in every project that keeps a table of per-model prices. A cost estimator looks up the model, multiplies by the rate, and returns a number. When the model is not in the table, the obvious thing to return is zero.

Do not do that. Any lookup whose miss value is also a legal answer is a silent failure waiting for the table to go stale, and pricing tables go stale on a release schedule you do not control. Zero for a cost, an empty string for a name, an empty list for a result: all of them read as an answer. Return something the caller is forced to handle, so the interface shows "unknown" rather than "0.00". A cost guardrail reading zero looks exactly like a guardrail that is working.

What this is and is not#

The honest version is narrow. Opus is the default here because most of the work is the kind where a locally correct change can be globally wrong, and because the tier above cost more than Adam wanted to spend at this volume. Neither of those is a finding, and one project with one game behind it is not an evaluation.

What would make it one is the same discipline the pathfinding work already established, pointed at a different question: processor time rather than a stopwatch, one version per run, alternating, best of at least five runs. Twenty tasks with known-good answers, swept across effort levels and tiers, is a day's work and it would replace every opinion in this post with a number. The rest of the stack is documented with rather more care than any of this is measured.