The Sol/Fable Leap: From Pair Programmer to Model Fleet
A measured 10–20× increase in engineering reach turned my nights-and-weekends experiments into full product ecosystems.
For every new coding model flagship release, I return to the same two side projects for my “informal benchmark”: a private customer-support agent and a sports-analysis system. I rebuild them to get a feel for the new systems: how much farther can I push a real product per hour of active steering than I could a few months ago?
This round, the answer was striking. Sol and Fable are proficient coordinators. Given a tiny amount of harnessing, two consumer subscriptions started behaving like a heterogeneous engineering fleet. This doesn’t mean they’re “magic one-prompt app machines”. I was heavily engaged for roughly 100 hours of nights, weekends, and the occasional 2–4 a.m. session timed around capacity resets. But there’s a step change in how much can ship per engaged hour.
Tl;dr
In July, I’ve sent over 2,000 prompts while the coordinators launched about 350 subagents. I stayed intensely engaged while a dense layer of autonomous work ran underneath me.
The collaboration harness is simple: I gave capable coordinators permission to delegate, told them to choose the appropriate model and reasoning level themselves, and used Git as the boundary between Claude and Codex.
That tiny harness cut my cost per shipped change roughly in half, which is the difference between blowing through my $200/mo caps in a day, and fitting a whole product sprint inside them.
Conservatively, every hour I put in shipped work that would have taken 10-20 hours of pre-AI engineering.
Methodologies for these stats are in the appendix
The coordination leap
Earlier models were good employees. Sol and Fable are good leads. Handed a goal, they will scope it into bounded pieces, pick a cheap model for the mechanical pieces and a strong one for the judgment calls, launch the work in parallel, and come back with a synthesis and a recommendation. They also turned out to be genuine collaborators on the hard parts: algorithm development, research legwork, evaluation design.
When I started the sports project with Sonnet in early 2025, a similar block of nights and weekends bought me a thin web skin over some basic algorithms, so I could explore and evaluate ideas for foil racing. This sprint, a comparable time box carried a major upgrade of those algorithms, brand-new ones for maneuvers and different equipment classes, and then an entire product ecosystem around them, including accounts, sharing, and even an iOS phone and watch ecosystem for easier data collection. I hadn’t been planning to build that on day one. The increased execution capacity kept changing which product decisions were available to me: the plan expanded through collaboration with my coordination models.
The coordination harness is tiny
I experimented with delegation patterns, watched where context and premium-model capacity went, and encoded the useful behavior in a small set of durable instructions. The result was tiny: about fifteen lines of routing guidance and four short worker profiles (a read-only scout, a bounded worker, a critic, and a deliberately expensive paranoid reviewer).
Succinctly, I gave capable coordinators permission to delegate, told them to choose the appropriate model and reasoning level themselves, and used Git as the boundary between Claude and Codex.
The minimal recipe:
Tell the coordinator to delegate independent, bounded work.
Let it choose the model and reasoning level for each subtask.
Give it defaults and constraints, not an exhaustive routing matrix.
Put concurrent writers in separate Git worktrees.
Use GitHub issues and pull requests for cross-system handoffs and independent review.
What the harness changed, measured
I pay $200 a month each for Claude and Codex Max. At retail API rates, the activity in my Claude logs would be measured in thousands of dollars, not hundreds. This is a rough ballpark, but gives you a sense of how generous these subscriptions can be.
I deliberately tested an unharnessed extreme: naive “ultracode” with newly re-released Fable. It shipped real work hyper independently. It was also expensive, and diagnosing that cost led me to focus my harness on two areas:
Lever one: model selection. Unharnessed, every subagent defaults to the same frontier model as the coordinator. Told to pick a model per subtask instead, the coordinator routed over 40 percent of delegated Claude messages to Sonnet and Haiku, models roughly three to ten times cheaper.
Lever two: warm context. A new subagent starts blank and bills full price for every token it reads, while a long-lived session reuses what it has already ingested at roughly a tenth of the price. An unharnessed fan-out therefore buys the same repo understanding dozens of times at frontier rates, and throws it away dozens of times: in my “YOLO ultracode blowout” logs, each parallel worker began by re-reading the codebase from scratch. The harnessed coordinator buys that understanding once, keeps it warm, and spends it frugally writing scoped briefs. It is the difference between hiring thirty senior consultants who each bill a first day reading your wiki, and one lead who already knows the system writing tickets so precise that juniors start producing in minutes.
Together, the two levers cut each unit of shipped work to roughly half the baseline cost.
Same high engagement, more output
My prompt timestamps estimate my own time at roughly 70 to 100 engaged hours across both systems, usually working on both platforms simultaneously.
Underneath that steering, the delegated work genuinely ran on its own: about 60 percent of Claude tool operations ran inside delegated contexts. They were also managed mostly asynchronously. I wasn’t waiting on them; while one crew ran, I was steering another. I frequently set up larger tasks to run overnight or while I was working on other projects.
My prompts concentrated on critical product decisions, resolving ambiguity, brainstorming solutions to difficult problems or new feature ideas. The fleet handled the reading, the implementation, the test runs, and the first pass of review in between.
That last part took deliberate investment. I kept improving the test systems specifically so the fleet could check its own work: Playwright suites for the web app, iOS simulator runs for the phone and watch, labeled data for the algorithms. Delegation pays off roughly in proportion to how well the workers can verify themselves.
Git for cross-platform collaboration
I primarily use Claude and Codex together because they give me two pools of advanced-model capacity. Git lets work move between those pools. Their different working styles and partially independent histories then provide a secondary benefit: useful variety in implementation, criticism, and review.
This is not especially surprising. Git has been helping people with different contexts collaborate on the same software for decades. Git carries branches, commits, diffs, and current code state. GitHub carries issues, decisions, test evidence, review comments, and ownership.
Their partial independence is useful. The second system can review the work without automatically inheriting every assumption that shaped it. For ordinary implementation, I let each system run its own native reviewers, which is faster and skips the cross-provider choreography. For complex or consequential work, algorithms, architecture, privacy, the subtle stuff, I set up the actor and critic across model families: Claude builds and Codex reviews, or the reverse.
What these models effectively handled
The workload spanned two very different projects. One is a consumer sports product: GPS and wind algorithms, product design, accounts, competitions, a full web app, and a native iPhone and Apple Watch recorder (you can see a partial version at foil.run; the iOS phone/watch app is not yet released). The other is a low volume support agent for a small consumer company: prompt architecture, retrieval, and multi-turn evaluation. I found this structure remarkably effective across the whole range of tasks.
I started building these due to my interest in data science and agent infrastructure, which is where I steer hardest and question everything. Everything around it (accounts, sharing, competitions, native apps, test harnesses, deploys) is the ecosystem a real product needs. Pre-AI, that surface area belonged to a small team of specialists I did not have. Now the fleet builds the ecosystem while I stay close to the models, and my specialty gets to ship inside a complete product. The “weakest” area for me remains UX - I find the harnesses still can’t quite bridge the gap to truly beautiful user design with my inexpert hands at the wheel.
The multiplier
For the numerator, I estimated what this month’s shipped work would have cost a conventional senior team before AI. The full workings are in the appendix; the conservative reading: every hour I spent steering shipped 10-20 hours of conventional engineering, and most of the estimates run higher.
The multiplier is time and breadth at once. Before AI, an hour of my time bought an hour of data science. This month it bought a slice of a whole team.
This harness will probably disappear
I am building this harness manually because the models are improving faster than the surrounding products. I expect much of it to become a default capability: coordinators that choose their own workers, reasoning levels, context boundaries, and review paths.
The fifteen lines of delegation guidance are useful now. I would be surprised if I still needed to write them a month from now.
Benchmarking this with one statistic is hard. I care less about “How well does this model perform this task?” than “If I give this system two days, how much can I accomplish?” Rebuilding a whole system is messy as measurement and excellent as experience. It reveals capability changes that disappear when the unit of analysis is one isolated task.
What required constant explanation before? What can now be delegated? Which ideas become real before the time box ends? Where does coordination begin to break? How large a fleet can the coordinator use effectively? Which product ideas were previously too expensive even to explore?
The benchmark runs again at the next capability jump: same two projects, same nights and weekends. Lately, the answers keep coming back bigger.
Wren is a Senior Staff Research Engineer working on AI evaluation, tooling, and reliability.
Appendix: How I measured this
I analyzed my local Claude and Codex transcripts, then reconciled the agent activity with GitHub. The raw measurement window is my last 30 days of transcripts, focused on the time since Fable re-release.
Human prompts and engaged time
The prompt counts include 1,014 cleaned direct-human prompts to Claude and 1,339 to Codex in the July window. I excluded automation, inter-agent relays, heartbeats, delegated-worker prompts, and Claude-to-Codex dispatches.
To estimate my time, I combined both timestamp streams so simultaneous work in Claude and Codex counted once. I tested three ways of grouping nearby prompts into working bursts. The strict setting ended a burst after a 10-minute gap and added two minutes for reading and setup, producing 69 engaged hours. The tight setting used the same 10-minute gap with a five-minute allowance, producing 79 hours. The monitoring-inclusive setting allowed a 15-minute gap and ten minutes for reading, reviewing, or watching agents run, producing 98 hours. I use “roughly 100 hours” in the body as the inclusive upper bound.
That produces the roughly 100 hours cited in the body (the full June 20 - July 13 window measures 95 to 145 under the same settings). Time inside a burst can include prompting, reading, reviewing, and watching agents run. More than half fell on weekends and a holiday stretch, and weekday work concentrated at night (because I have a day job that has even more tokens available)
Delegation and autonomous movement
Claude provides the cleaner delegation denominator. In July I observed 353 launches and hard-linked 262 of them to worker transcripts. Of those, 221 completed before another direct-human prompt reached the parent session: 84 percent. About 60 percent of Claude tool operations ran inside delegated contexts.
Most of the window came before my access to Sol, when Fable was planning and Codex was primarily executing. The direct Sol/Fable comparison uses their first shared window of roughly a day and a half. Claude initiated about 26 native subagent launches per 100 of my prompts; Codex initiated about 21.
Model mix and retail cost
The cost analysis covers Claude. I deduplicated streamed usage records by message ID, kept the complete record, and applied current Anthropic API list prices to fresh input, cache writes, cache reads, and output. This produces a retail API-equivalent valuation, a comparison proxy separate from my $200 subscription bill.
In July, the Sonnet family handled about 36 percent of delegated Claude messages and Haiku another 7 percent, over 40 percent combined. Those tiers were roughly three to ten times cheaper than Fable at list prices.
One economics footnote: Fable re-released on July 1, and during this window Anthropic included it in Max plan limits as a launch promotion (through July 12). It has since moved to usage credits, so the subscription economics of a similar sprint will look different.
For the harness comparison, I matched Claude’s PR-creation commands to GitHub outcomes. The early harnessed window landed roughly 40 to 50 percent lower in retail API-equivalent value per merged Claude-attributed PR than two Fable-heavy fan-out windows. The windows contained different work. This is an observed operating contrast, with quality and causality left open.
Estimating the pre-AI work
This is the squishiest number. I defined the exact June 20 baseline, excluded the system that already existed, separated raw GPX and fixture data from authored code, and grouped the in-window work into engineering domains.
Three separate Opus-agent estimates put the conventional senior-team effort at roughly 1,500–3,300 hours. A blind Codex-family estimate that inspected representative PRs landed substantially higher, roughly 5,000–12,000 hours. All four estimates are model-generated, and their spread shows how much the answer depends on feature grouping and assumptions about a conventional team.
I scaled each engineering domain by its July share of merged-PR churn: that gives roughly 1,000 to 2,200 conventional hours against 70 to 100 engaged hours. The conservative edge sits near 10x and the central readings land around 15 to 20x, which is why the body says 10-20 and calls it conservative; the Codex-family estimate implies multiples far above that. I use it as an order-of-magnitude scale check, expressed as conventional labor-hours per hour of active steering. Elapsed development speed is a separate question.
The precise transcript and GitHub counts carry the strongest claims. The cost comparison is observational and Claude-side. The labor-hour multiplier is a counterfactual estimate with deliberately wide uncertainty.