How to Use Fable 5 for End-to-End Coding

TL;DR

Use Fable 5 as an end-to-end implementation agent, not merely as a smarter replacement for Opus. Keep reasoning effort at high or below, let it divide work into smaller pieces, and use cheaper models for delegated tasks. The described workflow completed a month of backlog in three days and reduced a five-and-a-half-hour run from a potential cost in the thousands to about $150.

Transcript

Saying Fable 5 has oneshot me would be a criminal understatement. I really appreciated the model the first day I tried it, but over the next two I started to genuinely love it and was blown away with what it was capable of. And then I got taken from us and I I struggled. I did my best to make decent work come out of Opus 48 and GPD55, but it just i... Read More

Key Insights

• Fable 5 is most effective as an end-to-end implementation agent that can write code, test changes, verify results, merge work, and coordinate smaller tasks. Reusing prompts designed for Opus fails to exploit this broader capacity and may make the improvement seem smaller than it is.
• The creator completed more work during the first day after regaining Fable 5 than during the preceding month. The model finished planned but incomplete tasks, fixed code, merged changes, and helped turn a stalled backlog into software the creator felt confident enough to ship.
• Lakebed had accumulated roughly 20 or 30 unfinished pull requests because earlier work was only 50% to 80% complete. Concerns about SDK changes, implementation quality, and cleanup effort prevented those changes from moving forward until Fable 5 was used on the backlog.
• A single thread produced approximately 11 or 12 merged pull requests as part of a larger burst completed over two to three days. The creator remained the only contributor to Lakebed, so the reported output was attributed to the agent workflow rather than additional human contributors.
• The five-and-a-half-hour agent loop cost about $150 while processing closed, fixed, updated, recreated, and merged pull requests. That total included Fable 5 and the other models it called, showing how model orchestration reduced the potential expense of sustained autonomous work.
• Fable 5 can control costs by delegating suitable work to cheaper models such as Codex and GPT-5.5. Its distinctive value is not performing every step personally, but deciding how to divide an extended software task and coordinating the necessary work across agents.
• High is the recommended maximum reasoning effort because xhigh and max can repeatedly second-guess decisions. The creator reports that these settings may create excessive changes, worse code, longer reasoning loops, and sharply higher costs even when the original request is relatively simple.
• Reasoning effort controls how much the model thinks per tool call or change, not how many total steps it can perform. A task requiring hundreds of steps can still run for a long time at low, medium, or high without using max reasoning on every individual action.

Questions & Answers

Q: How should Fable 5 be used for software development?

Fable 5 should be given end-to-end software outcomes rather than treated as a slightly smarter version of Opus. Its advantage appears when it can implement features, test and verify changes, fix code, merge work, and divide a larger objective into smaller tasks for subagents. Prompts built for earlier models may not reveal this capability because they constrain the model to narrower coding work.

Q: Why should Fable 5 reasoning effort stay at high or below?

Reasoning effort should stay at high or below because xhigh and max can make Fable 5 overthink individual steps. The creator observed longer reasoning loops, unnecessary changes, excessive implementation scope, worse code, and much higher costs at those settings. High can still support long, difficult workflows because the setting affects thought per step, not the total number of steps available.

Q: Does max reasoning let Fable 5 work for longer?

Max reasoning does not necessarily let Fable 5 complete more steps or remain active for a longer overall task. The reasoning setting applies to each tool call and change, so max primarily increases the thought spent on individual actions. For a workflow containing hundreds of steps, that added deliberation can waste resources because most steps do not require the same intensive reasoning.

Q: How can Fable 5 costs be reduced during long agent runs?

Fable 5 costs can be reduced by making it orchestrate other models instead of handling every part of the workflow itself. The creator taught it to use Codex and also involved GPT-5.5 for delegated work. Using this structure, a five-and-a-half-hour loop that might have been expected to cost thousands of dollars instead cost about $150 across Fable 5 and the other models.

Q: What work did Fable 5 complete on the Lakebed project?

Fable 5 helped process a large Lakebed backlog by closing, fixing, updating, recreating, and merging pull requests. The creator reported approximately 11 or 12 merged pull requests from one thread and a much larger burst of activity across two to three days. This was especially significant because Lakebed still had only one contributor and had previously stalled with roughly 20 or 30 unfinished pull requests.

Q: Why had the Lakebed pull requests stopped progressing?

The Lakebed pull requests had stopped progressing because many were only 50% to 80% complete, and the creator did not trust parts of their implementation. In particular, the SDK changes were unsatisfactory, confidence in the overall work was low, and manual cleanup appeared too time-consuming. New ideas continued generating more pull requests, but the existing backlog remained unshipped.

Q: What makes Fable 5 different from Opus for coding tasks?

Fable 5 differs from Opus primarily in how far it can carry a software task, not merely in producing smarter code. It can move across implementation, testing, verification, task decomposition, subagent delegation, code repair, and merging. As a result, giving it the same prompts previously used with Opus may produce only modest gains and miss the end-to-end workflow that distinguishes it.

Q: What productivity improvement did the Fable 5 workflow produce?

The creator reported completing more work on the first day after Fable 5 returned than during the prior month. Across two to three days, the model helped clear a substantial pull request backlog, including approximately 11 or 12 merges from one thread. The description characterizes the result as shipping a month of backlog in three days, even while the creator spent part of that period at a conference and worked from a phone.

Summary & Key Takeaways

• Fable 5 delivered its strongest results when assigned complete software outcomes rather than isolated coding prompts. The model handled implementation, testing, verification, code fixes, and merges while breaking larger jobs into smaller delegated tasks. This broader workflow helped the creator finish previously stalled work and regain confidence in changes that were ready to ship.

• Cost control depended on using Fable 5 as an orchestrator rather than making it perform every operation itself. During a five-and-a-half-hour loop, it called other models, including Codex and GPT-5.5. The resulting workload cost about $150, far below the thousands of dollars the creator initially expected such extended work to require.

• Reasoning effort should remain at high or below because higher settings can encourage excessive reconsideration. According to the creator, xhigh and max think more during each step but do not necessarily complete more steps. This can produce longer loops, broader changes, worse code, and substantially higher costs without improving the completed software outcome.