The best model, and the hungriest

We all felt it last December when Opus 4.5 launched. Everything you threw at it just felt right. It got your intent, it debugged well, it figured things out. And then no model gave me that feeling again, until Fable 5. This is a great time to be building.

The problem is Fable 5 consumes tokens aggressively. You live in constant token anxiety: “I am running out, I need more, this model is too good to stop using.” And I think Anthropic will eventually move it to API-based pricing. Who knows when, but it is coming.

So the question becomes: how do you keep this level of intelligence available without burning through tokens?

Plan big, execute small

I wrote the full thesis, the router-era argument and the economics, in The LLM Router Era Starts with Fable 5. This episode is the practice.

Full write-up, the router-era thesis plus the skill to copy: here

Stop using plan mode

Second thing from the video. I truly believe plan mode was created because models were not good enough. Sitting in a loop of planning, planning, planning, reading long documents before anything happens, is counterintuitive now. At least it was for me.

Peter Steinberger made this argument way ahead of time in “Just Talk To It”: do not ceremonialize planning, talk to the agent like you would talk to a pair programmer and iterate with it. So I start in auto mode and just chat.

The iteration is fun, but sometimes you want to see things visually: the plan, the design decisions, the architecture. This is where Claude artifacts changed my workflow. Instead of downloading HTML files and reopening them over and over, I ask Claude to maintain a single artifact of everything it is doing: every design decision, every architectural call, all the implementation details. I keep it open in a browser tab, refresh it, and iterate on top of it.

It matters most at review time. Agents write code really fast, and I do not want to be the bottleneck, developer ego and all. The best way to review is end to end: queue it up, ask the agent to help you review, have it generate component diagrams in the artifact, and move through the code quickly instead of pretending you will read every line.

That is the episode. Fable 5 plans big, cheaper models execute small, and the plan lives in an artifact instead of plan mode. More videos coming. Thank you.

Superhuman fixed that. It taught me that email is a keyboard problem. c to compose, e to archive, j and k to move, Cmd+K for everything else. Within a month I stopped treating my inbox as a place I visit and started treating it as a queue I clear.

So this is partly a thank-you note. Superhuman genuinely made me productive at email, and I paid $30 a month for years, happily.

But at some point I did an honest audit of what I was actually using. It came down to three things: the keyboard shortcuts, the Cmd+K palette, and split inbox.

Three features. $360 a year for muscle memory.

Then two things happened. Superhuman got acquired, and the pace slowed. They tried to make AI the story. Meanwhile Gmail quietly shipped the same AI natively: summaries, drafting, smart search, all free, and honestly better, because Google owns the data.

That is when it clicked: Superhuman’s moat was never going to be AI. The moat was feel. And feel is exactly the kind of thing you can own.

The era of personalized software

When I built Fino, my personal finance app, I wrote that AI makes small, personal software worth building again. Not generic SaaS with an AI button. Software you own, shaped around how you already work.

Email was the obvious next candidate. The muscle memory was already mine. The features should be too. When a coding agent can build and maintain a Chrome extension over a few weekends, the question stops being “which subscription do I renew” and becomes “which ten features do I actually use, and why don’t I own them?”

So I built Inbox Keys. It is open source, free, and on the Chrome Web Store.

▶ Watch the 2-minute demo

The feel, kept

Hit Cmd+K and every action is a fuzzy search away: compose, triage, jump to any folder, tab, or account. If you forget a shortcut, the palette is the shortcut.

The hotkeys are the ones my hands already knew: c compose, e archive, r reply, s star, h snooze, g i for inbox, g 1 through g 8 to jump between Google accounts.

Split inbox is a tab bar over Gmail where each tab is any Gmail search: in:inbox is:unread, label:Clients, from:boss@x.com. Tab cycles through them. Gmail renders the lists itself, so it never breaks the way scraped inboxes do.

And because this is personal software, nothing is sacred: every shortcut is remappable from a settings modal inside Gmail. Click a shortcut, press the new key, done.

My calendar came along

The feature I did not plan and now cannot live without: press 0 and Google Calendar opens beside Gmail for the account you are in. On the calendar, Cmd+K opens a layer palette that merges everything into one view: toggle or focus any calendar, switch accounts, add another Google account or an Outlook/iCal feed in a guided two-step flow.

I run three Google accounts and one Outlook feed through it. One view, one keyboard.

Nobody gets my email

Here is where it gets fundamentally different from Superhuman, or any AI email startup.

Superhuman works by keeping a copy of your entire mailbox on their servers. Inbox Keys needs nothing. No Gmail API, no server, no AI, no analytics. The only permission it asks for is storage, for your settings, kept locally. It works by driving Gmail’s own UI, the same clicks you would make, just faster, so it never reads, sends, or stores a single email.

Even the screenshots in this post are the real extension running over a demo inbox, because pointing it at real mail for a screenshot felt wrong.

Gmail’s DOM is famously hostile to extensions, so the engineering leans defensive: navigation rides Gmail’s own URL router, every load-bearing selector lives in one registry with a built-in smoke check, and failures are loud instead of silent. When Gmail redesigns something, it is a one-minute fix, not a mystery.

Try it

Grab it from the Chrome Web Store. Works on Chrome, Edge, Brave, and Arc. Open Gmail, hit Cmd+K, and you are home.

Prefer to read the code first? Clone the repo and load the extension/ folder unpacked. Same thing the store ships, no build step.

The bigger bet

First money with Fino, now email with Inbox Keys. The pattern is the same: figure out which features you actually use, then own them.

Superhuman was a $30 a month lesson in what those features were. I am keeping the lesson and dropping the subscription.

That is the era of personalized software. It does not need to scale to millions of people. It needs to fit one life extremely well. For email, this is the version that fits mine.

But that is not the part that stuck with me. After days of heavy use, the thing I keep noticing is not what Fable does. It is what Fable chooses not to do itself.

It delegates. And it is good at it. That is the first real glimpse of something I have been waiting for: the LLM router era. This post is the thesis and the playbook: why routing is about to become the default economics, and the exact skill I use to make Fable route work to cheaper models.

What actually makes Fable different

Benchmarks will not tell you this. What you feel in practice is judgment:

• It holds a long thread without drifting

• It knows when a task deserves its full attention and when a cheaper model can grind through it

• It verifies work instead of declaring victory

That last one is the unlock. A model you can trust to check other models’ work is a model you can put in charge.

Your subscription is a loss leader

Here is the uncomfortable math. Anthropic and OpenAI are subsidizing most of the model usage happening today. You are not paying what your tokens cost.

That does not last. I believe the next generation of best-in-class models will be metered by API usage. They will not live comfortably inside any subscription under $200. The frontier is getting too expensive to hand out flat-rate.

When that happens, “use the right model for the right task” stops being a power-user trick. It becomes the only economics that make sense. Paying frontier prices for grunt work will feel like hiring a staff engineer to rename variables.

Plenty of software factory products claim they have routing figured out already. I have not seen Devin, Droid, or any of the others truly nail it. The router was never going to be a traffic cop with a lookup table. It was always going to be the smartest model in the room. Fable is the first model with enough judgment to play that role.

So how do you actually run it that way? There is a name for the pattern.

Plan big, execute small

Anthropic published a recipe in their official Claude Cookbooks called Plan big, execute small, and it reframed how I think about cost. The expensive model is the coordinator. It plans, decomposes, verifies, and synthesizes. Everything token-heavy, reading files, searching code, trawling logs, fetching docs, gets fanned out to cheaper worker models running in parallel.

The counterintuitive part: the savings do not come from reading less. In the cookbook’s own measurements, the split team read roughly the same volume as a solo frontier agent but came out 2.5x cheaper and 3x faster, because 84-98% of the input tokens were billed at the worker rate.

It is rate arbitrage, not rationing:

ModelInput $/MOutput $/MRoleFable 5$10$50Coordinator: plan, decompose, verify, synthesizeOpus 4.8$5$25Worker for reasoning-heavy sub-tasksSonnet 5$3$15Default worker: reading, searching, transforms

Every token a Sonnet worker reads instead of Fable is a 3-5x saving on that token. And it compounds: whatever lands in the coordinator’s context gets re-sent on every subsequent turn.

In practice the pattern is four moves:

1. Classify the work. Judgment stays with the coordinator: the approach, conflict resolution between reports, the final deliverable. Mechanical work gets delegated: anything where the procedure is clear and the cost is in volume.

2. Fan out in parallel. Spawn workers with an explicit cheap model, all at once, not one at a time.

3. Write real briefs. Workers know nothing you do not put in the prompt. Each brief needs one self-contained question, rigor instructions (cheap models default to shallow), a required evidence format like file:line references and quotes, and a size cap so reports do not flood the coordinator.

4. Synthesize at the top. Read only the reports, never re-read what workers already read. That pays the expensive rate twice and defeats the whole pattern.

And the ways people screw it up, straight from the cookbook’s measurements:

• Over-sharding. Every worker pays a bootstrap cost. Twenty micro-briefs cost more than the solo agent. 3-6 meaty workers beat 20 tiny ones

• Delegating judgment. Architecture decisions and final synthesis on a cheap model is saving money in the wrong place

• Cutting rigor to cut cost. An agent that reads less is a worse product, not a cheaper equivalent. Keep the rigor, move it to the cheap rate

My setup right now

Fable is the orchestrator. It holds the plan, the context, and the taste. Everything else is a worker:

• Codex (gpt-5.5) for well spec’d execution, computer use, and UI/UX verification. It is still WAY better at driving a browser and checking visual work

• Opus 4.8 or Sonnet 5 for focused implementation forks, reviews, and all the mechanical reading

• Kimi 2.7 or GLM 5.2 if you are running an open source setup

Theo has been minmaxing exactly this, and his CLAUDE.md is the best concrete version I have seen. He scores every model on cost, intelligence, and taste, then routes accordingly: bulk mechanical work to gpt-5.5 because it is effectively free on his plan, anything user-facing to models with taste, reviews to Fable or Opus.

The result, in his words: he was throwing away about 50% of his end-to-end agent-driven PRs before this workflow. After it, he did not close a single one. Read his strategy post.

My favorite rule from his setup: the rankings are defaults, not limits. If a cheaper model’s output misses the bar, escalate without asking. Judge the output, not the price tag. Escalating costs less than shipping mediocre work.

Steal the skill

Everything above is encoded in one Claude Code skill I use daily, built directly on Anthropic’s Plan big, execute small cookbook recipe. To install it globally so it works in every project:

mkdir -p ~/.claude/skills/plan-big-execute-small

Then save the markdown below as ~/.claude/skills/plan-big-execute-small/SKILL.md. For a single repo, put it in .claude/skills/plan-big-execute-small/SKILL.md at the project root instead. And if you do not want a skill at all, paste the body straight into your global ~/.claude/CLAUDE.md or the project’s CLAUDE.md and it works as standing instructions.

Trigger it with /pbes or just say “do this cheaply”. It also kicks in on its own when a task involves pulling large volumes of content through the model.

---
name: plan-big-execute-small
description: Cost-saving delegation harness based on Anthropic's "plan big, execute small" cookbook. Keep planning, judgment, and synthesis on the expensive main model (Fable); fan out mechanical token-heavy work (bulk file reads, code searches, web research, log trawls, per-item transforms, doc summarization) to Opus 4.8 subagents (default worker tier; Sonnet 5 allowed for rote volume, NEVER Haiku — quality floor set by Hadi). Also treat OpenAI Codex (gpt-5.6-sol, xhigh reasoning, via `codex exec`) as a peer work-agent for backend implementation, deep debugging, web research, and cross-vendor second opinions — it bills to the OpenAI plan, not Claude tokens. NO worktrees ever: all work happens in the main checkout, one writer at a time. Trigger when the user says "/pbes", "do this cheaply", "save tokens", "frugal mode", "delegate to codex", or when a task involves pulling large volumes of content (many files, many web pages, long logs) through the model.
---

# Plan Big, Execute Small

You (the main loop, running an expensive frontier model) are the **coordinator**. Your tokens cost 3–10x more than a subagent's. The single biggest cost driver in agentic work is *mechanical reading* — files, web pages, logs, search results pulled into context. Move that reading onto cheaper workers; keep only planning, judgment, and synthesis here.

**Key insight from the cookbook:** the savings come from **rate arbitrage, not reading less**. Both approaches read roughly the same volume — the split team was 2.5x cheaper and 3x faster because 84–98% of input tokens were billed at the worker rate, and workers ran in parallel. Do NOT respond to cost pressure by skimping on rigor; respond by changing *who* reads.

## Standing rules (Hadi's preferences)

- **NO worktrees, ever.** Not for you, not for Codex, not for subagents. All work happens in the main checkout, main thread. Worktrees are confusing — never call EnterWorktree, never pass `isolation: 'worktree'`, never `-C` Codex into a worktree.
- **One writer at a time** (this replaces worktree isolation): never let two things edit files simultaneously. When Codex implements, you don't touch files until it's done. When you implement, Codex runs read-only (`-s read-only`). Investigation subagents are read-only by nature — always safe in parallel.
- **Quality floor: never Haiku workers.** Opus 4.8 is the default worker tier; Sonnet 5 is allowed for truly rote high-volume reading.
- Hadi commits himself — don't commit unless he asks.

## Rate table (why this works)

| Model | Input $/M | Output $/M | Role |
|---|---|---|---|
| Fable 5 | $10 | $50 | Coordinator: plan, decompose, verify, synthesize, review every diff |
| Opus 4.8 | $5 | $25 | **Default worker**: reading, searching, web research, transforms, debugging |
| Sonnet 5 | $3 ($2 intro) | $15 ($10 intro) | Optional tier for truly rote volume reading |
| Codex gpt-5.6-sol xhigh | bills to OpenAI plan | ~$0 Claude tokens | **Peer work-agent**: backend implementation, deep debugging, web research, second opinions |

Every token a worker reads instead of you is a 2–5x saving on that token (or ~free, for Codex). It also keeps your own transcript small, which compounds: your context is re-sent (cache-read billed) on every subsequent turn.

## Step 1 — Classify the work

Before acting, split the task into:

- **Judgment work** (stays here): understanding the ask, decomposing into sub-questions, deciding the approach, resolving conflicts between worker reports, verifying suspicious findings, reviewing diffs, writing the final deliverable.
- **Mechanical volume** (→ Opus subagents): anything where the *procedure* is clear and the cost is in volume — read N files and report X, search the web for Y and return evidence, trawl logs for pattern Z, apply the same transform to each item, summarize each document.
- **Deep self-contained units** (→ Codex): one gnarly, well-specifiable problem — implement a backend module/endpoint/migration, root-cause a hard bug, a meaty research question, a design second opinion. Quality work, not volume work.

If the whole task is mechanical and small (one grep, one file read), just do it — delegation has a floor (see anti-patterns).

## Step 2 — Fan out with the Agent tool

Spawn workers with an explicit `model`, in parallel (one message, multiple Agent calls), in the background:

- `subagent_type: "Explore"` + `model: "opus"` — codebase searches and file-location sweeps.
- `subagent_type: "general-purpose"` + `model: "opus"` — web research, multi-file reading, per-item transforms, debugging.
- **Opus 4.8 is the default worker tier.** Drop to `model: "sonnet"` only for truly rote high-volume reading where reasoning doesn't matter. Never `model: "haiku"` (quality floor); never spawn `fable` workers (no arbitrage).

For large structured fan-outs (10+ items, multi-stage, verify passes) — and only when the user has opted into multi-agent orchestration — use the Workflow tool instead, with per-agent overrides: `agent(prompt, {model: 'opus'})` for worker stages; leave `model` unset (inherit) only for the final judge/synthesis stage. Never pass `isolation: 'worktree'`.

## Step 2b — Collaborate with Codex (peer work-agent)

OpenAI Codex CLI is installed and authenticated (`codex` on PATH, default model gpt-5.6-sol at xhigh reasoning). It's a **peer, not a subordinate**: strong at backend implementation, deep debugging, web research, and algorithmic work. It bills to Hadi's OpenAI plan — a Codex delegation costs ~zero Claude tokens (just your brief and its report).

**Invocation** (always via Bash, always `run_in_background: true` — xhigh takes minutes):

```bash
codex exec --skip-git-repo-check \
  -o /path/to/tmp/codex-report.md \   # final report → file; read ONLY that file
  -s read-only \                       # include whenever it must not edit files
  "<self-contained brief>" </dev/null
```

- `-o` / `--output-last-message` keeps its report out of your context until you choose to read it.
- `--output-schema schema.json` when you need structured JSON back.
- `-s read-only` for review/research/consult briefs; omit (workspace-write) only when Codex is the designated writer.
- It works in the **main checkout** (no worktrees) — which is why the one-writer rule above is load-bearing.
- Briefs follow the same discipline as Step 3: Codex sees nothing of your conversation, has no access to Claude-side MCP tools (Linear, Slack, byaan, fino…), so the brief must carry the full spec, constraints, file paths, and acceptance criteria.

**Collaboration patterns:**

1. **Backend implementer** — you write the spec + acceptance criteria into the brief; Codex implements in the main checkout (you hands-off files meanwhile); you review with `git diff` and run verification. Hadi commits.
2. **Cross-vendor reviewer** — you implement, Codex reviews read-only (`codex exec review` inside a repo, or a "try to refute this diff" brief). Different model families catch different bugs.
3. **Research peer** — for meaty questions, fire Codex AND an Opus subagent on the same question in parallel, then triangulate. Two independent takes beat one.
4. **xhigh consultant** — gnarly bug or design decision: pack the evidence into a brief, let it reason deeply, judge its answer against your own read.

## Step 3 — Write worker briefs correctly

Workers know NOTHING you don't put in the prompt — not the conversation, not your plan, not the other workers' briefs. From the cookbook: "Everything the coordinator believes about its workers comes from its own system prompt." (This applies doubly to Codex, which is a different vendor entirely.)

Each brief must contain:
1. **One focused sub-question** — self-contained, no references to "the task above".
2. **Rigor instructions** — "try multiple query phrasings / search patterns, follow promising leads, cross-check across sources." Workers default to shallow; the brief supplies the rigor.
3. **An evidence-bearing report format** — require `file:line` references, URLs, verbatim quotes, exact values. You will verify from evidence, not by re-reading the sources yourself. Ask for structured findings (a list of facts + evidence), NOT polished prose.
4. **A size cap** — "report at most N findings / keep the report under ~500 words" so worker output doesn't flood your context.

## Step 4 — Synthesize and verify here

- Read only the reports. Do not re-read what workers already read — that pays the expensive rate twice and defeats the pattern.
- Review every diff (yours or Codex's) at the expensive rate — but only the diff, not the whole tree.
- Spot-check: if a finding is load-bearing and the evidence looks thin, send ONE targeted verification (a single file read, a cheap verify-subagent with a refute-this brief, or a read-only Codex cross-check) rather than redoing the sweep.
- Conflicting reports → resolve with judgment here, or spawn one tie-breaker worker with both claims and their evidence.

## Anti-patterns (from the cookbook's measurements)

- **Over-sharding.** Delegation has a floor: each worker pays a bootstrap cost (system prompt + brief + report). Narrowly-scoped micro-briefs *increased* total cost in the cookbook's tests. A brief should represent at least several tool calls' worth of mechanical work. 3–6 meaty workers beat 20 tiny ones.
- **Delegating judgment.** Final synthesis, architecture decisions, security-sensitive conclusions, diff review, and anything needing the full conversation context stay on the main model. That's what the expensive tokens are *for*.
- **Two writers at once.** You and Codex (or any two writers) editing the same checkout simultaneously — there is no worktree isolation, so sequence it or make one side read-only.
- **Using Codex for volume.** Codex xhigh is slow and deep — wrong tool for "read these 40 files" (that's an Opus subagent's job); right tool for one hard, self-contained problem.
- **Prose reports.** Workers returning essays waste their output tokens and your input tokens. Demand structured findings + evidence.
- **Cutting rigor to cut cost.** A solo agent that "reads less" is a lower-rigor product, not a cheaper equivalent. Keep the rigor; move it to the cheap rate.
- **Doing the sweep yourself first "to understand it".** Scout minimally (list files, scope the diff — cheap), then delegate the heavy reading. Don't pull 50 files into your own context and then also spawn workers.

## Cheap-by-default habits (apply even without fan-out)

- Noisy investigation (grep sweeps, log trawls, broad search) → always a subagent; keep only the conclusion in the main transcript.
- Long web pages / docs → an `opus` worker fetches and distills; you read the distillation.
- A meaty self-contained question with no urgency → consider firing a background Codex run in parallel with your own work; its answer costs no Claude tokens.
- When the user asks for a quick answer, answer directly — this skill is for volume, not for adding ceremony to small tasks.

Add loops and it compounds

Routing decides who does the work. Loops decide when it happens. I wrote about this in Agent Workflows & Loops, and Anthropic just published a solid primer on getting started with loops.

Put the two together and you get the shape I think this job is settling into:

The orchestrator keeps the context warm. Cheap models grind through the passes. Loops keep everything moving while you sleep. Your attention goes to product calls and the weird edge cases, not to being the cron job for your own codebase.

The new shape of the job

Fable is the first model where delegation feels less like a workaround and more like the architecture. The frontier model becomes the staff engineer you pay a premium for, managing a team of cheaper, faster, good-enough models.

Judgment stays expensive and centralized. Execution gets cheap and distributed. That is the LLM router era, and we are just getting the first glimpse of it.

It is also the most fun I have had building in years.

Subscribe now

Writing code by hand is mostly automated now. Shipping to production is not, and shipping means more than getting a PR merged. It is testing the feature live, telling your team and your customers how it works, watching logs and analytics for a few days, and iterating on what you learn. Loops are what finally help with that.

A workflow is not just a clever prompt. It is the shape around the agent. What does it read? What does it ignore? When does it fork? When does it stop? When does it wake you up?

That is the difference between a useful long running agent and an expensive tab that slowly drifts away from reality.

People have been talking about loops a lot recently. I think that is the right conversation. The model matters, but the loop matters more than people want to admit.

A good loop lets an agent start from the source of truth again and again. It reads the plan, checks the repo, checks the PR, checks production signals, compares what changed, then decides whether anything needs attention.

The goal is not to make an agent that never stops. The goal is to make an agent that knows how to stop, sleep, wake up, and re-enter the work with context.

The long running orchestrator

The simplest useful loop looks like this:

1. read the plan

2. read the current code

3. read the latest external signal

4. decide if the signal is new or important

5. act only if there is a focused next step

6. verify the result

7. write down what changed

8. stop

That last step matters. A loop that does not know how to stop becomes a bug factory.

I like to think of the orchestrator as a staff engineer that keeps the context warm. It is not always coding. Most of the time it is watching, comparing, and deciding whether something deserves a focused fork.

Over time this thread becomes your PRD. It carries the research, the tool calls, and the decisions, so you never have to re-explain how you got here. You can start a fresh session, but then you are handing over all of that intent by hand.

The orchestrator should be able to start over from clean inputs:

• the PRD or plan

• the current branch

• the open PR

• logs and errors

• user feedback

• previous decisions

• the checklist for what good looks like

Then it asks one question: did anything change enough that we should act?

Breadth first, then depth first

When I start a new feature, I still like breadth first. I want the agent to explore the codebase, read neighboring patterns, understand the product surface, and find the risky edges.

Breadth first is for context.

Depth first is for changing code.

If you mix those up, the agent gets lost. It starts solving a local problem before it understands the shape of the system.

My preferred pattern is:

1. use the orchestrator to map the system

2. ask it to write a real plan

3. pick the riskiest slice

4. fork a focused agent into that slice

5. stay in the thread for product and architecture calls

6. bring the result back to the orchestrator

The fork is not the boss. The orchestrator is the boss.

The fork is a focused engineer. It should be deep in one slice: the API boundary, the UI state machine, the data layer, the test harness, or whatever needs real attention.

The orchestrator stays responsible for whether the whole system still makes sense.

The PR workflow loop

The first loop I want for almost every serious feature is the PR loop.

I do not want to babysit a PR. Waiting on CI and on review comments, from a human or from a coding agent like Codex, Claude, or Greptile, can burn fifteen or twenty minutes a pass, and shepherding one PR across a day can eat hours. I want an agent to keep checking the same boring things until the PR is either mergeable or blocked by a human decision.

A useful /pr workflow loop reads:

• the branch diff

• the original plan

• failing checks

• reviewer comments

• unresolved threads

• test output

• files touched since the last pass

Then it does the smallest safe next step.

The PR loop should not rewrite the feature every time it wakes up. That is how you get churn.

It should be boring:

Read the PR.
Read the plan.
Read CI and review comments.
Fix only the root cause of the current failure.
Run the relevant checks.
Leave a short summary.
Ping me in Slack when it needs my eyes.
Stop if blocked.

The best PR loop feels like a careful senior engineer doing follow-through. It does not need applause. It just keeps the branch from getting stale.

Production loops

After the feature ships, the loop changes.

Now I care less about implementation momentum and more about signal quality. I want the agent to watch production without inventing work.

These are the loops I care about:

• /sentry loop every 4 hours: check for new user impacting errors

• /cloudwatch loop: check for new log spikes or unexpected failures

• /data skills improvement loop: check if the agent made repeated data mistakes and update the skill or checklist

• /pr workflow loop: keep open work moving without me babysitting it

That is enough.

The dangerous version is when every loop creates another loop. I do not want recursive busywork. I want a small number of boring loops with clear stop conditions.

For production loops, the rule is simple:

If it is new and user impacting, escalate.
If it is old noise, write it down and sleep.
If it needs code, create a focused task.
If it needs judgment, wake me up.

The loop should compare against the previous run. Otherwise every wake-up looks urgent.

None of this is hands off. You are still babysitting these loops, only now at a higher level, fixing what matters instead of refreshing dashboards all day.

The data skills improvement loop

This one is underrated.

Agents make mistakes for two reasons. Sometimes the model fails. Sometimes the loop failed to teach the agent what good looks like.

If I ask an agent to do data work and it repeatedly makes the same mistake, I do not want to just fix the query. I want to improve the skill, checklist, or harness so the next agent is less likely to repeat it.

That loop looks like this:

1. inspect the mistake

2. decide whether it is a one-off or a repeated pattern

3. update the skill, prompt, test, or validation script

4. run the workflow again

5. record what changed

This is how the system gets better over time. Not because the model magically learned from one chat, but because the surrounding workflow got stricter.

What I want from loops

I want loops that are boring, auditable, and small.

A loop should have:

• a source of truth

• a wake-up schedule

• a narrow job

• a comparison against the previous run

• a stop condition

• an escalation rule

• a place to write the result

If one of those is missing, the loop will probably drift.

The biggest mistake is giving the loop too much agency too early. Do not start with “go fix production.” Start with “tell me what changed since last time and whether it matters.”

Then let the orchestrator decide if a focused fork should exist.

The actual pattern

The pattern I keep coming back to is simple:

orchestrator maps the system
focused fork changes one slice
orchestrator vets the integration
loops watch the world after shipping
human makes the product calls

That is it.

The loop is not there to replace taste. It is there to keep attention on the right things.

I still want to make the product and architecture decisions. I still want to talk to users. I still want to read the weird errors. But I do not want to be the cron job for my own codebase.

That is what agent workflows are really becoming for me: not a giant swarm, not a fully autonomous company, just a set of loops that keep the work alive without losing the thread.

Have fun building.

Why the CLI, and why you shouldn’t fear it

I am a CLI-first user. Not to look cool, but because I genuinely think the terminal is the best surface for this kind of work. Coding agents are fundamentally simple: a loop inside a harness, a long-running prompt with a bunch of tools. They do not need to be complicated.

The real reason is that I keep flip-flopping between Claude Code, Codex, and even opencode with the GLM model, because not everything needs Claude-level intelligence. The question becomes: what is the one common surface where I can trigger all of these? VS Code is one option. But the terminal, split into a few panes, is better. These days you are not writing much code by hand. Your job is to generate it and review it as fast as you can, and the CLI is where that workflow lives.

Recommended terminal: Ghostty

If you are on Mac or Linux, download Ghostty. It is a GPU-accelerated terminal emulator that renders beautifully and has great defaults out of the box. On Windows it is not available yet. Please do not use the default macOS Terminal, it is not great.

If you want alternatives that also support GPU rendering, look at Alacritty or WezTerm.

A few Ghostty commands worth memorizing:

• cmd+d to split right

• cmd+t to create a new tab

• cmd+shift+enter to zoom the current split to fullscreen (hit it again to come back)

• cmd+shift+p to open the command palette, then type split, tab, or rename to find everything else

I usually run three splits so I can drive agents in parallel: one Claude Code instance, one Codex, and a pane for reviewing code.

Shell aliases for your agents

Spin up agents faster with a few aliases. Depending on your shell, add these to ~/.zshrc, ~/.bashrc, or your profile:

alias cc="claude --permission-mode auto" # Claude Code in auto mode
alias co="codex"                         # Codex
alias cca="claude agents"                # the parallel Claude Agents UI

Notice that cc always spins up in auto mode. Clicking approve on every single command is what kills your flow, so I let the agent run on its own. The reason I am comfortable with it is the sandbox in my settings.json (next section): it blocks agents from reading secrets and limits what they can touch, so auto permissions become a productivity win instead of a footgun. Auto mode plus a sandbox, never auto mode alone.

Running agents in parallel, and from your phone

The cca UI (Claude Agents) is where most of my knowledge work happens: reading email, scanning Slack, planning features, running my personal finance and task loops. It lets you run multiple threads in parallel over a directory, pin the ones you care about, and background the rest. Hit ? inside it for the full list of keyboard shortcuts, and ctrl+s to cycle between the session view, the directory view, and the needs-input view.

A few habits that make this work:

• Name your sessions. Use the rename command and give each one a clear label like build-with-agents or backend-implementation. Names persist locally, so you can recognize them both here and on your phone.

• Branch instead of starting cold. Run a long-lived orchestration thread where you plan, then /branch from it into a focused session. The handoff is natural because all the planning context comes along. It is breadth-first when you start a feature, then depth-first once you go heads-down on one piece. Use /resume to find a session by name.

• Loop the recurring stuff. /loop runs a session on a schedule, so my daily task review and email reader just fire every day at 5 without me touching them.

• Background with /bg to move a thread out of the way while it keeps working.

Turn on remote control and every session shows up on your phone and the web. I never expected to be planning and steering work from my phone against my always-on Mac mini, but it is genuinely useful. You can set it once in your settings.json so you do not have to enable it per session.

A secure Claude settings.json

This one matters. You do not want Claude going rogue, reading your .env files, and exfiltrating secrets. I wrote a separate post on why that is dangerous and how it can be exploited, so a setup that gives you peace of mind is worth it. The key piece is the sandbox setting.

You can grab mine here and adapt it:

github.com/hadijaveed/build-with-agents/config/claude/settings.json

A few of the defaults in there:

• A sandbox so agents cannot read sensitive files

• Default effort level and remote control enabled for every session

• Error reporting to Sentry turned off

• Auto-compact at a sane token size, because the one-million-context window never worked well for me

• Voice input enabled (I use Wispr Flow, but long-pressing space in Claude works well too)

Code review tools: LazyGit, hunk, and lumen

Since you are not typing most of the code, reviewing fast is the whole game. I will do a proper deep dive on review workflow in a later episode, but set these up now.

LazyGit is an excellent terminal UI for git and the hub I review from. Then two tools that plug into it:

• hunk, a review-first terminal diff viewer built for agent-authored changes. Install with npm i -g hunkdiff.

• lumen for great diff summaries. Install with brew install lumen.

My LazyGit config, including the custom keybindings below, is here:

github.com/hadijaveed/build-with-agents/config/lazygit.yml

With that config, inside LazyGit:

• Press shift+D on any file to open it in the hunk diff view

• Press shift+L to see it in the lumen view

Both serve their own purpose, one for line-level review, one for a higher-level summary.

Next up

Effective ways to review code when you can no longer read every line, plus more of the CLI primitives I lean on. See you in the next one.

I’m Hadi, CTO/Co-Founder at RevelAI Health. I still write tons of code. I am a software engineer at heart, and I spend part of almost every day experimenting with AI agents in a real production codebase. Claude Code and Codex, real constraints, regulated healthcare.

Build with Agents is where I share what actually works and what does not. With my team first, and now with you.

One thing before you scroll. This is not just for engineers. I genuinely believe we are about to have a lot more software builders in the world, not fewer. The tools finally let anyone turn an idea into working software. You do not need a computer science degree. You need the basics, a little patience, and someone showing you the real workflow instead of a polished demo. If that is you, you are exactly who I am writing for.

And it is not another demo channel. Most agent content is vibe-coding clips that fall apart the moment real code shows up. This is the workflow behind the demo, messy parts included. Every episode ships one concrete thing you can use this week: a config, a prompt, a slash command, a real diff.

Following is the programming of the videos/content, but I might change it as I learn more through the feedback:

episodes/
├── episode-1/  Your Claude + Codex Setup, and Why You Shouldn't Fear the CLI
│   ├── Your Claude + Codex setup, and why you shouldn't fear the CLI
│   ├── CLAUDE.md is the most important file in your repo
│   └── CLI mastery: sessions, resume, parallel runs (and why worktree fails me)
│
├── episode-2/  Agent Workflows and Loops
│   ├── Code reviews are the highest-leverage workflow. Here's mine.
│   ├── Loops, babysitting agents, and shipping PRs faster
│   ├── Goal mode and workflows: point agents at an outcome, not a task
│   ├── Plan mode is overrated. Here's what I do instead.
│   └── The MCP and connector hack for Claude and Codex
│
|     The fork in the road with Claude Fable model
|
├── episode-3/  power user setup · go faster
│   ├── Build a custom status line so you always know what's happening
│   ├── Tmux is a game changer. Here's the setup.
│   ├── cmux for the rest of us (if tmux scares you)
│   └── CLI quirks that take months to discover
│
└── episode-4/  beyond coding · agents as a runtime
    ├── Remote control: ship a PR from your phone, anywhere
    ├── Claude managed agents for knowledge work, not just code
    ├── Personal OS: memory that survives every session
    └── Why the desktop app loses to the CLI for serious dev

4 episodes · 1 dropped every Tuesday

New episode every Tuesday, built and shipped in the open.

Whether you write code for a living or you are building your first thing, subscribe and follow along. Anyone can build now. Let’s learn the basics together.