Whether Fable 5 uses your included allowance or a separate credit balance depends on your plan and seat tier.
Updated October 1, 2026: Max, Team premium and legacy seat-based Enterprise premium include Fable usage; Pro and standard seats use credits from the start. The current plan guide covers Fable 5 and 5.1. The July timeline below is history, not today's billing rule.
This article was first published July 17; its original cover illustrates that historical promotion. This correction updates plan inclusion and the expired credits offer; the API-rate and retention examples remain the July 17 context. Check their linked official documentation before budgeting a new workload.
This is not another Fable capability review. We already covered what Fable and Mythos changed and why the shutdown exposed an infrastructure risk. This update is about the access regime that followed: who gets included usage, who pays from the first token, what "usage credits" actually means, and why prompt caching does not undo the model's 30-day retention requirement.
The original July explainer recorded four operational dates:
The June 30 redeployment announcement recorded the initial July 7 offer. The current plan guide records its extension to July 19. That ended promotion should not be used to infer today's allowance.
One more date trap is worth calling out. Some developer documentation still presents Fable as generally available from its June 9 launch. That is reasonable for a model-introduction page, but it is not a service-status history. The restoration post is the better source for the June 12 interruption and July 1 return.
For the included tiers in the matrix below, the ceiling is up to 50% of the shared weekly limit. It is not extra capacity.
That does not mean Anthropic added a separate half-week of Fable capacity on top of the normal plan. Fable draws from the same regular weekly pool as other Claude models. Anthropic also warns that Fable uses that allowance faster than other models.
Think of included usage as two overlapping constraints:
Suppose a user's other-model activity has already consumed half of the weekly allowance. That user has only the remaining half available overall, even though the Fable ceiling is also 50%. If the user reaches the Fable ceiling first, they may still have regular plan capacity for another model.
For a credit-only tier, there is no included Fable share to exhaust first. Check the seat tier before estimating spend.
The model name alone does not tell you the billing behavior. These are the current rules checked October 1, 2026, against the official plan and promotion guides.
The current plan guide and promotion terms are the sources for these rows. Anthropic's Enterprise billing guide explains the larger contract change: all new Enterprise plans use a single usage-based seat. The annual seat fee provides access to web, desktop, mobile, Claude Code, and Cowork, but includes no usage. Every token is a separate metered charge.
Legacy Standard and Premium seat types are no longer offered for new Enterprise contracts and are moving to the single Enterprise seat at renewal. That is why two companies that both say "we have Claude Enterprise" can get different answers about Fable.
For Pro and Max users, usage credits are configured on the web under Settings → Usage. The user adds a payment method, enables credits, prepays funds, and chooses a monthly limit or unlimited spending. Auto-reload can buy more funds when the balance falls below a chosen threshold. Anthropic lists a daily redemption limit of $2,000.
The credit boundary follows the plan matrix above. Do not group Pro with Max, or standard seats with premium seats, when configuring a Fable budget.
For Team, an Owner or Primary Owner enables credits, prepurchases the shared balance, chooses which users can consume it, and sets organization or user limits. For legacy seat-based Enterprise, credits are billed monthly in arrears based on actual use, with controls at organization, seat-tier, group, and user levels.
Anthropic warns that a request can slightly overshoot a spend limit. Eligibility is checked before a request runs; the final token cost is known only after processing. The next request is blocked, but the request that crosses the threshold can finish above it.
For usage-based Enterprise, “usage credits” may describe the prepaid pool on self-serve plans, but it is not overflow from an allowance. There is no allowance. Self-serve Enterprise draws every request from a shared prepaid balance; sales-assisted Enterprise meters the same usage into a monthly invoice. AWS Marketplace purchases are invoiced in arrears like sales-assisted plans.
Pro and Max users prepay on the web, set a monthly cap, and can choose auto-reload. A mobile subscription does not let you configure the credit feature inside the mobile app.
Owners buy the balance and govern access. One person's long Fable session can reduce the shared pool available to everyone else.
Use the standard/premium distinction in the current plan matrix, then confirm which tier the organization actually assigns.
The seat buys access to the product surface, not included inference. Every model request is billed separately, and Fable sits at the high end of Claude's generally available rate card.
Anthropic also sells discounted usage bundles for Pro, Max, and Team: $50 of credit for $45, $250 for $200, or $1,000 for $700. Those are 10%, 20%, and 30% purchase discounts. Individual subscribers can buy up to $2,000 in discounted bundle value per month; Team organizations can buy up to $3,000. Usage beyond those bundle caps returns to standard rates.
That discount changes the effective amount paid for a credit balance, but it does not change the model's metering units. The dashboard still needs a token-aware budget.
Anthropic says usage credits are billed at standard API rates. The following Fable 5 examples retain the July 17 rates. Consult the current API price sheet before using them for a new estimate:
The simple formula is:
cost = (uncached input ÷ 1,000,000 × $10)
+ (cache-write input ÷ 1,000,000 × write rate)
+ (cache-hit input ÷ 1,000,000 × $1)
+ (output ÷ 1,000,000 × $50)
× applicable geography multiplier
If a Fable request processes 100,000 uncached input tokens and generates 10,000 output tokens, the illustrative first-party global cost is $1.50: $1.00 for input plus $0.50 for output. If the same 100,000-token prefix is a valid cache hit, that input portion falls to $0.10, making the request $0.60 before any other feature charges.
That example is deliberately narrow. Real Claude and Claude Code sessions can include growing conversation history, project files, tool definitions, tool results, screenshots, server-tool charges, retries, and fallback behavior. The chat interface does not expose a neat one-prompt-one-price abstraction.
Fable uses Anthropic's newer tokenizer. The pricing documentation says the same text produces approximately 30% more tokens than with models on the previous tokenizer, with the exact increase depending on content and workload shape.
This creates an easy budgeting error. A team migrates a fixed prompt from an older model, multiplies the old token count by Fable's list price, and assumes it has a forecast. Even if output quality and request count stay constant, the billed token quantity can be higher.
Use Anthropic's token-counting endpoint with the Fable model ID on representative production payloads. Count the complete request shape, including system text, tool schemas, files, images, and conversation history. Then compare total task cost, not only the per-million-token label.
This is the most important cost insight in the update:
A price per token is not a price per workload when the tokenizer changes.
Prompt caching is compelling at Fable rates. A five-minute cache write costs 1.25 times normal input and a one-hour write costs 2 times normal input. A hit costs 0.1 times normal input. Anthropic says a five-minute cache pays back after one hit; a one-hour cache pays back after two hits.
That works well for stable, repeated prefixes:
It does not turn every long task into a cache hit. The repeated portion must match the cache rules, and the cache must still be alive. A one-off 500,000-token analysis has no second read to discount. A frequently changing prefix can keep paying write prices.
Batch and cache discounts can stack, and the US-only multiplier can stack on top of both. That is useful for non-interactive evaluation or document pipelines, but it is not the billing behavior of an ordinary live subscription chat.
Anthropic designates Fable 5 and Mythos 5 as Covered Models. Its API and data-retention documentation says both require 30-day retention and are not available under zero-data-retention arrangements.
On the direct Claude API, a request from an organization or workspace that has not enabled the required retention returns a 400 invalid_request_error. An organization with a ZDR agreement can opt a specific workspace into 30-day retention while leaving other workspaces on ZDR. That makes a separate Fable workspace a practical governance boundary.
Anthropic's Covered Models support article says prompts and outputs are retained for 30 days on every platform where covered models are offered. For direct Claude API and Claude Platform on AWS, Anthropic handles the retained data. On Amazon Bedrock and Google Cloud's Agent Platform, retained data stays in the provider environment. Azure Foundry has its own subscription-level configuration path.
Consumer Pro and Max surfaces already had retention, so the operational change is most visible for commercial organizations that previously relied on ZDR. The model can be affordable enough and technically accessible, yet still be disallowed for a particular dataset.
That means the real Fable admission check is three-part:
Use it when completion quality or long-horizon reliability can repay the higher meter. Simple routing, extraction, and short summaries usually do not.
Forecast with the new tokenizer, real context growth, cache behavior, tool overhead, fallback, and a hard spend boundary.
If the answer is no, Fable is the wrong route regardless of model quality, subscription tier, or available credit balance.
Anthropic uses the word credit in two unrelated billing mechanisms.
Usage credits are money-like account balance. They fund metered use where the plan requires credits, or after an included allowance is exhausted.
Fallback credit is an API billing adjustment. Fable and Opus prompt caches are model-specific. When a Fable request is refused and retried on Opus 4.8, the same prefix normally has to be written into a second model's cache. Anthropic's Fallback credit documentation describes a token that lets the retry be billed as though the conversation had been on the fallback model all along, avoiding a duplicate prompt-cache write charge.
On Anthropic's consumer and work-product surfaces, automatic switching is enabled by default when Fable safeguards block a request. The billing guide for switched conversations says:
This matters because a Fable session may not be billed entirely at one model's rate. For security, biology, chemistry, model-distillation, or certain frontier-ML workflows, routing behavior belongs in both the quality trace and the cost trace.
The expired July offer and current seat differences show why three parts of the product contract need separate checks:
Your plan can give you the interface without including Fable entitlement. Your organization can enable the entitlement but cap or withhold the spend. Your credit balance can fund the model, while a retention rule still blocks the data.
That separation has several consequences.
A model picker shows access, not how a request is funded. The current matrix distinguishes included usage from credits; check both before forecasting.
Procurement documents, onboarding guides, and internal support scripts should stop using “available” as a synonym for “included.” The right questions are:
The current Enterprise seat is a platform fee plus consumption. That resembles cloud software more than traditional per-seat SaaS. A seat grants identity, collaboration, governance, and interfaces; compute is billed separately.
This architecture makes advanced models easier to expose without pretending their marginal cost fits a flat subscription. It also moves FinOps practices into ordinary knowledge work. Teams need cost attribution, spend limits, workload routing, and alerts for an assistant used in chat.
The July offer was a historical migration window. Today, build the routing policy around the actual seat allowance and credit controls. Enabling unlimited credits does not explain which tasks justify their cost.
The practical model is:
The earlier frontier access-regime analysis argued that capability, permission, and deployment are becoming separate competitive layers. Fable's post-restoration billing makes the same pattern visible at the checkout screen.
Before relying on Fable for a recurring workload, run a small workload audit:
The decision metric should be:
incremental cost of Fable ÷ incremental successful outcomes
If Fable saves an engineer three hours on a difficult migration, a $20 session can be cheap. If it adds polish to routine summaries, the same meter is waste. The model should earn its escalation.
The earlier weekly-usage promotion ended July 19, 2026 at 11:59:59 PM Pacific Time. The current plan matrix, not that expired offer, determines included usage now.
Pro uses credits from the start. Max includes up to 50% of the shared weekly limit; credits are optional after that limit. See the current plan matrix for Team and legacy Enterprise seats.
No. Included Fable usage draws from the same weekly plan limit as other models and may consume it faster. The 50% figure caps how much of that shared limit can be spent on Fable at no extra charge.
Usage-based Enterprise is metered at standard API rates. Legacy seat-based Enterprise is different: use its standard/premium rows in the current plan matrix, rather than applying the usage-based rule to every Enterprise account.
The July 17 example uses $10 per million input tokens and $50 per million output tokens. Check the linked current price sheet before estimating a new credit bill. Cache writes, cache hits, Batch API requests, US-only inference, tools, and fallback behavior can change the final amount. Discounted credit bundles can reduce the effective purchase price for Pro, Max, and Team users.
No. Prompt-cache TTL controls reuse for cost and latency. Fable's Covered Model policy separately retains prompts and outputs for 30 days and does not support ZDR.
On Claude product surfaces, an input-blocked request is charged only at Opus rates. A midstream block can produce a mixed bill: Fable rates for the input and streamed portion, then Opus rates for the remainder. API customers must opt in to and configure fallback behavior.
Yes, though controls depend on the plan. Individuals can set monthly limits and manage auto-reload. Team and legacy Enterprise owners can set organization and user limits, with additional seat-tier or group controls on legacy Enterprise. Current Enterprise organizations can set organization and individual spend limits. One request may slightly exceed a cap because its cost is calculated after it runs.
Keep the July restoration timeline, current seat entitlement and credit balance separate. A model's availability does not settle its billing path.
Use the current matrix to identify the included allowance, then measure the workload's cost and confirm its data-policy requirements. The expired promotion is history; it should not be the rule behind a new budget or an unlimited auto-reload setting.