A quiet progress panel after an Opus-to-Fable migration is not, by itself, evidence that the agent has stopped. Before changing prompts or adding retries, check which response blocks your UI consumes—and which CometAPI route you are qualifying.
The Anthropic migration guide, inspected September 6, describes a relevant change: Opus 5 inter-tool narration arrives in text blocks, while Fable 5.1 uses progress-update thinking blocks. The default thinking.display=omitted provides no readable text. The beta display=updates setting exposes progress text while keeping reasoning hidden. The guide recommends rendering nonempty thinking blocks between tool_use blocks.
That creates a specific adapter failure mode: a renderer that only watches text blocks can miss progress updates even if the tool loop is continuing.
Choose the CometAPI route before promising progress support
CometAPI’s September 4 Fable article documents claude-fable-5-1 through both the Anthropic-compatible /v1/messages and OpenAI-compatible /v1/chat/completions endpoints, and recommends evaluating tool behavior before moving traffic.
For an adapter that depends on native thinking and tool_use distinctions, I would qualify CometAPI’s /v1/messages route first. That is a design recommendation based on the documented interface choices, not proof that this route passes through the display beta. Endpoint compatibility alone does not establish that either route preserves progress blocks or supports thinking.display settings.
Before testing, confirm current account access and the route-specific beta prerequisites. Do not switch to /v1/chat/completions and assume the same block representation survives. If that is the route your application requires, qualify its response mapping separately rather than treating the native-route adapter as interchangeable.
Keep three responsibilities separate
The proposed adapter should distinguish:
- Progress presentation: show readable, nonempty progress updates in a status area, not as final-answer prose. These updates are not access to hidden reasoning.
- Answer presentation: keep final-answer text separate from progress and tool activity. A progress update must not become part of the saved answer merely because it is readable.
- Conversation replay: retain the original conversation payload independently of the display. The upstream migration checklist requires passing thinking blocks back unchanged, including empty ones; rebuilding history from visible text would lose that distinction.
This is a UI and history-handling design, not a report of an executed CometAPI integration.
A small acceptance matrix before rollout
| Case to qualify on the selected CometAPI route | Required adapter behavior |
|---|---|
| Omitted display or an empty thinking block | No invented narration; an empty progress view alone does not mark the run as stopped. Preserve the original block for replay. |
| A nonempty update, if the route supports the beta | Render it in the progress area without appending it to the final answer. |
| A tool-use block between updates | Handle tool activity separately; do not interpret a display gap as a reason to retry the model call. |
| Final-answer text | Present the answer without merging earlier progress into it. |
If the route rejects the beta setting or loses the needed updates, stop the progress-feature rollout, not necessarily the entire integration. Use an application-owned waiting or tool-status indicator, clearly distinguished from model narration, until support is demonstrated. Do not advertise model progress updates based only on the upstream guide.
The decision is narrower than “does Fable work?”: can this particular CometAPI route preserve the signals your adapter needs, while keeping progress, final text, and replay history separate?