How to Actually Get Value out of Claude Code: Fable 5, Opus 4.8, and Session Discipline

Treat Claude Code like a brilliant engineer with amnesia and a meter running. It reasons like a senior, forgets everything the moment the context resets, and bills you by the token. Almost every mistake people make with it comes from ignoring one of those three facts. Get them right and the same tool goes from "impressive demo" to "does a day of real work while you review."

This is the workflow we actually run, cross-checked against Anthropic's own Claude Code best-practices docs. No theory you won't use. Just the handful of moves that change the output.

Route by task, not by loyalty

Most people pick one model and marry it. That is how you either overpay on everything or ship sloppy work on the jobs that mattered. The skill is routing: match the model to the shape of the task in front of you.

Here is the current lineup and what each one is actually for.

The counterintuitive part: on short, well-scoped tasks, Fable 5 and Opus 4.8 perform nearly identically. Rename a function across a file, write a test for a known function, wire up an endpoint that matches five others, and you cannot tell which model did it. You just paid double for one of them.

Fable's lead shows up when the horizon is long. A three-hour migration across forty files, a research pass through a codebase you have never seen, an autonomous run that has to hold a plan in its head and not drift. That is where the extra reasoning stops being a luxury and starts being the difference between a clean diff and a mess you have to unwind. So the rule is simple: Opus by default, Fable when the task is long and unforgiving, and pay the 2x only then.

Downshift just as deliberately. If the job is "find every call site of getUser" or "label these 300 log lines by error type," that is Haiku work. Spending Opus tokens on it is like sending a principal engineer to alphabetize a folder.

Plan with a bigger model, build with a cheaper one

The most expensive tokens you spend are the ones spent going the wrong direction. A plan is cheap insurance against that.

For anything that touches multiple files or has real uncertainty, use plan mode first. Let the strong model reason about the approach, name the files it will change, and flag what could break, before it writes a line. Then hand that plan to a cheaper model, or a fresh session, to execute. The plan is the hard thinking; the build is mostly typing.

Skip planning when you can describe the diff in one sentence. "Add a createdAt index to the messages collection" does not need a planning phase. Reserve the ceremony for the changes where being wrong is expensive.

Short sessions win. Every time.

This is the one that separates people who get real work out of Claude Code from people who fight it all afternoon.

Context fills fast, and model quality degrades as it fills. A model reasoning over 300k tokens of half-relevant history is measurably worse than the same model on a clean 20k-token context. It starts referencing the file you abandoned twenty minutes ago, re-litigating decisions you already made, and confidently repeating a mistake you thought you corrected.

So keep each session on one job, and reset often. Our working rule: after two or three turns, or a couple of finished tasks, run /clear and start fresh. Switching from "build the auth flow" to "fix the CSS on the dashboard"? That is a new session. The auth context does nothing for the CSS work except crowd it out.

And the sharpest signal of all: two failed corrections on the same issue means the context is polluted. If you have told the model twice what is wrong and it still misses, stop arguing with it. It is now reasoning over a transcript full of its own wrong turns. /clear, and rewrite the prompt from scratch with everything you just learned baked in. A clean session with a better prompt will fix in one shot what a poisoned session would fight you on for ten.

Arguing with a confused session is the single biggest time sink in agentic coding. The fix is almost never a better argument. It is a fresh context.

Write the handoff down so any session can resume

Because sessions are short and memory resets, the thing that carries work forward is not the chat history. It is a written spec.

Before you clear a session that has figured something out, ask it to write the handoff itself: a self-contained brief that a brand-new session (or a different model, or a teammate) could pick up cold. A good one has three parts:

• The files involved. Exact paths, and what role each plays.
• What is out of scope. An explicit "do not touch" list. This is the part people skip, and it is the part that stops a fresh agent from cheerfully refactoring things you did not ask it to.
• A verification step. How the next session will know it succeeded: a test to pass, a command to run, a screenshot to match.

Then open a fresh session and give it only that spec. This is the official handoff pattern, and it is the closest thing to giving your amnesiac engineer a set of notes on their desk each morning. The clean session executing a tight brief beats the hour-old session every time.

Make it prove the work

Left alone, a model stops when the code looks done. It does not stop when the code is done, because it has no way to tell the difference unless you give it one.

So give it a verification loop. A test it has to make pass. A build whose exit code it has to check. A screenshot it has to compare against the target. The moment the agent can observe the result of its own work, its behavior changes: it iterates until the check is green instead of declaring victory and handing you something that throws on the first click.

"Add the feature and make npm test pass" is a fundamentally different instruction from "add the feature." The first one has a finish line the model can see. The second one has a finish line only you can see, which means you become the test suite.

Delegate the reading to cheap subagents

Investigation is expensive in the worst way: it fills your main context with material you needed for ten seconds. "Read these eight files and tell me where the rate limiting lives" can burn 40k tokens of context you now carry for the rest of the session.

Push that work to a subagent. It burns its own context on the reading and returns you a short summary. Your main session stays lean and focused on the actual change. Point Haiku or Sonnet at the grunt investigation and keep your expensive brain for the decisions.

The same trick has a second payoff: use a fresh-context reviewer for code review. A model that just wrote 400 lines is biased toward them. It reasons about the code the way an author reasons about their own draft, defensively. A separate session that has never seen the code, handed only the diff and the requirements, will catch things the author is blind to. Do not ask the writer to grade its own paper.

Spend tokens like they cost money, because they do

A few habits compound over a heavy week of building.

• Keep CLAUDE.md short. Every line in it loads into context on every session. It is a standing tax. Put the rules the model needs each time (build commands, hard constraints, house style) and nothing else. A 400-line CLAUDE.md is 400 lines you pay for before you have typed a word.
• Move deep knowledge into skills. Situational knowledge does not belong in the always-on file. Put it in a skill that loads on demand, so it costs tokens only when it is relevant.
• Compress output on grind sessions. Most of what a model writes is connective prose you skim past. Terse output modes (the community "caveman" plugin is the well-known one) cut response tokens by roughly 75% while keeping the technical content intact. Keep full prose for planning, where clarity earns its cost. Switch to compressed for the long repetitive stretches.

None of these change what the model can do. They change how much runway it has before its context gets crowded, and how much you pay for the same result.

Do not trust the model on anything past its training cutoff

A model knows the world up to its cutoff and not one day past it. Library versions, API shapes, pricing, breaking changes in a framework's latest release: all of that drifts, and the model will answer confidently from a stale snapshot.

For anything version-sensitive, make it check a primary source. Turn on web search, or paste the current docs into context, and have it work from what is actually true today rather than what was true when it was trained. This matters most for exactly the things that break silently: an install command that changed, a config key that got renamed, a method that was deprecated last quarter. Even the pricing table earlier in this post is the kind of thing worth verifying against the source before you bet a budget on it.

The whole thing in one breath

Write the spec down so any session can pick it up. Keep each session on one job. Make it prove its work with a test. Delegate the reading to cheap subagents. And buy the expensive brain only for the marathon.

That is the entire discipline. Everything above is just those five moves with the reasoning attached. The engineer is brilliant. It has amnesia. The meter is running. Work with all three and Claude Code stops being a toy you poke at and becomes something that closes real tickets while you review the diffs.

Where this shows up in practice

This is the same philosophy we build on at Casagbic, an AI app builder where you describe an app in plain English and orchestrated agents build and deploy it, with code you own at the end. Under the hood it routes work across models, keeps agent contexts scoped and short, and makes agents verify their output instead of stopping when it looks done. The playbook above is not marketing gloss on top of it. It is how the thing actually runs.

Frequently asked questions

The models will keep getting renamed and repriced. The discipline underneath will not. Route by task, keep sessions short, write the handoff down, and make the agent prove its work. That is the part worth learning.

Want to watch agents build a real app on this exact playbook, with code you own at the end? Try it on Casagbic →