Twitter threads circulating this week claiming developers pulling $40,000 a month out of Claude Fable and Sonnet 5 are not writing clever prompts.
They are running a system.
I would normally scroll past a number like that, but the thread promised to show the setup behind it, so I stopped to check.
Note: Most of the income math in threads like this does not survive contact with reality, and I am not going to repeat the specific dollar figures here because I have no way to verify them. Sorry for the clickbait, too.
I’ll just shed light on how they use it and what I have actually noticed changing in how I am now using agent-first IDEs like AntiGravity on my own products.
That part is worth unpacking.
The gap is not the model, it is what you hand it
Here is the pattern I keep seeing in my own work too.
If I open a chat, drop in a function, and ask for a fix, I get exactly that: a fixed function.
Useful, but small.
The moment I give Claude a full picture of a repository instead, the quality of what comes back jumps in a way that has nothing to do with prompt wording.
That distinction is the entire argument of the thread, and it happens to be correct.
A single question gets you a single answer.
A repository, read in full, with rules laid out for how the codebase works, gets you something closer to a colleague who already knows the project.
Two models doing two different jobs
Anthropic shipped Claude Fable 5 alongside Sonnet 5 as a step above the existing Opus tier.
It is positioned less as a chat upgrade and more as a model built to stay on task for long, unsupervised stretches of agentic work.
The detail that made me stop scrolling was a case Anthropic put out at launch.
Stripe reportedly ran a codebase-wide migration across a 50 million line Ruby codebase using Fable 5 in about a day.
Their own team had estimated the work at more than two months by hand.
I treat any vendor case study with real skepticism, but it is a documented claim from Anthropic itself.
The underlying idea tracks with what long context and sustained autonomous coding are supposed to unlock.
The practical read for someone building solo, the way I do on aibucket.org, is not to use Fable 5 for everything.
It is closer to this: cheaper, faster models can carry your daily feature work and bug fixes.
You reserve anything resembling a large refactor, a security-sensitive change, or a genuinely gnarly architectural call for the model built to hold context the longest.
Routing tools exist that pick the right tier automatically based on how complex a task looks, so you are not manually deciding this every time or paying premium rates for a one-line docstring fix.
The files doing the heavy lifting
The most useful part of the thread, and the part I have actually started copying into my own repositories, was not about which model to use.
It was about what you put in the repository before you ask Claude to touch it.
- A rules file at the root of the project. Not a prompt, but a permanent document. It lists which libraries are banned, which are mandatory, how commits should be made, and what the testing setup looks like. Claude reads it once per session and then never needs the same instructions typed out again.
- A project context file. Where the architecture decisions live, why the folder structure looks the way it does, and what past mistakes to avoid repeating. This is the difference between Claude treating your project like a stranger and treating it like something it already understands.
- Small task-specific reference files. Instead of re-explaining your API conventions or your deployment steps every session, you write them once and call them by name when the task needs them. Frontend rules, backend rules, security checklists, and deployment steps each live in their own file. They are called on demand instead of retyped.
- A plan-first instruction. Before any code gets written, Claude reads the whole repository, lays out exactly which files it intends to touch and why, flags edge cases it expects to hit, and waits for a yes before doing anything. I have started doing a version of this myself on GritGlean and BoutPredict. The difference between planning first and just building is not subtle. Skipping straight to code is how you end up reviewing a diff you do not fully trust.
Splitting the work into specialists
These threads also described running several narrower Claude sessions instead of one general one.
One focused purely on researching the right library or approach, one that turns a feature into a step-by-step plan, one that writes the code, and one that reviews the diff for bugs and security holes before anything gets committed.
It is the same model underneath every time, just handed a narrower job and a narrower context each time.
It is closer to how an actual small team splits responsibility than how most people currently use a single long chat.
I have not fully rebuilt my own workflow around four separate personas yet, but the underlying logic is sound.
It is the piece of this I am most likely to steal properly.
I will not use it as a screenshot-worthy claim but as an actual change to how I structure a session before I start typing.
I am not going to pretend I have a four-project agency and a fifteen thousand dollar SaaS running off this exact playbook, because I do not, and neither does most of Twitter.
What I am taking from it, and what I would genuinely suggest testing on your own repository before dismissing the whole thread as hype, is the specific, checkable part.
Write down your project rules once instead of retyping them.
Make Claude plan and show you the plan before it writes a line. Stop treating a frontier model like a better version of Stack Overflow.
The revenue screenshots are the part that gets these threads/articles shared.
But, the repository structure underneath it is the part that is actually worth your weekend.
In case we are meeting for the first time, come over here, it’ll be worth the roller coaster of articles that are gonna come up in the next few weeks.
Have you read?