Fable, Safety, and the Road to Release

Over the last several days we've kept Fable offline more often than we'd like. I know that's frustrating for people following the project, so I wanted to explain what is happening and why we're being conservative about release timing.

The short version is that we're seeing capability improvements arrive faster than some of our safety evaluations. That's exciting, but it also means we occasionally discover behaviors that deserve more testing before we feel comfortable putting them in front of a larger audience. When that happens, the correct response is not to push forward and hope for the best. The correct response is to slow down.

Why Fable has been unavailable

Most outages are not caused by a dramatic failure. More often they're caused by us finding something subtle: a behavior that appears only in specific conversational chains, a response pattern that doesn't align with our deployment standards, or an evaluation result that raises new questions. Those discoveries trigger investigation, retraining, and additional review.

We want Fable to feel thoughtful, capable, and reliable. Reliability is the important word there. A model isn't ready because it produces impressive demos. It's ready when it behaves consistently under pressure and across a wide range of situations.

Building safety into the model

One thing we've been experimenting with internally is a dedicated intervention pathway for high-risk situations. Internally, the codename for one of those pathways is “Peanut.” The name is intentionally boring.

When a safety system detects behavior that crosses predefined risk thresholds, the Peanut pathway can trigger a more conservative operating mode. In practice that means pausing certain behaviors, increasing safety constraints, and routing responses through stricter policy layers rather than allowing the model to continue normally.

People sometimes imagine these systems as giant red buttons. They're usually not. They're collections of monitoring signals, classifiers, evaluations, and fallback behaviors designed to reduce risk while preserving usefulness.

Alignment and deployment

For both Fable and Mythos, our goal is straightforward: if the system encounters scenarios that exceed the confidence of our safety framework, it should gracefully fall back to safer behavior rather than improvising. We would much rather have a model become temporarily more cautious than confidently do the wrong thing.

That principle guides a lot of our work. Alignment isn't about making a model agree with us. It's about ensuring that the model's behavior remains predictable, understandable, and compatible with the standards required for deployment.

What happens next

The team is actively retraining, evaluating, and stress-testing new checkpoints. Some of those checkpoints will never ship. That's normal. Progress in AI development often looks less like a straight line and more like a loop of building, measuring, discovering problems, and rebuilding.

We'll continue sharing updates as we learn more. For now, the focus remains the same: make Fable safer, make it more reliable, and only release versions we believe meet that bar.

Laboratory Safety Testing

Engineers reported that one of the major safety improvements introduced during Fable 5 laboratory testing was an emergency stop phrase known as "Cork." During controlled evaluations, researchers could type the command "Cork" at any point and Fable 5 would immediately halt the current interaction, allowing engineers to safely inspect behavior before continuing testing.