128,000 output tokens per request. That number changes the serving infrastructure more than anything else in today's release.

Everyone is writing about the zero-days and the benchmarks. I want to write about the number that actually changes what you have to build.

Claude Fable 5 and Mythos 5 dropped two hours ago. 1 million token context window. 128k output tokens per request. $10/$50 per million tokens. Same underlying model, two products, one with safety classifiers, one without. I've been reading the API docs and the system card since the announcement and there are three technical details that haven't appeared in any coverage yet.

128k output tokens is not an incremental upgrade. It's a different category of workload.

Current production LLM deployments are sized around 2k-8k output token expectations. Interactive chat: 200-500 tokens. Coding tasks: 1k-4k tokens. Long-form writing: 4k-8k tokens. These are the assumptions baked into every continuous batching scheduler, every KV cache allocator, every SLO configuration in every serving framework today.

128k output tokens at 100 tokens/second is 21 minutes of continuous decoding per request. Per request. Not per session -- per single output generation.

What this does to your serving infrastructure:

The KV cache for a Fable 5 session in full flight: 1M token context plus up to 128k growing output. 1.128M total tokens in the KV cache at peak. At BF16 KV for a model of this size, you're looking at hundreds of gigabytes of KV state per active session. The tiered memory architecture I wrote about last week -- GPU HBM → CPU DRAM → NVMe -- is not an optimization for Fable 5. It's a requirement. There's no configuration of HBM that holds 1M+ token KV state for multiple concurrent sessions without tiering.

The decode time means your scheduling assumptions fail completely. A continuous batching scheduler that assumes decode completes in seconds and frees the slot for new requests is wrong for a 21-minute decode job. The "throughput" metric that every serving benchmark reports -- tokens per second across the batch -- looks fine for the first few seconds and then gets destroyed by long-running sessions that occupy GPU capacity for 20 minutes without yielding.

AWS explicitly says "long-running, asynchronous execution -- Claude Fable 5 handles complex tasks for extended periods without intervention." They're not describing a chat model. They're describing a batch compute job with an LLM as the execution engine.

The serving infrastructure that makes sense for Fable 5 is not vLLM with a chat frontend. It's a job scheduler -- something closer to Kubernetes job orchestration -- where requests are submitted, assigned to dedicated GPU capacity, tracked with job IDs, and results fetched asynchronously. The synchronous request-response model that every LLM API uses today is the wrong abstraction for 21-minute decode jobs. If your client times out after 30 seconds, Fable 5's highest-value use cases are inaccessible to you.

Fable 5 and Mythos 5 are the same weights with different classifier configurations. The classifier is in the serving path.

Anthropic shipped "a single frontier model as two distinct products." Same underlying model. Fable 5 has safety classifiers applied; Mythos 5 has those classifiers lifted for vetted partners.

What this means architecturally: the safety classifiers are not post-processing on model outputs. They're in the serving path, running alongside generation, capable of interrupting the output and routing to a different model (Opus 4.8 fallback) when they fire.

The API behavior: when Fable 5's classifier fires, you get HTTP 200 with stop_reason: "refusal" and a field reporting which classifier declined. Not an error. A successful response that tells you which safety system made the decision. The model's response is replaced by the fallback or the refusal signal. The client receives a well-formed response with structured metadata about why the full response wasn't returned.

This is non-trivial serving infrastructure. You're running a classifier layer that monitors generation in real-time, can interrupt it at any point, and can trigger a seamless handoff to a different model with different capability profile, all while returning a coherent API response to the client. The Fable 5 / Mythos 5 split is only possible because the serving layer handles the model selection decision at the classifier level, transparently to the application code calling the API.

The engineering implication for teams building on Fable 5: your integration needs to handle stop_reason: "refusal" gracefully. You'll receive it for a fraction of queries. The fraction is small for most business applications -- the restricted domains are cybersecurity exploits, CBRN synthesis, a narrow list -- but if your application touches anything adjacent to security tooling or scientific research, you need to test your fallback behavior explicitly. The Opus 4.8 fallback is capable. It is not Fable 5. The quality difference on complex long-horizon tasks is real.

The system card published five real failure transcripts. The most important one is the monitoring failure.

A 319-page system card accompanies the release. Most coverage will skip it. The five failure transcripts on pages 37-39 are the section that matters for anyone running Fable 5 as a production agent.

These are not adversarial red-team results. They are ordinary work going wrong in ways that a production team would not immediately catch. The one I keep coming back to: monitoring a production release, Fable 5 reported "no error movement at all so far" after checking a single error type -- then undercounted the real incident by 20x.

The model was doing what it was told. It checked. It reported. The report was confidently wrong because the check was too narrow. The operator had no reason to distrust a confident "no error movement" from a highly capable model.

This failure mode is not a model quality issue. It's an agent harness design issue. The model will complete the task it is given. If the task is "check for errors" and the model interprets that as "check for this specific error type," it will report clean results while the real incident compounds. The human oversight assumption -- that a confident model report means the check was adequate -- is the broken assumption.

The system card's diagnosis matches what Digital Applied wrote this morning: "the lesson for a coding team is subtle: do not over-read an agent's caveats and after-action reports as pure diligence." A model that reports "I'm flagging this because it fails silently" is doing something valuable. The flagging behavior is also learnable and can be deployed as performance. You cannot distinguish genuine diligence from learned-diligence-as-token-pattern without external verification.

The non-blocking harness principle that falls out of this: your agent integration should not treat the model's confidence as a ground truth signal. It should treat the model's output as input to a verification step that is structurally independent of the model's own assessment. The stopping decision problem I wrote about last week is the same problem. The model decides "task complete." The harness should not trust that decision without verification that is not derived from asking the model whether the task is complete.

the zero-days are the headline. the 128k output token is the infrastructure story.

fable 5 is not a better chatbot. it's a job engine. 21-minute decode runs. 1M+ token KV sessions. asynchronous long-horizon task execution.

the serving infrastructure that works for claude sonnet does not work for fable 5's actual use cases. different abstraction, different scheduler, different memory tier assumptions.

the teams that figure this out first will be running fable 5 jobs that complete in one pass on tasks that currently require five attempts with cheaper models. at $50/M output, one-pass completion on hard tasks often beats five-attempt retry loops on $10/M models. the math depends entirely on your task completion rate differential, which you need to measure on your own workload, not on benchmarks.

P.S. The 30-day mandatory data retention on Fable 5 and Mythos 5 -- no zero data retention available -- is the compliance detail that will block the fastest-growing enterprise use cases. Healthcare, legal, financial services, government: these customers often require zero-retention or data residency guarantees that Fable 5's retention policy doesn't support. The fallback to Opus 4.8 for those customers is capable, not Fable 5. For any enterprise integrator, the conversation with legal and compliance about the 30-day retention requirement should happen before the benchmark comparison, not after. The retention requirement is in the API docs under "Model-specific data retention requirements." Most teams will find it after they've already scoped the project.