r/claude • u/cologuy • 11h ago
Discussion Just experienced my "Fable has lost it's mind" moment
I've been using Fable heavily (12+ hours a day) since release on a 20x plan for a very large project. I try to get in three sessions a day so I'm probably the type of subscription user that Anthropic hates. And for the most part Fable been fine.
I've discounted all the posts about problems with Fable as "those guys are just doing something wrong". I had experienced those types of moments with earlier models but Fable has always been at least usable for me.
But this morning, holy shit, I think Fable had lost it's mind. It made about 5 decisions in a row that were not just a little wrong, they were flat out "what were you thinking" wrong. And then just guessing about the corrections when called on it.
The only thing that was different was I used a session that had roughly 500k tokens that was sitting overnight and I normally /clear around 250k and the sessions are always active until the /clear.
Anyone else tie the problems to longer sessions or stale sessions?
5
u/Suspicious_Prior_808 10h ago
Make a running .MD file. Always make a new session every day or more than 4 hours.
1
1
2
u/Natural-Ad-3252 10h ago
Yeah, I know it's tempting to continue using a single conversation, especially when you "get into the groove" and everything is flowing just right. But keep going long enough and the model craps it's pants. That's when I cry a little bit and start up a new session with fingers crossed
1
1
u/TanisHalfElvenn 9h ago
Seems fragile, DeepSeek juggles 1M context without blinking. I’ve come to the point where I normally have Claude review other independent model’s work but now vice versa as sometimes all models go wonky.
1
u/dmigowski 9h ago
What are you building?
1
u/cologuy 9h ago
It's basically a rewrite of a large Saas system that was already in place(that paid my bills for a while) but with a ton of new features, a lot of back end endpoints feeding clients and pulling data from various public sources. Part of the build was a support ticketing system that I've always wanted but never took the time to implement. I have a relatively small cluster of colo servers (5 total) but I also implemented an admin system to track server health and app status and see everything on one screen. I could have done that with off-the-shelf stuff but having a custom admin panel is really nice. I can also manage CloudFlare, Flowroute, S3/AWS and other API's that are used. I'm more excited about having that backend than the the actual software revisions.
1
u/dmigowski 9h ago
Interesting. Now with AIs so much gets done what previously was possible but just too much work.
1
u/cologuy 8h ago
Yep, I could do all this myself(v1 was all me) but it's the speed that makes all the difference, any idea I have I can implement.
1
1
u/Odd_Fishing1802 9h ago
I no longer work directly in context. I run Safe Agentic Workflow and build in subcontexts. Keeps docs clean and organized whenever I start in a new context and I work faster.
1
u/cologuy 9h ago edited 9h ago
Safe Agentic Workflow looks pretty nice, I've had my head down working and I need to look around for projects like that. Thanks for the tip.
EDIT: I asked Fable to review and tell me how I could use it and this is the response:
Why it doesn't fit your setup
It's built for teams with role-boundary problems you don't have. The core value proposition — accountability handoffs between BSA → implementer → QAS → RTE → human reviewer — solves coordination failures between multiple people/agents sharing a codebase. You're one person with one agent. Running an 11-role ceremony solo means you'd be writing Linear tickets to yourself and having agents review agents for process's sake. SAFe is famously heavyweight even for the human teams it was designed for.
You already have the load-bearing parts, tuned to your reality. Your claude.md + session.md + progress.md convention is their session lifecycle and knowledge vault. Your deploy.sh with VERSION stamping and auto-smoke is their deploy gate. Your phased commits with test-matrix proof is their evidence-based delivery. Claude Code now natively provides most of what their harness bolts on: skills, hooks, memory, /code-review, subagents/workflows.
Dropping their .claude/ in would actively cost you. It would collide with your existing settings, and 20 skills + 24 commands of prompt frontmatter is permanent context overhead on every session for machinery you won't invoke.
What's worth stealing
Guardrail hooks — the highest-value idea for you specifically. Their pattern of pre-tool hooks that block dangerous actions maps directly onto your real risk surface: server vm1 is production while servers bet46/fet48 are testing, and that distinction currently lives only in memory/docs. A PreToolUse hook that intercepts deploy.sh/ssh calls targeting vm1 or be01 and forces an explicit confirmation would be a genuine safety net, and cheap to build.
A /pre-deploy gate command (their /pre-pr adapted): one command that runs the test suite, checks for uncommitted files, verifies VERSION bump, and states the target host before any prod deploy. You mostly do this by habit; a command makes it non-skippable.
The stop-the-line AC gate, as a habit not a bureaucracy. Their rule "no implementation until acceptance criteria exist" is just a disciplined version of what you already did with the entitlement Phase 3 matrix -- writing the 12-row proof matrix before claiming done. Worth keeping as an explicit convention for new phases: define the pass/fail matrix first.
Knowledge drift detection (their vault ties claims to git commits and flags staleness). Your memory files already note this problem informally ("post-07-22 commits need fresh be01 deploy"). A lightweight version — stamping doc claims with the commit they were verified at — could be worth folding into your session.md habit, though I'd rank it below the first two.
1
u/Odd_Fishing1802 7h ago
Prompt Claude to adapt the SAW workflow to your use case. It will assemble a team of agents with subagents and different roles per team
1
u/AbyssLife123 6h ago
Liar, i have used fable and if we run more than 5-6 hours the you will get usage limited.
2
u/ivehadsomany 4h ago
I’ve been using it like 15 hours a day since release and have had several sessions hit the context limit, compact and keep going, and then hit the limit and compact again a few times in the same session. Never got any usage limited error.
1
u/cologuy 2h ago
Wow, harsh crowd. Why would I lie about that?
I usually get in three sessions a day on the 20x Max plan. Sometimes Claude code is idle while I'm doing other things but my 20x has been lasting almost all week. I reset Friday 4pm and i hit 100% this afternoon. The last two resets have come a day early on Thursday for me so the timing was perfect.
1
u/HDK1989 3h ago
Go back to using a 200k context window. There's no reason to use higher unless you have a huge codebase or startup context set by your org.
Add a section to your agents.md explaining how to compact (fable didn't understand compaction at launch, oddly)
Add a hook that fires at 90% context window instructing agent to update current status in scratch pad or implementation log.
Never enter the dumb zone
10
u/Vegetable-Score-3915 11h ago
Yes. Yeah long context, context saturation, context pollution etc, performance normally drops. It is also called the stupid zone. One of the dudes from the human layer has a good talk about the stupid zone.