What happens to your turn when the narrator's model provider goes down

Fabulator's narrator is written by an AI model that the platform reaches through an outside provider. Outside services fail. A request can time out, a connection can drop, a provider can refuse or stall partway through a reply. This article explains what the platform does in those moments, because the design decision behind it matters more to a Player than the failure itself.

The short version: the turn stops, you are told, and nothing in your story changes. The rest of this piece explains why that is the behaviour on purpose.

The narrator is treated as a critical capability

Fabulator separates its model-backed capabilities into those the story cannot proceed without and those that improve it. Narration is in the first group. Without a narrator there is no scene, and the platform will not invent one from nothing.

So when narration fails, the system performs what its design rules call a fail-secure halt. It does not retry forever, it does not hand the scene to a different model without telling you, and it does not stitch together half a reply. It stops the turn and sends the client an error with a provider error status. In the portal this appears as a plain narrator error, and you can send your action again.

Your state is not touched by a failed turn

The reason a halted turn is safe is how a turn is committed. When you act, the platform first validates the action and records the proposed changes as a draft turn marked as awaiting narration. That quick write finishes before the model is called, so no database transaction is held open while the platform waits on an outside service.

Only after the narration comes back and passes its checks does the platform apply those changes to the live world, store the final prose and mark the turn complete. If narration fails first, the draft is marked as failed and the live tables are never written. There is nothing to roll back because nothing was applied.

In practice this means a failed turn does not cost you an item, a hit point, a relationship change or a moved location. The world is where it was before you pressed send.

You never see half a scene

Narration is not shown to you token by token as it arrives. The platform buffers the full reply, runs it through output safety and consistency checks, and only then replays it to your screen. This is partly a safety measure, since unsafe text should never reach the screen before it has been checked. It has a useful side effect for reliability: if the provider dies partway through a reply, you do not get a scene that stops mid-sentence and then gets contradicted later.

A stream that goes quiet is handled the same way. The platform watches for stalls, and a provider that stops sending data triggers the halt rather than leaving you waiting indefinitely.

Optional extras fail differently

Not every model-backed feature is treated as critical. Voice narration and scene images are enhancements. If one of those providers is unavailable, misconfigured or switched off, the capability degrades to its fallback: voice falls back to text only, and an image falls back to a descriptive text plate. Core play continues, and a warning is logged rather than the session crashing.

The distinction is deliberate. Losing a voice should not stop a story, but losing the narrator has to, because anything else would mean pretending to a scene that was never written.

Soft quality drops are surfaced, not hidden

There is a related principle in how the platform handles reduced quality in general. When a provider lacks an optional feature a task would prefer, the platform proceeds at reduced fidelity and records that it did so, both on the response and in its metrics. The guiding idea is that a system may fail, but it should not lie about failing. A degraded result should be visible to the operators and, where it matters, to you.

What operators see

Failures are not swallowed. A halted turn is counted by phase and error type in the platform's metrics, and the turn's trace records what happened, so a spike in provider errors shows up as a pattern rather than a rumour. Those metrics and logs are written without blocking the turn loop, so observability never makes a bad moment worse.

Fabulator also runs a public status page that reports whether its own services are responding. That is a separate signal from a model provider having a bad hour, but it is the first place to look if nothing in the portal seems to respond at all.

What you can do

If a turn errors:

• Wait a moment and send the same action again. Your previous state is intact.
• If the problem repeats, try again later. Provider trouble usually clears on its own.

None of this makes outside services reliable. It makes the failure honest and contained: the turn stops cleanly, your world stays consistent, and you can pick up from the same place.

Other posts on this blog cover how a turn is committed and why model output is validated before it becomes game state.