Kicking the tires on Fable

With Prism Runner 5.0 and TripChronos 2.1 both out the door this month, I’m in that dangerous post-launch window where the backlog is quiet and the brain starts pitching new projects. The brain won. There’s a new game in early prototyping. Too early to talk about, except to say it’s going to need a lot more art than anything I’ve shipped before.

Which is convenient timing, because the model landscape just shifted again.

The new model

Anthropic shipped Claude Fable 5, the first of the Claude 5 family and the start of a new tier they’re calling Mythos-class, a step above Opus. (There’s a sibling model, Mythos, that’s the same thing without the extra guardrails, available only to approved organizations. Fable is the one you and I can actually use.) Every model release comes wrapped in the same superlatives, so announcements have stopped being information. You find out what a model is by giving it your real work and watching where it breaks.

So that’s what I’ve been doing: running my normal development workload through it in Claude Code and paying attention.

The early impression isn’t that it’s smarter, although it is. You notice that in code review the way you notice a strong colleague, in the comments you don’t have to make. The bigger difference is that it holds its shape over longer work. My whole workflow is built around spec packages written up front so agents can build reliably, and the recurring cost has always been drift: the constraint you stated in the spec quietly stops mattering forty files in, and you catch it, hopefully, in review. The in-place Prism Runner migration was hundreds of small decisions that all had to respect one rule, and enforcing that rule was most of my job. What I’m watching with Fable is how much of that enforcement I still have to do. So far, noticeably less. It’s also better at fanning work out, spinning up parallel agents to sweep a codebase or cross-check a finding, without me playing coordinator.

I want a few more weeks of real use before I trust any of that as a conclusion rather than a honeymoon. But it points in a direction I care about, because the next project’s bottleneck isn’t code.

The actual question: assets

For a one-person studio, code stopped being the scarce resource a while ago. Agents write most of mine now, and the spec-and-review loop scales better than my typing ever did. What doesn’t scale is art. Prism Runner’s twelve biomes were a brutal amount of visual work, and the new prototype wants more of everything: environments, characters, animation.

So the question I’m actually investigating isn’t which model writes the best Swift. It’s whether image and audio models can be assembled into an asset pipeline, with the emphasis on pipeline, as opposed to a folder of four hundred one-off generations that almost match. That’s the failure mode. Anyone can prompt their way to one gorgeous image. A game needs the two-hundredth sprite to look like it lives in the same world as the first, and that’s a systems problem, not a prompting problem.

The biggest piece is style consistency. I want a style bible the pipeline can enforce (palette, line weight, lighting rules) so generation is constrained up front instead of curated after the fact. This is where most AI game art falls apart, and it’s where I’m spending most of the experimentation.

Repeatability is the second piece. If a biome needs a fifth obstacle variant in six months, I want to re-run a recipe, not archaeologically reconstruct a prompt. That means treating prompts, seeds, and post-processing steps like source code: versioned, reviewable, re-runnable.

Then there’s the unglamorous middle. Generation is maybe a third of the work. The rest is cleanup, palette enforcement, background removal, slicing into sprite sheets, atlas packing. Boring, deterministic, and perfect agent territory. The interesting design question is where the human checkpoints go.

And animation, where the honest current answer is that image models still fight you. Coherent frames of the same character in motion is a much harder ask than one beautiful still. I have ideas. Most of them will be wrong. That’s what prototyping is for.

Why this is the same project as the last one

The Prism Runner rewrite taught me that my job has shifted from writing the thing to specifying and reviewing the thing. The asset investigation is that same shift aimed at art instead of code. I’m not trying to become a painter, any more than I was trying to hand-type every line of Swift. I’m trying to become a decent art director with a very fast, very weird studio.

Whether that works is an empirical question, and the new game is the experiment. I’ll write up whatever survives contact with reality.