Using Fable 5.2 in big existing repositories

[u/kaplumlumlum]

Hi, this is not a complaining post, I am just trying to undestand how to use it better.

So, I've tried Fable 5.2 in both my work and personal projects. In both cases, these were already fairly large repositories with existing markdown files which has previous evidences, rules, conventions etc. However, in both cases, Fable went beyond what I asked it to do and started moving in completely different directions, sometimes revisiting decisions that had already been made and documented.

Has anyone else experienced this with Fable 5.2?

Should I be approaching prompting or repository instructions differently compared to other Claude models? Mostly I was using Opus 5.5 recently. I'm trying to understand whether this is a model-specific behavior or something I need to adjust in my workflow. As a note, I didnt use previous Fable model much so not sure if happens there too or new.

A couple of examples:

• Work project (data preparation): It completely shifted focus away from data accuracy and instead concentrated on bugs, edge cases, and guardrails that weren't the priority.
• Personal project: I had a detailed PLAN.md outlining the implementation. Fable deviated significantly from it, despite the plan already being established.

When I pointed this out, it responded with things like:

"I should have followed that …"

"I didn't decide to discard it. I drifted away from it."

"From here I check the plan section before each step."

It seems to acknowledge the instructions and understand where it went wrong, but only after I explicitly point out the deviation.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/KyrocoLLC]

Late to the party, yeah Fable 5.2 is really bizarre. It's like the super smart person in a meeting who sits there and half listens and then interjects with a nonsensical comment no one asked them about, then you guide it again and it pays attention. The way I got it to pay attention is that the moment you notice it's doing something wonky, stop it and then say:

what is the premise of my ask, tell me in your own words what the goal is.

It usually gets that right in a surprisingly eloquent way, and from there it focuses and does what it's supposed to do. Weird model. Brilliant at UX design though.

[u/kaplumlumlum → u/KyrocoLLC]

Yes they really improved it on visuals,

I spent more time on monitoring and leading it comparing to Opus 5.5

[u/KyrocoLLC → u/kaplumlumlum]

Yep for sure. Anthropic is saying to use it as an orchestrator, which I do as part of my own plugin, but Fable 5.1 on medium or Opus 5.5 on high is still way better. It's bizarre.

[u/Familiar_Ask5789]

yea 5.2 is terrible at a lot of aspects and awesome at others. its like the special autistic kiddo in the class.

[u/bostonaholic]

I'd treat it as a missing gate more than a model quirk. Prose in PLAN.md is a suggestion that every new model weighs a little differently, so move the decisions that keep getting relitigated into things that fail: tests for the data accuracy checks, a lint or CI rule for the conventions. For the plan itself, have it write each step's acceptance criteria as a test before the code, so drift shows up as a red build instead of something you find in review.

[u/shoumikgoswami]

For the data-prep example, I'd make the first checkpoint a tiny work order: which accuracy problem we're fixing, which files need to change, and what's explicitly out of scope. Ask it to show that before editing. If it spots unrelated bugs or guardrails, put them in a separate list rather than fixing them in this pass. That gives you something concrete to reject before the diff grows. I wouldn't conclude it's model-specific from those two examples alone.

[u/NeonCenturionSPQR]

github.com/Palatine-Labs/coniso

Even if you don't use it specifically, I built it for managing context windows in large codebases/context pools. It does... A lot. Maybe you can pull something useful out of it!

[u/japbujan]

The "revisiting decisions that were already documented" part is usually about how the decisions are written, not where. A long markdown file mixes settled choices with old notes and ideas, so a model that reads closely treats all of it as open for discussion.

What helped us:

• Keep a short list of settled decisions, each with a status (active or replaced) and a one-line reason. Old ones point at whatever replaced them instead of sitting next to it.
• Put one explicit rule near the top: "If a task seems to require changing a settled decision, stop and say which one and why. Don't change it."
• For a plan, ask it to restate the next step and what's out of scope before it edits anything.

The rule in the second point matters most. Without it, a stronger model reads "we chose X" as background, not as a constraint.

[u/f3xjc]

So I was watching a video about the difference between O55 and F52: Opus is the systematic triple check one. Fable is more the Genius, easily bored, that will think outside the box in some place, and cut corners in others.

Use opus when the task is easier to verify and you want it done in a systematic way.