How I Run AI Agents: Fable for Planning, a Slim Harness for Execution

TL;DR

My current AI-agent setup starts with a simple rule: think before touching the repository.

I use plan mode as the read-only room where a model can inspect the work, compare approaches, and argue about risk without changing files. For that planning pass, I reach for Fable 5 first. I keep Fugu Ultra xhigh available as another high-reasoning lane, and GPT-5.5 Pro as a backup I rarely open now, but Fable has become my preferred planner.

Then execution moves into a slimmer harness. In oh-my-opencode-slim, roles like orchestrator, explorer, fixer, and librarian are shaped around different jobs. The execution-heavy roles run on GPT-5.5 high because they reward speed, reliability, and bounded changes. The point is not to crown one model forever. The point is to route the right kind of thinking to the right kind of work.

The surprising part: better planning did not reduce downstream usage. It increased it. When Fable produces a cleaner plan, there are more well-shaped tasks for execution agents to run.

Why I Start in Plan Mode

Plan mode is the safest place to spend reasoning.

When a model is allowed to edit files immediately, a bad idea becomes state. It leaves diffs behind. It can force cleanup work. It can make the next agent reason from a messy intermediate position. That is tolerable for tiny changes, but it is expensive for anything with architecture, deployment, or public writing involved.

Read-only planning changes the cost profile. The model can inspect the repository, read the tests, map the issue tracker, and propose a sequence. If the plan is wrong, nothing broke. If the plan is good, it becomes a contract the execution agents can follow.

That distinction matters more as agents get stronger. A powerful model can make a plausible change quickly. That does not mean it made the right change. I want the strongest reasoning to happen before the harness starts mutating the project. In practical terms, that means I spend more time asking: What is the boundary? What should not change? What proves this worked? What follow-up should be filed instead of smuggled into the current diff?

Plan mode is where those questions belong.

Why Fable Is My Planner

For planning, I currently prefer Fable 5.

That is a working preference from real projects, not a universal benchmark claim. I have tried Fable, GPT-5.5 Pro, and Fugu Ultra. GPT-5.5 Pro is still capable, but it has become the fallback I rarely open. Fugu Ultra xhigh stays in the rotation as a high-reasoning option, especially when I want a second serious look at a hard problem. But if I am starting a coding session and need a plan I can trust, Fable is the first model I reach for.

The difference shows up less in flashy output and more in shape. Fable tends to produce plans that are easier to hand to a working harness: clear sequencing, fewer vague branches, better sense of what should be tested, and a stronger instinct for when a question needs to be answered before implementation starts.

That is what I want from a planner. Not a motivational paragraph. Not a giant implementation dump. I want the model to turn ambiguity into a bounded work graph.

Testing Fable at high vs xhigh

I am also testing Fable at high instead of xhigh for some planning work.

The tradeoff is familiar: xhigh can be deeper and more careful, but it is not always the right default. If the work is well-scoped and the repository already has strong tests, high may be enough. If the decision has long-term architectural consequences, or if a wrong answer would cause expensive cleanup, xhigh is easier to justify.

This is the same token-minimizing discipline applied to reasoning effort. Use enough thinking to protect the work. Do not use maximum thinking as a reflex.

The important part is that escalation stays available. I do not want every task to start at the most expensive setting, but I also do not want hard decisions squeezed through a cheap lane just because it feels efficient in the moment.

Planning Drives Execution

One of the counterintuitive effects of better planning is that it creates more execution.

Before I had strong plans, some tasks died in the fog. The model would explore, patch, rerun, and summarize, but the next step was not always obvious. Better planning turns that fog into a queue: add the test, write the article, update the index, run the build, ask the designer, ask the reviewer, deploy, smoke, archive, close the issue.

Each item is smaller. Each item is safer. But there are more of them.

That is why my downstream GPT-5.5 high usage went up after I started planning with Fable. A cleaner plan gives the orchestrator and specialists more bounded work to do. It is a good problem, but still a real capacity problem.

The public-safe version is simple: I run more than one signed-in subscription session, and when one weekly limit is exhausted, I move to the next. I do not think of that as a hack so much as a sign of where the workflow is going. Better plans make agents more useful, and useful agents get used.

Inside oh-my-opencode-slim

oh-my-opencode-slim is my slim harness for this style of work.

The word slim matters. I do not want the harness to become a second operating system. My MCP servers live in the main config. The harness should mostly do one job: keep agent orchestration low-overhead and role-aware.

The model mapping is intentionally role-class based, because exact weekly routing changes. Planning goes to Fable. Execution-heavy roles run on GPT-5.5 high. The orchestrator defines the boundary and schedules work. The explorer maps the codebase when context is missing. The fixer makes bounded changes and validates them. The librarian checks current library or external documentation when stale knowledge would be risky.

Then there is the oracle lane. I reserve that for genuinely hard decisions: architecture, security, simplification, or review after a change touches enough surface area that a second senior pass is worth the cost.

This is not about pretending agents are employees. It is about reducing wandering. If the explorer is exploring, the fixer is not wasting steps rediscovering the repository. If the fixer is fixing, the orchestrator is not doing all the typing. If the librarian is checking the docs, the rest of the system is less likely to build on stale assumptions.

Good roles make handoffs smaller. Smaller handoffs make context cheaper. Cheaper context makes the next agent more reliable.

The Discipline Underneath

This setup is just the operational version of the discipline I wrote about in Commitmaxxing & Tokenminimizing.

Commitmaxxing makes useful progress durable. Tokenminimizing makes the next step cheaper to understand. Plan mode protects the repository before anything changes. Fable helps turn uncertainty into a work graph. GPT-5.5 high handles the bounded execution. oh-my-opencode-slim keeps the roles narrow enough that the whole system can move without becoming mushy.

The goal is not to automate taste away. The goal is to protect it.

AI agents are powerful, but they are also hungry for context. The more I use them, the more I believe the main craft is not prompting harder. It is designing the workflow so the right model sees the right slice of the problem at the right time, with a test or review gate waiting at the end.

That is the difference between a model doing a task and a system getting better at work.