▶ YouTube Summaries

• https://www.youtube.com/watch?v=8GRmLR__OGQ
• Original title: A proper guide to Fable 5

The follow-up to the "misconceptions" video. Theo, admittedly "one-shot" by Fable 5, walks through the actual systems, prompts and CLAUDE.md/skills changes he uses to get a month of work done in 2–3 days. Core thesis: Fable is not a better Opus — reusing Opus-style prompts wastes it. Its edge is how far it can go end-to-end (implement, test, verify) and how well it breaks work into sub-agents. Treat it like the old models and you won't see the benefit.

Cost min-maxing first

• Same rule as before: do not exceed high reasoning. X-high/Max overthink per-step and loop, producing worse, overdone code at absurd cost. Reasoning effort applies per tool call, NOT to how long a task can run — Max doesn't do more steps, it thinks more per step, and most steps don't need it. Every person he saw blowing through limits was on X-high/Max/Ultra-code. Ultra-code itself runs high under the hood, just many of them — even Anthropic agrees high is the best value. Leave it on high and stop thinking about it.
• All the PR work below cost ~$150 across every model (not just Fable) and never broke 40% of either the Claude or Codex sub.

Teaching Claude Code to shell out to Codex / GPT-5.5

The key move. Codex sub limits are absurdly generous (~$14k/mo of notional inference, plus stacked resets), and 5.5 crushes Anthropic at computer use — the Codex desktop app drives the whole Mac (Xcode setup, complex app navigation), not just a Chrome tab. Route token-hungry work there: log digging, giant PDFs/specs, computer use with hundreds of screenshots.

Implementation lives mostly in the global claude.md:

• "If computer use is helpful… shell out to GPT-5.5 with Codex." The words "shell out" matter — it tells the model to call Codex via bash.
• A model-selection glossary. He defines his own axes — intelligence (how hard a problem the model handles unsupervised) and taste (UI/UX, code quality, API design, copy) — plus a cost score, then rates each model so Fable knows what to route where. His ratings: GPT-5.5 = high intelligence, high (near-free) cost-benefit, weak taste ("writes TypeScript like a Python dev, Rust like a paranoid C++ dev"); Sonnet 5 = less intelligent, token-hungry so often pricier than Opus, slightly more taste; Opus 4.8 = more intelligent, high taste; Fable = best-in-class intelligence and taste, expensive. Fable itself wrote the "cost is only a tiebreaker; intelligence > taste > cost; escalate without asking" section — Theo edited it live on-screen because he disagreed with over-weighting cost.
• Rules: bulk mechanical work (clear specs, migrations, data analysis) → 5.5 (effectively free). User-facing work (UI copy, API design) needs taste > 7. Reviews → Fable/Opus, optionally 5.5 as an independent perspective. Never use Haiku. Since 5.5 is only reachable via Codex CLI, inside workflows he has Sonnet-on-low spawn 5.5 and report back, with a prefix so he can see which sub-agents used 5.5.
• Most of these rules were appended as he hit problems: get it ~80% working in half an hour, then feed each failure back to the original thread, ask for a fix, cut the suggestion in half, and paste it in.

Skills (used sparingly)

He's not a heavy skills user (plans to delete these once models/Anthropic get good at computer use). Remember Claude only sees a skill's description until it invokes it, so the description must carry enough to decide whether to call it.

• codex-review — ask Codex/5.5 for an independent review of uncommitted changes/branch diff/commit. Workflow: identify target, make a temp artifact dir, run codex review with a focused prompt, then verify Codex's claims against the code before presenting.
• codex-implementation — bounded work, usually on a worktree.
• codex-computer-use — his favorite; gives Claude Codex's computer-use powers without building it in or burning tokens. Prompt Codex simply — Claude tends to over-prompt Codex as if it were Claude. Add guards like "if Codex finds nothing, say so clearly" to stop the parent model re-running.

He deliberately does NOT publish the files — wants viewers to screenshot, rebuild and learn to edit these fearlessly rather than copy-paste.

The real workflow — triaging 16 stale PRs on "Lakebed"

His side project Lakebed had ~16–20 stale PRs (50–80% done, disliked SDK changes) blocking the project. Sequence:

1. Prompt: "investigate and review the open PRs… list which are ready to merge, which need a rebase/touch-up, which were trumped, which have good ideas but should be scrapped. Use a workflow to break the work into multiple reviewers." It spawned a workflow (48 agents: 16 investigators + Fable/Opus judge panel; 14/16 unanimous) and returned a triage with a suggested order of operations.
2. Told it to close the dead PRs, then spec the rest as HTML plans (using his HTML-planning skill) with links back to the inspiring PRs — reviewed on his phone.
3. Asked how to structure the remaining work. It pushed back sensibly: a single giant workflow is the wrong tool because this is checkpoint-driven (each PR needs CI, review, merge). Workflows shine for deterministic fan-out-and-verify; here it should orchestrate from the current session, spawn worktrees itself, and use workflows only for multi-agent review passes. It also found parallelizable streams.
4. Set a goal ("keep going until conditions pass"): complete all the work, permission to create worktrees, rebase, branch, merge and close PRs, but do not merge until automated reviewers (Bugbot, Macroscope, Code Rabbit) approve. It ran 5 hours and landed a month of roadmap — ~11–12 PRs merged from one thread.

Why merging to main isn't insane: merges deploy only to staging; production is still human-in-the-loop, so the model can't touch prod. He first had Fable clean up staging, then stress-tested everything himself and with other agents (testing new + old features, diffing prod vs main). Found almost nothing to fix — he burned more tokens verifying than producing, and takes that to mean he still isn't pushing it hard enough.

Parallelizing across machines

Claude over SSH is painful (no image paste, bad scroll/select), so he uses T3 Code (open-source, no revenue yet — he's spent >$250k on tokens+salaries) with Tailscale to drive agents on his Mac Mini and Linux boxes from the T3 Code web/desktop/mobile apps. From his phone he kept spawning worktrees to fix small bugs (e.g. moving a favicon so T3 Code shows an icon), taking a screenshot of a failure and pasting it into a fresh Fable thread on a worktree so it doesn't disturb other work. Also had Fable merge five phone-spawned worktrees into one conflict-resolved branch for combined testing. GitHub's load times are the slowest part of the loop.

He doesn't expect most of this spawned code to merge. Time-to-solve is a codebase-health signal: under 3 min = simple, safe to file; ~15 min = pay attention; over an hour = something's wrong with the architecture. Example: a mobile scroll-jump fix took 90 min (scary, won't blind-merge) vs a 2m20s fix that was suspiciously simple and slightly wrong (talked about a "drawer" they may no longer have). Think about architecture, request, speed and blast radius — and just ask the model questions when unsure.

Closing pro tip: Vibe Proxy auto-splits traffic across multiple accounts (uses the API-key Claude Code, so you lose /remote and a few features). Overall he's more ambitious, shipping more, and having more fun than ever with this model.