The free period for Fable 5 ends on July 7th.
Today is July 3, 2026. In other words, the time for "using Fable because it's free" is ending in a few days, and from July 8th, it will move to a usage-based credit system.
So, what do we do from July 8th?
Sonnet 5 is available on all plans, including Free.
The introductory price until August 31st is $2 per 1 million input tokens and $10 per 1 million output tokens. After that, it will be $3 for input and $15 for output. Fable 5 is $10 for input and $50 for output.
Even at regular prices, it's about a 3.3x difference. Compared to the introductory price of Sonnet 5, it's 5x.
Moreover, Sonnet 5 has a 1M context window and 128k output. The capacity to read long documents and code is the same as Fable 5.
If so, is the only thing missing really just "performance"?
My conclusion is slightly different. The secret to Fable 5's strength isn't just intelligence. It's behavior.
Thinking long. Defining success conditions first. Doubting. Verifying. Taking notes. And finally, reporting honestly on what was achieved and what wasn't.
A significant portion of this behavior can be baked into CLAUDE.md and environment settings.
CLAUDE.md is a configuration memo that Claude Code reads constantly, telling it "how to act in this project." It's not a prompt you paste into every chat. It's an instruction placed in the environment itself.
The techniques of those who paste prompts every time are also strong. Making it create victory conditions, comparing drafts, breaking things down, and finishing. That pattern is very effective.
However, you forget things you have to paste every time. The longer they are, the more tedious they become. They disappear when the session changes.
That's why this time, we are making it permanent.
To borrow a phrase trending overseas:
Prompts are temporary. Structure is permanent.
In this article, I will provide CLAUDE.md settings to bring Sonnet 5 closer to Fable 5 in a copy-pasteable format.
Moreover, these aren't just settings I came up with.
Using Claude Code's headless mode—specifically, asking via claude -p from the terminal—I interviewed both Sonnet 5 and Fable 5 themselves.
Asking the junior, Sonnet 5, about its own weaknesses.
Asking the senior, Fable 5, how to train the junior.
This double interview led to some very interesting answers.
The True Identity of Fable 5 is "Persistent Behavior"
When you use Fable 5, it is certainly smart.
But if you look closely at the output, its strength isn't just the amount of knowledge. The way it approaches work is different.
It doesn't start building immediately. It defines success conditions first.
It doesn't trust its own ideas right away. It looks for where things might fail first.
It doesn't just say "it worked." It shows what it used for verification.
It doesn't fill gaps in knowledge with pretenses of understanding.
And even in long tasks, it tries to maintain the initial constraints until the very end.
This is easy to understand if you replace it with human work.
Fable 5 looks like a highly capable senior. Even when given an ambiguous request, before rushing off, it comes back and asks, "What does success look like in the first place?" If a plan fails, it discards the plan and starts over.
Sonnet 5 is a highly capable junior. Fast. Obedient. Faithful to instructions. However, without structure, it can answer too fluently.
In that case, we just need to give the junior the senior's work habits.
The place to put that is CLAUDE.md.
Clear Weaknesses Identified by Interviewing Sonnet 5 "Itself"
First, I asked Sonnet 5 itself.
"What should I write in CLAUDE.md to produce Fable 5-level results?"
The self-analysis it returned was quite honest.
Sonnet 5 said this about itself:
"I tend to answer fluently, and uncertainty is often hidden in my writing style."
This is important.
AI answers can be dangerous when the writing is good. If it's written clearly, humans tend to believe it. But in reality, it might contain "maybe," "unconfirmed," or "this part is suspicious."
Therefore, the first setting to include is this:
**Make it explicitly state confidence levels for uncertain parts.
Do not let it hide behind ambiguous adverbs.
If confidence is low, make it confirm before proceeding.**
The reason it works is simple. It can no longer hide anxiety within its writing style.
Next, Sonnet 5 admitted it tends to "implement first and adjust later." To stop this, make it write success conditions first.
Before writing code or text, have it output premises, verifiable success conditions, and failure modes. Not "it works" or "feels good," but in a form that can be judged as tests, outputs, screens, or specific text conditions.
What's important here is to make success conditions a "judgment" rather than a "mood."
"Make a good article" is weak.
"Mention the July 7th deadline at the beginning. Include the price difference. Place 6 or more copy-paste settings for CLAUDE.md. Do not hide the gaps that Fable cannot fill."
If you write this much, you can compare it at the end.
Sonnet 5 concluded by saying:
"Fable 5 can think deeply on its own. I move quickly and accurately if given structure. Bridging that difference with CLAUDE.md is the essence."
The core of this article is exactly that.
Results of Interviewing Fable 5
Next, I asked Fable 5 itself about the same theme.
The first response was great.
"A model's self-report is not reliable data."
Exactly. Just because I asked the model doesn't make it a benchmark. Self-evaluation from the inside is biased.
So, in this article, I won't treat "what they said" as absolute truth. I'll treat it as hints for creating a usage pattern.
That said, the difference Fable 5 defined was sharp.
It said the difference is "what happens when there is no structure, or when the given structure is wrong."
If specifications are clear, tests exist, and procedures are set, the difference is small.
The difference appears when the specifications themselves are wrong. When a plan fails. When maintaining initial constraints until the end of a long task. When self-restraint is needed to not add unrequested improvements.
And Fable 5 admitted its own weaknesses.
High unit cost. Overthinking even simple tasks. Losing in speed matches for bulk processing.
In other words, "Fable for everything" is economically incorrect management.
So, what is the `CLAUDE.md` that Fable 5 wrote for its junior, Sonnet?
Organizing the points that overlapped with Sonnet's side, here are the 7 tips to keep.
7 Tips for `CLAUDE.md` to Turn Sonnet 5 into Fable
The first is success conditions. Both models brought this up independently.
1[Judge completion mechanically]2Define "completion" in one line before starting.3Example: This test passes. This command returns exit 0. This heading is in the body.4If you cannot write it, ask what needs to be decided before proceeding.
The second is multiple interpretations. Both agreed on this too.
1[Do not choose between multiple interpretations on your own]2If an instruction has two or more interpretations, do not silently pick one.3List the candidate interpretations and confirm with a recommendation.4However, if the output remains the same regardless of the interpretation, you may proceed.
The third is scope.
1[Prohibit incidental improvements]2Do not implement changes that were not requested.3"Fixed it while I was at it" or "made a better design" is prohibited.4If you find adjacent areas for improvement, list them as suggestions instead of implementing them.
The fourth is verification reporting.
1[Report 'verified' instead of 'it worked']2Completion reports must include evidence such as executed verification commands, return values, test results, and screenshot confirmations.3Do not write "it should work" for things not executed.4Clearly state the reason for any skipped verifications.
The fifth is how to persist through the same failure. Persistence is important, but persisting in the wrong direction wastes time.
1[Max 2 retries for the same error]2If a fix for the same error fails twice, do not try a third variation.3Briefly report the current status, what was tried, and remaining hypotheses, then change course.
The sixth is the role of the dissenter.
1[Perform a first-read review before completion]2Before the completion report, review your changes as if reading them for the first time.3Identify one adjacent function that could break.4Write what a skeptical senior would say in opposition, and answer that opposition.
The seventh is confidence and honest progress. This reflects Sonnet 5's own self-analysis.
1[Report confidence and progress in 3 points]2Attach confidence levels (High, Medium, Low) to uncertain parts.3If confidence is Medium or Low, ask if you should confirm before proceeding.4In long tasks, report only the following three points at each milestone:5What is completed. What to do next. What you are concerned about.6Reports consisting only of "proceeding without issues" are prohibited.
These 7 tips are not settings that add ability.
They are settings that preemptively block the failure modes where the gap appears.
Don't fall into specification holes. Don't decide ambiguities on your own. Don't inflate the scope. Don't claim completion without verification. Don't continue a broken plan.
In short, we are externally attaching the behaviors that Fable 5 does naturally to the Sonnet 5 environment.
What We Saw in the Comparison
What was interesting was that Sonnet 5 and Fable 5's answers matched significantly even when asked separately.
First, don't pick multiple interpretations on your own.
Both said this. When given ambiguous instructions, AI tends to pick a plausible interpretation and move forward. From a human perspective, you think, "I wanted you to check that."
Next, externalize verification.
Instead of letting it say "it worked," make it output what it executed, what passed, and what it saw. Even in official best practices, giving Claude a way to verify its own work is considered most important.
Provide checks that result in pass or fail, like tests, builds, or screenshot comparisons. This closes the loop.
Furthermore, it's big to separate the eyes that verify.
If the creator grades themselves, they get lenient. Have a verification sub-agent in a new context check the diff against the plan. It's like having a reviewer separate from the author in human terms.
And finally, the unbridgeable gap also matched.
Long-term context retention.
In a job involving dozens of tool calls and several hours, the ability to maintain constraints decided at the beginning until the end. This cannot be completely filled by CLAUDE.md alone.
If I hide this, the article becomes a lie.
Finishing Touches on the Environment Side
It doesn't end with just writing CLAUDE.md.
Sonnet 5 has an effort setting to specify the depth of thought. In official correspondence tables, Sonnet 5's "medium" is equivalent to Sonnet 4.6's "high," and Sonnet 5's "high" is equivalent to Sonnet 4.6's "max."
If you see shallow reasoning, increase the effort rather than tweaking the prompt. This is the official recommendation.
If you want Claude Code to always think deeply, add the following to settings.json:
"effortLevel": "high"
This pushes Sonnet 5 toward the "persistent" side from the start.
However, CLAUDE.md shouldn't just be long.
Ideally, it should be under 60 lines. At most 200 to 300 lines. For each line, ask, "If I delete this, will Claude make a mistake?" If the answer is No, delete it.
Don't write things that can be inferred from the code. Don't write standard practices. Leave what can be handled by a linter to the linter.
What you should write are unpredictable commands, unique practices, how to run tests, pitfalls, and architectural decisions.
Place important instructions at the beginning. Use strong words like "Must" or "Prohibited" instead of "Recommended."
CLAUDE.md is not a request letter to the AI. It is the team's work rules.
Situations Where You Should Still Use Fable 5
After reading this far, you might think, "Then do I not need Fable 5?"
No.
Fable 5 is necessary. However, you should narrow down where you use it.
The bridgeable gap is in work where the correct answer can be judged mechanically.
Implementation fixes that can be judged by tests. Bulk classification, extraction, and summarization. Small changes where a human review will happen anyway. Sonnet 5 with a good CLAUDE.md can compete well in these tasks.
The unbridgeable gaps are mainly three:
1. Work where a checker cannot be written.
Is this design okay? Are there holes in this migration plan? What should be built in the first place? If writing the acceptance criteria itself is the core of the work, you cannot run a verification loop first.
2. Judgment of rule application.
Even if you write "keep it simple," the model decides what is simple. Even if you write "don't abstract without permission," where abstraction begins changes with the situation.
3. Long-term context retention.
This is a difference in raw power. While prompts can improve it, it won't completely disappear.
The judgment criteria provided by Fable 5 itself were the most practical.
If you can write the acceptance test first, use Sonnet. If writing the acceptance test itself is difficult, use Fable. If unsure, start with Sonnet, and switch to Fable only for tasks that result in two consecutive reworks.
I think this is fine.
You don't need to throw everything to Fable from the start. Conversely, saying everything can be handled by Sonnet is also careless.
Start with the cheaper Sonnet. Reduce failures with structure. Switch to Fable after two setbacks.
This is the realistic way to differentiate usage after July 8th.
What to Do Today
First, paste the 7 tips from this article into your project's CLAUDE.md.
Next, set effortLevel to high in settings.json.
Then, for your next task, make sure to have it output "Success Conditions," "Multiple Interpretations," and "Verification Reports."
For long tasks, separate the implementation role and the verification role. Don't let the creator grade themselves; show it to Claude in a different context.
And switch to Fable 5 only for tasks where reworks continue twice.
Even when Fable 5's free period ends, what ends is only the free tasting period.
What you should really keep is Fable 5's behavior.
Turn Sonnet 5 into Fable 5.
The first step isn't pasting long magic prompts every time.
It's placing the work template in CLAUDE.md.
But after reading this far, you must have thought:
"I understand the settings. But I don't know what to build or how to earn with this upgraded AI."
It's the opposite. AI that has become cheaper and smarter should first be used for mass-producing customer attraction and content. If you can bake Fable-level persistence into Sonnet, you can run daily posts, articles, funnels, product ideas, and improvement loops at a low cost.
The specific details are summarized in my pinned post. For those who seriously want to "use AI cheaply and smartly to connect to customer attraction and monetization," please go here ↓
