Fable made me start using Codex
Fable made me start using Codex. Well, actually Claude, Codex, Kimi and MiniMax M3 together.
Not because Fable is weak. Because it is the first model strong enough to run the other models properly.
The shift: stop asking which model is best. Start matrixing every model to the task it performs best at.
- Claude (Fable): the seat. Orchestration, judgement, long context.
- Codex: the coding powerhouse.
- Kimi: long-video understanding.
- MiniMax M3: the looping build system.
Place each task chip on the model that owns it. Correct matches snap in with a one-line rationale; wrong matches bounce back.
Select a task chip, then click the model that owns it.
For the first time the multi-model workflow is truly effortless. Local models included. It all just works, because the model at the top is not doing the work. It is routing it.
Flip routing on and watch tasks stop piling up. Flip it off and see what the inbox looks like without a matrix.
The matrix in practice
Here is the scrubbed version of how a task actually moves through my setup. Internals removed, shape intact.
Everything lands at one seat. Claude holds the context, the taste and the judgement calls. The seat never does the labour.
Tasks are classified by shape, not by app. A heavy code build. A long video to understand. A build that needs many passes. A judgement call. The shape decides the route before any model is named.
The matrix maps shape to model. Codex takes the heavy code. Kimi takes the long video. MiniMax M3 takes the loops. Small local models handle memory and retrieval so context arrives already warm.
Workers run in the background. Briefs go in as files. Results come back as files. No second chat window, no tab juggling. The seat stays clean for the next decision.
Nothing merges on a worker's word. A fresh set of eyes with no memory of the build checks the claim before it lands. Trust the work, not the report.
route:
heavy-code: codex
long-video: kimi
looping-build: minimax-m3
orchestration-and-judgement: claude
memory-and-retrieval: local-models
gates:
audit: fresh context, before anything merges
publish: human, always
The loops
The newest slot in the matrix is the looping build system, and it is the reason MiniMax M3 earned a place at the table.
A loop here is not a retry. It is a fresh-context pass. Each iteration spawns a clean worker that reads the plan from disk, does one slice of the work, writes the result back to disk and exits. The next pass starts with zero memory of the last one.
That sounds wasteful until you watch it run. Conversations drift. Files do not. Because all state lives in files, every pass starts honest. It sees what is actually built, not what the last pass claimed it built. The loop ends when the plan says done or a gate says stop.
That is also why a cheaper model can hold the slot. The discipline lives in the loop, not in the model. The model only has to execute one clean slice at a time.
Two days on the matrix
This page is itself a receipt, but I want to be precise about what the receipt proves.
Fable did not magically replace the rest of the stack. The infrastructure I have built around it means I can give one tight brief, let the model reason thoroughly about the shape of the problem, and have the workspace turn that into routed work. The seamlessness comes from the system around the model, not from pretending one model should do every job.
In my workspace, briefs, plans, outputs, audits and Cortex links all live as files. Fable can follow those links, hold the seat and decide which lane the next piece belongs in without dragging the whole working context into one chat.
The diagrams above and the two toys you just played with were not built by the seat. The seat said what it wanted, a Claude Sonnet worker built the components and the diagrams and returned a green build, and the seat never opened the editor.
Here is the rest of the window. Two days of real work, scrubbed but honest, six models each used for the task shape it fits best.
| Task | Model | Why this one |
|---|---|---|
| Turn one tight brief into routed work | Fable | Thorough enough to solve the shape of the problem and hold the thread |
| Build this page: components, diagrams, green build | Claude Sonnet | Fast, reliable hands for a contained build |
| Plan the hard builds, think through the deep problems | Opus 4.8 | The slow, careful thinker, kept for plans and synthesis |
| Close a heavy build a cheaper lane wobbled on | Codex | The coding powerhouse, brought in to finish clean |
| Run the looping builds and the audit passes | MiniMax M3 | Cheap enough to loop, because the discipline lives in the loop |
| Read a large pile in one pass and return a verdict | Kimi | The largest context window, the long-read lane |
Two of these are worth saying out loud, because they are the part people usually flatten.
The heavy build is the clean one. Every step is tiered against the model I actually have, not against a fantasy model that can do everything. Two cheaper passes wobbled on the same implementation. Codex took the next pass and closed it. The slot is not loyal to a model, it goes to whoever finishes it.
The loop is the honest one. MiniMax M3 runs the audit passes, the fresh-context checks every build must clear before it merges. One night a briefing bug meant the check could never write its verdict, so the system kept firing the same audit again. It ran about ten times before anyone caught it. The fix was not a smarter model. It was a cap: three retries, then the task escalates to me instead of looping forever. A Claude Sonnet worker found the cause, added the cap and wrote the tests the same night, and the lane went back to work. A cheaper model looping is only a weakness if nothing around it knows when to stop.
Both pieces, the routing matrix and the looping build system, are coming to ARI-OS in an update. Same discipline, packaged so it installs on top of an existing setup.
That is the lesson worth keeping. I have spent my time with Fable, and with every frontier model before it, building the infrastructure to create the perfect workspace. The importance was always the infrastructure, not the solution.
The intelligence is the routing, not any single model.