Claude Fable 5.2 API: Tool Use Costs and Safe Retries

Anthropic released Claude Fable 5.2 on November 9, 2026, for agent tasks that run for hours. One cost in these tasks is easy to miss. Each data tool result stays in the conversation, and the next request sends all earlier results again. So request 20 carries the results of the first 19 calls.

The size of each result, when you trim it, and how you retry without a second charge decide the cost. In our estimate below, model input for the same 18-call turn costs from $0.512 to $10.383, based on these choices.

We used a typical research task to measure this. We sent 20 live requests to the EveryInfra data API for Reddit, Trustpilot and YouTube. We sent them on November 14, 2026, at 13:07, 13:26 and 13:44, Singapore time. For each request we recorded the bytes, the result count, the time and the charge. Then we used the public Fable 5.2 prices to estimate the model token cost.

We did not run the model, so the model code and the token estimates are configuration examples.

Claude Fable 5.2 API: eight facts to check before you build

Anthropic released Claude Fable 5.2 and Claude Mythos 5.2 on November 9, 2026, a Monday in the United States (Anthropic launch post). The launch post says that the two names point to the same underlying model. Fable has extra safeguards for cybersecurity and biology, and all users can call it. Mythos goes only to organizations that pass a verification program. The system card carries the same date, and CNBC reported the launch on the same day.

All primary sources give November 9 as the launch date, and this article uses that date. Anthropic edited the launch post on November 11, 2026. The edit changed one sentence about math formalization and added a footnote. It did not change anything about the API.

Long agent runs fail in two ways: they cost more than planned, or they break on a retry. So we read the model page, the "What's new" page, the pricing page and several feature pages on November 14, 2026. We saved a copy of each page. The table below lists the facts that change how you write a long tool loop.

Forced tool use and edited history make Fable 5.1 code fail with a 400 error on Fable 5.2. First, forced tool use. On Fable 5.1, some code sets tool_choice: {"type": "tool", "name": "..."} to make the model call one tool. On Fable 5.2, that code fails with a 400 error. The official fix is to keep auto and set strict: true on the tool. Then the input always matches your JSON Schema (strict tool use docs).

We tested the same limit on Opus 5.5 in October, in Claude strict tool use with a data API. This article does not repeat that test. It uses strict mode only in the tool definitions further down. The topic here is different: what a long run of data tool calls costs, and how to retry those calls safely.

Second, edited history now fails. Each Fable 5.2 thinking block stores a fingerprint of everything before it: the system prompt, the tool definitions and every earlier message. When you send the block back, the API checks that this content did not change. The docs say that even one word in a tool description counts as a change (prefix checks).

Do not shorten old tool results after the conversation grows. On Fable 5.2, that edit makes the next request fail with the message The block is bound to a different conversation (What's new). So you must trim a result before you first append it to messages. To remove old results later, use server-side context editing. The docs say that server-side clearing never invalidates thinking blocks (context editing).

One more fact affects every token number in this article. Fable 5.2 uses the tokenizer that started with Opus 4.7. The docs say this tokenizer counts about 30% more tokens for the same text than older models (token counting). We do not have a Fable 5.2 API key, so we could not count tokens with the official endpoint.

All token numbers below are therefore estimates. The lower bound uses the pricing page example "Average webpage (10 kB): ~2,500 tokens", which is about 4 bytes per token (pricing page). The upper bound multiplies that by 1.3. The token counting endpoint is free. If you have a key, you can send our saved responses to it and get exact numbers.

The task: about 20 data tool calls in one turn

The AWS launch blog says the model can run unattended for hours to days.

We picked a common research job to measure this. The prompt is one sentence: "Compare user feedback from the last month for Notion, ClickUp, Asana and monday.com, and list the top three praises and complaints for each." The agent needs real user words from three places. Those places are Reddit threads, Trustpilot reviews and comments under YouTube review videos.

EveryInfra has four capabilities for this job: reddit/search (capability page), trustpilot/reviews (capability page), youtube/search (capability page) and youtube/comments (capability page). All four use one endpoint, POST /api/v1/social. Each call costs a fixed price, and a call with zero results is not charged.

We wrote down the tool calls that the task needs, in a realistic order, and sent each call to the live API. For each call we saved the raw response, the time, the size in bytes and the charge. The size and the data fee do not depend on the model.

Prices, parameters and fields come from the free catalog, GET /api/v1/social/catalog, as read on November 14, 2026.

Claude Fable 5.2 tool use: how to define the four tools

Each request sends the tool definitions again. The pricing page counts tool names, descriptions and schemas as input tokens. When a request has tools, the API also adds a special system prompt that lets the model use them (tool use pricing). So keep the tool list short. Put the details that the model often gets wrong into the description. This job needs four tools, one for each capability. The code below is a configuration example, because we did not run the model side.

TOOLS = [
  {
    "name": "reddit_search",
    "description": "Search Reddit posts from the last month. Returns at most 25 posts. "
                   "sort must be one of: relevance, newest, popular, rising, top, controversial.",
    "strict": True,
    "input_schema": {
      "type": "object",
      "properties": {
        "keyword": {"type": "string"},
        "sort": {"type": "string", "enum": ["relevance", "newest", "popular", "rising", "top", "controversial"]},
        "limit": {"type": "integer"}
      },
      "required": ["keyword", "sort", "limit"],
      "additionalProperties": False
    }
  },
  {
    "name": "trustpilot_reviews",
    "description": "Reviews of one company on Trustpilot. company is the website domain, e.g. notion.so. "
                   "stars is a list of strings such as [\"1\",\"2\"]. date is one of last7days, last30days, "
                   "last3months, last6months, last12months.",
    "strict": True,
    "input_schema": {
      "type": "object",
      "properties": {
        "company": {"type": "string"},
        "stars": {"type": "array", "items": {"type": "string", "enum": ["1", "2", "3", "4", "5"]}},
        "date": {"type": "string", "enum": ["last7days", "last30days", "last3months", "last6months", "last12months"]},
        "limit": {"type": "integer"}
      },
      "required": ["company", "stars", "date", "limit"],
      "additionalProperties": False
    }
  },
  {
    "name": "youtube_search",
    "description": "Search YouTube videos by keyword. Use it to find review videos; "
                   "pass a result url to youtube_comments.",
    "strict": True,
    "input_schema": {
      "type": "object",
      "properties": {
        "keyword": {"type": "string"},
        "limit": {"type": "integer"}
      },
      "required": ["keyword", "limit"],
      "additionalProperties": False
    }
  },
  {
    "name": "youtube_comments",
    "description": "Comments under one YouTube video URL. sort is newest or popular.",
    "strict": True,
    "input_schema": {
      "type": "object",
      "properties": {
        "url": {"type": "string"},
        "sort": {"type": "string", "enum": ["newest", "popular"]},
        "limit": {"type": "integer"}
      },
      "required": ["url", "sort", "limit"],
      "additionalProperties": False
    }
  }
]

resp = client.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    tools=TOOLS,                      # build once per conversation, send the same copy every turn
    tool_choice={"type": "auto"},     # "any" or "tool" returns 400 on Fable 5.2
    output_config={"effort": "medium"},
    cache_control={"type": "ephemeral"},   # automatic caching moves the breakpoint forward
    messages=messages,
)

We put each enum in the schema and again in the description. With strict: true, the model can only produce values from the enum. The sentence in the description helps the model pick the right value. In the EveryInfra catalog, the Trustpilot stars parameter is a list of strings, not a minimum star number. A model can easily write "stars": 1, so the schema makes it an array of strings.

The model fills in limit, but the executor caps it again (see the next section). Strict mode checks the type of a value. It does not check that the number is sensible.

Keep tools and the system prompt the same for the whole conversation, because the prefix check covers them. To add a tool later, append a role: "system" message with a tool_addition block. The tools array stays the same, and the cache stays valid (mid-conversation tool changes). This feature is in beta and needs the inline-tools-2026-09-15 header.

We set effort to medium. The docs say that Fable 5.2 thinks before almost every reply at high and above. Lower effort means fewer and shorter tool calls (effort docs). Each step in this job needs only a simple decision, so the default high gives little extra value. The docs also warn that the model stops long tasks early more often at low and medium effort (Prompting Claude Fable 5.2). So the system prompt must tell the model to work through timeouts and errors and finish the task.

The executor: copy-ready code for trimming, retries and errors

When the model sends a tool_use block, your own code runs the tool. Most cost and retry decisions happen in this layer. Here you see the full API response, and here you act before the result enters the conversation. The Python below uses the same logic that we used for our measurements. We ran the API side live. The model loop around it is a configuration example.

import os, json, time, requests

API = "https://api.everyinfra.com/api/v1/social"
HEADERS = {"Authorization": f"Bearer {os.environ['EVERYINFRA_API_KEY']}"}
ROUTE = {"reddit_search": ("reddit", "search"),
         "trustpilot_reviews": ("trustpilot", "reviews"),
         "youtube_search": ("youtube", "search"),
         "youtube_comments": ("youtube", "comments")}
KEEP = {"reddit_search": ["title", "community", "like_count", "comment_count", "posted_at", "url", "text"],
        "trustpilot_reviews": ["rating", "title", "text", "posted_at", "country", "is_verified"],
        "youtube_search": ["url", "title", "view_count", "comment_count", "posted_at"],
        "youtube_comments": ["text", "like_count", "reply_count", "posted_at"]}
MAX_LIMIT = {"reddit_search": 25, "trustpilot_reviews": 50, "youtube_search": 10, "youtube_comments": 50}
TEXT_MAX = 280

def trim(name, body):
    """Keep only the fields the model needs, cut long text at 280 characters, keep charged_usd only."""
    rows = []
    for r in body.get("results", []):
        row = {k: r[k] for k in KEEP[name] if r.get(k) not in (None, "", [])}
        if len(row.get("text", "")) > TEXT_MAX:
            row["text"] = row["text"][:TEXT_MAX] + "…"
        rows.append(row)
    return {"id": body.get("id"), "count": body.get("count"),
            "charged_usd": body.get("billing", {}).get("charged_usd"), "results": rows}

def run_tool(name, args, idem_key):
    platform, action = ROUTE[name]
    args = dict(args, limit=min(args.get("limit", 20), MAX_LIMIT[name]))
    payload = {"platform": platform, "action": action, "params": args}
    for attempt in range(4):
        r = requests.post(API, json=payload, timeout=110,
                          headers={**HEADERS, "Idempotency-Key": idem_key})
        if r.status_code == 200:
            return {"content": json.dumps(trim(name, r.json()), ensure_ascii=False)}
        err = r.json().get("error", {})
        if r.status_code == 422:                      # bad parameter: give it back to the model
            return {"content": json.dumps({"error": err.get("message"), "param": err.get("param"),
                                           "allowed": err.get("allowed")}, ensure_ascii=False),
                    "is_error": True}
        if err.get("retryable"):                      # 429, 504 and similar: wait, resend with the same key
            time.sleep(float(err.get("retry_after") or 2 ** attempt))
            continue
        return {"content": json.dumps({"error": err.get("message")}, ensure_ascii=False), "is_error": True}
    return {"content": "tool gave up after 4 tries", "is_error": True}

# Main loop: key = task ID + number of this tool call in the turn; a rerun gets the first result
# task_id is set when you create the task and stays the same on a rerun;
# step_no is 0 at the start of a turn and counts up across model requests
for block in resp.content:
    if block.type == "tool_use":
        step_no += 1
        key = f"{task_id}-{step_no}"
        out = run_tool(block.name, block.input, key)
        tool_results.append({"type": "tool_result", "tool_use_id": block.id, **out})
messages.append({"role": "assistant", "content": resp.content})   # send back exactly as returned
messages.append({"role": "user", "content": tool_results})        # only append at the end

Trimming. The trim function keeps only the fields that answer the question. It cuts review and post text at 280 characters. From the account data in the response, it keeps only charged_usd.

We picked the fields from the catalog response_fields list and wrote them as an allowlist. If the catalog adds a new field later, that field does not enter the context by default. The 280-character limit is our choice for sentiment work. For a task that quotes reviews word for word, keep the full text and drop only the other fields.

Retries without a second charge. Each tool call gets one Idempotency-Key, built from the task ID and the call number in the turn. After a timeout, a 504 or a 429, the code sends the request again with the same key. If the whole turn runs again, each step gets the same key again, and the calls that succeeded before return their first result.

EveryInfra's rule is simple. The same key with the same parameters within 24 hours returns the first result, with no new run and no new charge. The same key with different parameters returns 409 and does not run (llms-full.txt, retries and idempotency). We tested all these cases on November 9, 2026, in API idempotency keys for AI agent retries. Here we check the rule again inside a long run.

Parameter errors go back to the model. A 422 error body has the bad parameter name, all valid values and a suggested value. The code puts these into the tool_result and sets is_error: true. The official docs say to use this field when a tool fails (handle tool calls). The model then fixes the parameter and calls again. A 422 has no data fee, so this round trip costs only a few hundred model tokens.

Which fields to keep: pick them from the free catalog

The EveryInfra capability catalog is free. For each capability, it lists the required and optional parameters and the maximum result count. It also lists response_fields, which are all the fields a result can have. On November 14, 2026, the catalog listed 24 result fields for the Trustpilot reviews capability. We keep 6.

To compare products, the model needs the rating, the text and the date. It does not need author images or review URLs. To compare feedback by language, add the catalog field language. We keep the Trustpilot country field because we compare regions. If you only need the overall sentiment, you can drop it too.

Parameters also change the date range of the results, and so the number of calls in a turn. At 13:45 we searched Asana with newest. This call returned 21 posts, from 03:46 on November 13, 2026 to 12:00 on November 14, 2026, Singapore time. At 13:27 we got Notion's Trustpilot reviews from the last 30 days. The 7 reviews were from October 20, 2026 to November 13, 2026.

For a busy keyword such as Asana, the 21 newest posts covered only about a day and a half. To cover a full month on Reddit, top is the better sort. Put these choices in the tool description. Then the model picks the right value first and does not need a second call.

Live test: 20 requests at three times

The three rounds started at 13:07, 13:26 and 13:44, Singapore time. The first and the last request were 38 minutes apart. Each round sent the calls in the order the task needs them. First, the agent searches Reddit for a brand name. Next, it gets Trustpilot reviews and searches YouTube for review videos. Then it gets the comments under a video.

We added three special cases: one bad sort value, one search with no results, and two requests with the same idempotency key.

Of the 20 requests, 18 returned HTTP 200 (one of them with 0 results), and 17 returned data, with 335 results in total. The 0-result search and the bad parameter that returned a 422 had no charge. One more request was an idempotent replay. It returned the first result and had no new charge. The data API fee was $0.0169 in total, or $0.000050 per result.

Each row in the chart is one call. There are 18 rows, including the search with 0 results. The gray bars are very different. One Reddit search can return tens of KB, but YouTube comments return only a few KB.

The length of the text decides the size, more than the number of fields. The 18 responses with HTTP 200 were 594.5 KB raw and 128.2 KB after trimming. That is 78% less.

"Text share" is the share of result bytes in the text field. The median time counts the calls with HTTP 200 (not the replay), and the number in brackets is the sample size. The 6 reddit/search calls include the one with 0 results. We count text length in characters with Python len().

Text is most of the size in Reddit and YouTube search results. The median text of the 96 Reddit posts has 1,222 characters. Six posts have no text, and we count them as 0; without them, the median is 1,256.5. Of all posts, 84% are longer than 280 characters, and text is 90% of the result bytes.

In YouTube search results, text is the video description. The median of the 20 descriptions is 1,426 characters, all of them are longer than 280 characters, and text is 73% of the bytes. To pick a video, the model needs only the link, title and view count. So we drop the description, and this capability gets 93% smaller. If you only drop fields and keep the full text, a Reddit search gets only about 10% smaller.

YouTube comments are short. The median of the 76 comments is only 136.5 characters, and the 280-character cut applies to only 16% of comments. The other bytes are in fields such as the comment ID, author name, platform name and reply target. For comments, trimming means dropping fields.

Trustpilot is between the two. The median of the 143 reviews is 347 characters, and the cut applies to 57% of reviews. Fields such as the author image, review URL and experience date also take space.

The star rating also changes how often the cut applies. Of the 143 reviews, 117 have 1 or 2 stars, because two of the calls filtered for 1 and 2 stars. Their median text is 441 characters, and 63% are longer than 280.

The 26 reviews with 3 to 5 stars have a median of 212 characters, and 27% are longer than 280. Bad reviews are longer, and a list of the top complaints needs exactly those reviews. So for calls that filter for low stars, you can raise the cut to about 500 characters and keep 280 for the other calls. The 3-to-5-star group has only 26 reviews, so treat its share as a rough sign only.

Every response carries about 830 bytes of account data, such as the charge and the balance. Its size does not depend on the result count. Even the response with 0 results had 868 bytes of it.

Over 20 calls, the account data adds 16.6 KB. At 4 bytes per token, that is about 4,200 tokens, and every later request sends them again. The model does not need the balance for research. Keep only charged_usd when you trim.

After trimming, you can predict the size of each result. For one capability, raw responses for different keywords are very different. In the 5 Reddit searches that returned data, the average post took from 1,462 to 5,812 bytes, about 4 times apart. A full response took from 32.2 KB to 101.6 KB. In the 7 Trustpilot calls, a review took from 1,021 to 1,420 bytes, and a full response took from 6.5 KB to 59.1 KB.

After trimming, a Reddit post took 525 to 582 bytes, and a Trustpilot review took 356 to 403 bytes. A YouTube video from search took about 200 bytes, and a YouTube comment took 169 to 284 bytes. The reason is simple. The 280-character cut puts a ceiling on the text, and the allowlist puts a ceiling on the fields. Only texts shorter than 280 characters still change the size.

So you can estimate the context cost of a call before you send it. Assume about 560 bytes per trimmed Reddit post and 4 bytes per token. Then a call that returns 20 posts adds about 11 KB, or about 2,800 tokens. The same 20 posts in raw form, at 1,462 to 5,812 bytes per post, add 7,300 to 29,000 tokens. You set the context budget and the task budget before the run starts. After trimming, the post count times about 560 bytes is enough to set them.

We calculated these numbers from the 18 calls with HTTP 200 in this test. Only 5 Reddit calls and 2 YouTube search calls returned data. Other keywords and other communities can change the raw size per result. The trimmed ceiling comes from the 280-character cut and the allowlist, so it does not change with the sample.

Time is part of the cost too. For the 17 calls that returned data, the median time was 9.2 seconds (sample size 17). The prompt cache expires after 5 minutes by default. If the model waits for several slow tools between two requests, the cache can expire. Then the next request pays the write price again.

For tasks with slow tools, or with many parallel calls, think about the 1-hour cache (Prompt caching). The section "Where the cache breakpoint goes" shows how to compare the two prices.

What this turn costs

We put the 18 responses with HTTP 200 in time order, as one turn. Then we calculated the input of each model request. Our assumptions: the system prompt, tool definitions and user question use 3,000 tokens. The model writes 500 tokens per step, for the tool call and its thinking. The final answer uses 2,000 more output tokens.

The input of request k is the 3,000 starting tokens, plus all earlier assistant output and tool results. These assumptions are a configuration example. Replace them with the usage numbers from your own task.

With raw results, the last request carries about 160,627 input tokens. With trimmed results, it carries about 44,042 tokens. These are lower bounds at 4 bytes per token. With the new tokenizer at 30% more, the upper bounds are 206,115 and 54,555 tokens.

The 1M-token window can hold this, but each request bills all of its input. The docs also say that accuracy and recall go down as the token count grows. They call this "context rot" (Context windows).

The data API fee for this turn is $0.0169, while model input costs $0.512 to $10.383. The large difference comes from how many times each tool result is sent again.

With no cache and raw results, model input costs $10.383. With cache and trimming, it costs $0.512. That is about 20 times less. Of the two methods, caching has the larger effect, because resent history bills at $0.20 per million tokens. Trimming saves 72% more on top of the cache. The reason is that each new result is first written to the cache at $10 per million tokens, so a smaller result costs less.

You can also split the input cost by tool result, and see which kind to trim first. Result k is sent again in the next 19 − k requests. With no cache, the most expensive single result is call 9, the Reddit search for "clickup" at 13:27. It is 72.7 KB raw, about 18,200 tokens, and it is sent again 10 times, so it costs about $1.45 at $8 per million tokens. The largest result, the Reddit search for "asana" at 13:45 (101.6 KB), comes last and is sent again only once, for about $0.20.

With the 5-minute cache, each result is first written at $10 and then read at $0.20 per million tokens, so its position matters less. The two most expensive results become the Reddit search for "notion" at 13:44 (98.8 KB, about $0.28) and the one at 13:45 (about $0.25), because they are large. With both methods, the three most expensive of the 18 results are Reddit searches. So write the trim allowlist and the 280-character cut for Reddit first.

How we calculate each row: tokens = bytes / 4. With no cache, the cost is tokens × times sent again × $8 / 1,000,000. With the cache, the cost is tokens × $10 / 1,000,000 for the write, plus tokens × (times sent again − 1) × $0.20 / 1,000,000 for the reads.

In this estimate, output costs $0.440. Trimming and caching do not change it. Fable 5.2 bills thinking as output. If each step uses more thinking than our 500 tokens, output can quickly become the largest part. Only effort and the task budget control it. The next section covers them.

We used the official prices that we read on November 14, 2026. Per million tokens, input costs $8, output $40, a cache read $0.20 and a 5-minute cache write $10 (pricing page). The data API fee is the sum of billing.charged_usd in each response. It matches the price_usd of each capability in the catalog.

Three round trips from the test

422: a bad parameter that the model fixes. At 13:11:25 we set the Reddit sort value to hot on purpose. The API returned a 422 almost at once. The error body names sort as the bad parameter and lists all six valid values. The did_you_mean field suggests popular and top. The first item in next_steps says to change only sort and resend, and says that nothing was charged.

Our executor put these fields in an is_error result. Our simulated model followed the suggestion and changed the value to top. The next request, 9 seconds later, returned 13 posts with one charge.

Idempotent replay: one key sent two times. At 13:27:50 we asked for Notion's Trustpilot reviews from the last 30 days, with the idempotency key bl150-notion-30d-20261114-a. This call returned 7 reviews. At 13:28:16 we sent the same key and the same parameters again. The answer came almost at once. The second response had the header Idempotent-Replayed: true and the field replayed: true. The id in its body and its results were the same as the first.

Then we looked up this request ID with the account endpoint GET /portal/api/requests/{id}. The account request records show only one charge for this key: $0.00138889.

Be careful with one thing in your code. The replay returns the first response, and that includes the billing object. So the second body also shows charged: true and charged_usd. The EveryInfra docs say that a replay has the same billing and that nothing runs or is charged again (llms-full.txt). If your code adds up charged_usd from each response, skip the responses where replayed is true. If you do not, your records show more than the real charge.

0 results: change the keyword, no charge. The first request of the first round searched for "notion vs clickup". It returned 0 results, and charged_usd was 0. Reddit search covers only the last month, so long comparison keywords often find nothing. With a single brand name, each search returned 13 to 23 posts.

Give an empty result to the model as it is, and let the model pick a new keyword. Do not retry the same keyword in the executor.

Where the trimmed text goes: a tool to get the full text

Trimming has a cost: the model cannot see the text that you cut. For sentiment tags, 280 characters are enough. But when the model writes its conclusion, it can need the second half of one review to quote a user.

Do not put the full text back into the conversation. Instead, save each raw response on disk in the executor, and index it by the response id and the result number. Then give the model one small tool, such as get_full_text(id, index), that returns the full text of one result.

The earlier tool results do not change, so the prefix check does not fail. A request for full text is a new tool call at the end, and the history only grows.

The tool does not call the data API, so it has no data fee and adds only a few hundred model tokens. The saved raw responses are also an audit record: for each call, you can see the time, the charge and the data that came back.

Put this tool in tools at the start of the conversation. If you add it later, the tools array changes and the prefix check fails. If you must add it later, use the tool_addition system message, which is in beta. In the tool description, say that it returns the text of one result, does not go online and has no charge. Then the model does not use it as a search tool.

Where the cache breakpoint goes

With automatic caching, the cache breakpoint moves forward as the conversation grows. New content bills at the write price first, and at the read price in the next request (Prompt caching). In a long turn, each tool result is written once and read many times. For example, the result of call 3 is read again in requests 4 to 20.

So, with caching, the largest part of the input bill is often the new part that each step writes. Trimming decides the size of that part.

Put the tool definitions and the system prompt first. They do not change during the turn, so after the first write they bill at the read price. Two rules apply here. Do not change any word in a tool description, and that includes timestamps and random examples. Do not put a changing field in the system prompt, such as the current time. It breaks all later cache entries. If the model needs the time, put it in a user message or give the model a tool for it.

The cache lifetime is another number to check. In our test, the 17 tool calls that returned data had a median time of 9.2 seconds. If the model sends 5 parallel calls and then thinks, one or two minutes between requests is normal. The 5-minute cache usually survives that. If a person must approve a step, or a tool waits in a queue, use the 1-hour cache.

The 1-hour write price is 2 times the base input price, so $16 per million tokens. That is $6 more than the 5-minute write price of $10. When the cache expires, the full prefix bills at the write price again.

Here is the math for our trimmed turn. The last request carries about 44,042 tokens. If the 5-minute cache expires at that point, the rewrite costs 44,042 × $10 / 1,000,000 ≈ $0.44. Now assume that every new part of the turn uses the 1-hour write price. Then the extra cost for the whole turn is 44,042 tokens × $6 / 1,000,000 ≈ $0.26. So one expiry costs more than the 1-hour price difference for the full turn.

The same numbers at 100 turns per day

Assume that a team runs 100 research turns like ours each day. With raw results and no cache, model input, output and data fees cost about $1,083.94 per day. With trimming and cache, they cost about $96.93 per day. Most of the difference is model input. The data API fee is the same in both cases, about $1.69 per day.

This estimate does not include retries. The next section shows how to retry without a second charge.

Which errors to retry, and which to give back to the model

A long turn can have dozens of tool calls. If one call stops, the whole turn waits. So the executor must decide for the model. Some failures go away if you send the same request later. Other failures come from a bad parameter, and only the model can fix them. Your code retries the first kind and gives the second kind to the model.

Do not parse the error text to decide. Every EveryInfra error body has a fault field and a retryable field. The fault field tells you if the request, the account or the service caused the error. The retryable field tells you if the same request can succeed later. A retryable error also has retry_after in seconds (llms-full.txt, errors section).

Do not give a 409 conflict or a 503 "outcome unknown" error to the model. Also, do not resend these requests as they are. A 409 conflict means that your code used one key for two different calls. The model cannot fix that, so log an alert in your code and keep it out of the conversation.

For a 503 "outcome unknown" error, the charge is not final yet, and a resend can add a second charge. The docs say: do not send it again, keep the request ID and check later.

The model API can fail too, and you must handle it in a different layer. In the Anthropic error docs, 429 is a rate limit and 529 means the API is temporarily overloaded. You can retry both after a short wait (Errors). By default, the official Python SDK retries connection errors, 408, 409, 429 and 5xx errors two times, with a short backoff (Python SDK docs). The same page says that SDK version 2.0.0 is the first to use API version 2026-10-21. Read the migration notes before you upgrade to a new major version.

A retry of the model request does not run the tool again. Your code runs the tool only after it gets a tool_use block. But if you run the whole turn again from the start, the model sends the same tool calls again. In that case, the idempotency key on the tool side protects you. The key comes from the task ID and the tool call number, not from a random value. So on a rerun, each step gets the same key, the calls that succeeded before return their first result, and you pay only once.

Anthropic uses a token bucket for rate limits. The docs give an example: a limit of 60 requests per minute can be enforced as 1 request per second (Rate limits). The same thing can happen on the tool side. The model can send several parallel tool_use blocks. If your code sends them all at once, they can hit the per-minute limit in the same second.

The parallel tool use docs say that the next user message must return one tool_result for each tool_use block, all together. If one call fails, you still return a result with is_error: true and a short explanation (Parallel tool use). So if one parallel call waits for retry_after, keep the other results. Send all of them when the last one is ready.

If you do not want to write an executor, you can use the Tool Runner in the official SDK. It runs the tool loop for you (Tool Runner). The Messages API can also connect to remote MCP servers directly (MCP connector). Both options remove the loop code.

But you cannot change a tool result before it enters the context, so trimming depends only on the server format. For paid, retried calls, we suggest your own executor, with REST and an Idempotency-Key. See API idempotency keys for AI agent retries for the details.

Five more controls besides trimming

Trimming controls the size of each tool result. The Fable 5.2 API has five more settings that affect the cost of a long turn. Each one acts on a different part of the bill, so you can use them together. Every row below comes from the official docs, read on November 14, 2026. Rows marked "beta" need the matching beta header.

The sources are, in order: prompt caching, effort, task budgets, context editing and compaction on demand.

The task budget is the setting closest to tool calls. The docs give an example with three requests.

Your client resends the full history each time, so the payload grows. But the budget only counts what is new to the model.

In the example, the three requests use only 19,000 of a 100,000-token budget (task budgets). The task budget counts only the tokens that are new to the model. The bill counts all the input that you send in each request. Trimming reduces both. The budget only helps the model finish cleanly when it runs low.

The docs suggest a way to pick the number. Run a set of typical tasks without a budget and record the tokens each task uses. Start from the 99th percentile of that data. The budget must be at least 20,000 tokens, or the request fails with a 400 error.

Server-side clearing and your own trimming do not conflict. Our trimming acts when a result first enters the conversation, and it keeps the fields that the model will use later. Server-side clearing removes old results that the model has already used. For example, after the model writes a summary of the first ten searches, those raw results can go. The docs warn that clearing breaks the cache after the cleared point. Use clear_at_least to clear a large block at once, not a small part each turn (context editing).

Limits and things to watch

We did not run the model side. The tool definitions, the main loop and the token costs are configuration examples and estimates. We converted bytes to tokens and did not check them with the official counter. When you run your own loop, use the usage object in each response. Our assumption of 500 output tokens per step fits data research, where each step is a simple decision.

Thinking bills at the output price of $40 per million tokens. If each step uses 2,000 output tokens, output for this turn of 18 steps plus the conclusion goes from $0.440 to (18 × 2,000 + 2,000) × $40 / 1,000,000 = $1.52. That is more than the $0.512 of trimmed, cached input. Only effort and the task budget control that part.

Reddit search covers only the last month, and the sort value does not change that range. The catalog states this. For older threads, use a different capability, such as listing posts in one community. Trustpilot needs the company domain, such as notion.so. YouTube comments need a video URL, so the agent first calls youtube/search, and that is one more paid call.

Fable 5.2 thinking blocks work only in the account that created them, or in a linked account. A move from Fable 5.2 to another model loses the reasoning of those turns (What's new). If your code retries a refused request on another model, that turn loses its reasoning, and the cost goes up. Fable 5.2 also needs 30-day data retention by default. Zero data retention needs separate approval. Teams that process review text should check this before they start.

Recent changes

• November 9, 2026: Anthropic released Claude Fable 5.2. The price went from $10 / $50 to $8 / $40 per million tokens, and cache reads cost $0.20 (launch post). For you: the same long task costs 20% less on the model side, and resent history is cheap when it hits the cache.
• November 9, 2026: GitHub Copilot added Fable 5.2. The changelog says the model solved more tasks "while using fewer steps and tool calls" in early tests (GitHub changelog). For you: with fewer calls, the size of each result matters more.
• November 9, 2026: Fable 5.2 went live on Amazon Bedrock and Claude Platform on AWS. The AWS blog says that on Bedrock, your code must retry refused requests (AWS blog). For you: you need retry logic for the model, too, not only for the tools.
• October 22, 2026: The IETF draft for the Idempotency-Key header reached version 08. Its goal is safe retries for methods such as POST (IETF draft). For you: an idempotency key on data API calls is becoming standard practice.

FAQ

Do I need a separate Claude Fable 5.2 API key, and what is the model ID?

No. The docs say Fable 5.2 is open to all Claude API customers, with the model ID claude-fable-5-2. Only Mythos 5.2 needs a verification program (What's new). The migration guide gives a Claude Code command that changes your code for you. Source of the question: the Google suggestion "claude fable 5.2 api key", read on November 14, 2026.

What is the Claude Fable 5.2 context window and token limit?

The context window is 1M tokens, and one response can have up to 128K output tokens (model page). In our estimate, the last request of our test turn (18 tool calls with HTTP 200) carries about 160,627 tokens with raw results and about 44,042 tokens with trimmed results. Source: the suggestions "claude fable 5.2 context window size" and "claude fable 5.2 api token limit".

Why does tool_choice return a 400 error on Claude Fable 5.2?

Fable 5.2 does not support forced tool use. A tool_choice of any or of one named tool returns a 400 invalid_request_error. The docs say to keep auto and add strict: true, or to use JSON outputs (What's new). Source: the suggestion "claude fable 5.2 tool_choices".

Are thinking tokens billed at the output price?

Yes. A developer on r/claude warned that thinking tokens bill at $40 per million (r/claude post). You cannot turn adaptive thinking off on Fable 5.2. You can only change effort.

The docs suggest starting at high, the API default (Prompting Claude Fable 5.2). Data tasks with many simple steps suit medium or low.

How much cheaper is a cache read than a cache write?

A post in r/ClaudeCode with 346 points complains that Fable 5.2 uses too much of the plan limit (r/ClaudeCode post).

Here is the math at official prices. A 1-hour write is 2 times the input price, so $16, and a read is $0.20, which is 80 times less. A 5-minute write is $10, which is 50 times more than a read. Output is $40, which is 200 times more than a read. In a long turn, almost all resent history can be a cache read, if you never change tools, the system prompt or old messages.

Is Claude Fable 5.2 a good fit for dozens of tool calls in one turn?

The docs list multi-hour agent sessions and multi-step research as typical uses for Fable 5.2. Anthropic also suggests that most tasks start on Opus 5.5 and move to Fable only when evals fall short (launch post). The launch post adds that Fable 5.2 can act as an orchestrator that gives simpler tasks to smaller models. In this article's job, code fetches and trims the data, and the model only makes decisions, which follows the same idea. Source: the suggestion "claude fable 5.2 tool use cases".

Get started

1. Sign up and get an API key in the EveryInfra console. Run one POST /api/v1/social call with the quick start.
2. Read the free catalog, GET https://api.everyinfra.com/api/v1/social/catalog?platform=reddit. Check capability names, valid parameter values and response_fields, and put the fields you need in your trim allowlist.
3. Write the four tool definitions as above, with strict: true and tool_choice set to auto. Add the Idempotency-Key header and the 422 handling in the executor.
4. Run 10 typical tasks without a task budget. Record the usage of each response and the size of each tool result. Then pick effort, cache lifetime and budget.
5. If you do not want to write an executor, use the remote MCP server (MCP setup). Its tool names start with everyinfra_. For scheduled jobs and calls that retry, use REST with an Idempotency-Key, as in the executor code. See the idempotency key guide.

Prices are on the pricing page and in the catalog. For all capabilities, see the Reddit, Trustpilot and YouTube platform pages.

References

All pages were read on November 14, 2026, Singapore time. Dates in brackets are the dates of the pages.

1. Anthropic: launch post for Claude Fable 5.2 and Claude Mythos 5.2 (2026-11-09, edited 11-11) <https://www.anthropic.com/claude-fable-and-mythos-5-2>
2. Anthropic: Claude Fable 5.2 / Mythos 5.2 system card (2026-11-09) <https://www.anthropic.com/document/claude-fable-5-2-mythos-5-2-system-card>
3. Claude docs: Claude Fable 5.2 model page <https://platform.claude.com/docs/en/models/fable-5-2/overview>
4. Claude docs: What's new in Claude Fable 5.2 <https://platform.claude.com/docs/en/models/fable-5-2/whats-new-fable-5-2>
5. Claude docs: Migrate to Claude Fable 5.2 <https://platform.claude.com/docs/en/models/fable-5-2/migration-guide>
6. Claude docs: Pricing <https://platform.claude.com/docs/en/about-claude/pricing>
7. Claude docs: Models overview <https://platform.claude.com/docs/en/about-claude/models/overview>
8. Claude docs: Tool use overview <https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview>
9. Claude docs: Handle tool calls <https://platform.claude.com/docs/en/agents-and-tools/tool-use/handle-tool-calls>
10. Claude docs: Strict tool use <https://platform.claude.com/docs/en/agents-and-tools/tool-use/strict-tool-use>
11. Claude docs: Parallel tool use <https://platform.claude.com/docs/en/agents-and-tools/tool-use/parallel-tool-use>
12. Claude docs: Tool Runner <https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-runner>
13. Claude docs: MCP connector <https://platform.claude.com/docs/en/agents-and-tools/mcp-connector>
14. Claude docs: Prefix checks <https://platform.claude.com/docs/en/build-with-claude/preserved-thinking/prefix-checks>
15. Claude docs: Context editing <https://platform.claude.com/docs/en/build-with-claude/context-editing>
16. Claude docs: Compaction on demand <https://platform.claude.com/docs/en/build-with-claude/compaction-on-demand>
17. Claude docs: Task budgets <https://platform.claude.com/docs/en/build-with-claude/task-budgets>
18. Claude docs: Mid-conversation system messages and tool changes <https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages>
19. Claude docs: Prompt caching <https://platform.claude.com/docs/en/build-with-claude/prompt-caching>
20. Claude docs: Effort <https://platform.claude.com/docs/en/build-with-claude/effort>
21. Claude docs: Token counting <https://platform.claude.com/docs/en/build-with-claude/token-counting>
22. Claude docs: Context windows <https://platform.claude.com/docs/en/build-with-claude/context-windows>
23. Claude docs: Prompting Claude Fable 5.2 <https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-2>
24. Claude docs: Refusals and fallback <https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback>
25. Claude docs: Fast mode <https://platform.claude.com/docs/en/build-with-claude/fast-mode>
26. Claude docs: Batch processing <https://platform.claude.com/docs/en/build-with-claude/batch-processing>
27. Claude docs: Errors <https://platform.claude.com/docs/en/api/errors>
28. Claude docs: Rate limits <https://platform.claude.com/docs/en/api/rate-limits>
29. Claude docs: Python SDK <https://platform.claude.com/docs/en/api/sdks/python>
30. GitHub: anthropic-sdk-python repository <https://github.com/anthropics/anthropic-sdk-python>
31. Anthropic Engineering: Writing tools for agents <https://www.anthropic.com/engineering/writing-tools-for-agents>
32. Anthropic Engineering: Effective context engineering for AI agents <https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents>
33. IETF: Idempotency-Key HTTP header draft, version 08 (2026-10-22) <https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/>
34. RFC 9110: HTTP Semantics, idempotent methods <https://www.rfc-editor.org/rfc/rfc9110#name-idempotent-methods>
35. Stripe docs: Idempotent requests <https://docs.stripe.com/api/idempotent_requests>
36. Model Context Protocol specification: Tools <https://modelcontextprotocol.io/specification/2025-06-18/server/tools>
37. EveryInfra: llms-full.txt (retries, idempotency and errors) <https://api.everyinfra.com/llms-full.txt>
38. EveryInfra: Reddit capability catalog (free) <https://api.everyinfra.com/api/v1/social/catalog?platform=reddit>
39. GitHub changelog: Claude Fable 5.2 in GitHub Copilot (2026-11-09) <https://github.blog/changelog/2026-11-09-claude-fable-5-2-in-github-copilot/>
40. AWS Machine Learning Blog: Claude Fable 5.2 on AWS (2026-11-09) <https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-2-on-aws/>
41. CNBC: Anthropic releases Claude Fable 5.2 and Mythos 5.2 (2026-11-09) <https://www.cnbc.com/2026/11/09/anthropic-claude-fable-5-2-mythos-5-2.html>
42. The Verge: Anthropic releases Fable 5.2 and Mythos 5.2 <https://www.theverge.com/ai-artificial-intelligence/1030005/anthropic-claude-fable-mythos-5-2>
43. Reddit r/claude: PSA on Fable 5.2 pricing, thinking tokens bill as output <https://www.reddit.com/r/claude/comments/1xtz7tp/psa_on_claude_fable_52_pricing_so_the_base_price/>
44. Reddit r/ClaudeCode: Fable 5.2 uses too much of the plan limit (346 points) <https://www.reddit.com/r/ClaudeCode/comments/1xusayn/fable_52_uses_so_much_usage_its_basically/>
45. Reddit r/ClaudeAI: Fable 5.2 cost per task <https://www.reddit.com/r/ClaudeAI/comments/1xs292a/>
46. YouTube: first-look video on Fable 5.2 (2026-11-12) <https://www.youtube.com/watch?v=xKlUf-dw_Lw>