Anthropic cut Fable 5.2 token prices by 20%, but the cost per task rose 31% in a benchmark

If your AI agent spends hours fixing code, lower token prices are no guarantee of savings. Anthropic has released Fable 5.2 with prices 20% below the previous version, but in one independent benchmark of professional tasks, the average bill per attempt rose 31%. The reason is straightforward: the model checks its own work more thoroughly. For teams, this is a reason to revisit reasoning settings and calculate the cost of a result that passes review.

Fable 5.2 launched alongside Mythos 5.2. Anthropic is positioning the new models for complex technical projects where the task definition continues to change as work progresses. The release coincided with the start of the company's presentations to investors ahead of its IPO, but developers have a more practical question to consider: how much additional checking is worth buying from the model.

Why cheaper tokens made for a more expensive task

One million input tokens for Fable 5.2 cost $8, while output tokens cost $40. Fable 5.1 charged $10 and $50, respectively. But the final bill also depends on the amount of work performed: how much the model reasons, calls tools and rechecks intermediate solutions.

According to SemiAnalysis's analysis, in the GDPx benchmark the new version sometimes generated hundreds or thousands of checks where previous models had limited themselves to around twenty. It was also more willing to bring in additional agents to independently verify a solution. The average cost per task rose from $67.16 to $88.15. Fable scored 16.4%, the best result in this benchmark, but that percentage cannot be extrapolated to everyday development.

Imagine migrating a service to a new library. The agent updates API calls, runs tests, then starts checking unusual combinations of parameters and asks another agent to review the patch again. That work could catch a nasty bug before release. If the change concerns an internal prototype built for a single evening, the cost of the same level of care becomes harder to justify. This is a hypothetical illustration of how costs accumulate, not a published experiment.

Maximum reasoning does not guarantee maximum value

Fable offers five effort levels: Low, Medium, High, Xhigh and Max. The Claude and Claude Code applications use Medium by default. The setting affects how many resources the model can spend on a solution.

One important detail in the release: several evaluations showed that increasing effort does not always improve results. In Vals, High outperformed Xhigh and Max. According to Anthropic, on FrontierCode 2.0, Fable on High matched Opus 5.5 on Max at roughly half the cost per task. The latter is a vendor claim that should be checked separately on your own code.

Nor is there any across-the-board superiority. In the independent measurements cited, Fable trailed some competitors on terminal tasks and automation. First place in an overall ranking therefore says little about whether a particular workflow will become cheaper: fixing regressions, preparing financial documents or working in a browser.

The official announcement explains the positioning of Fable and Mythos, while Cursor's documentation helps you check the specifics of using the model in the editor. When migrating, reassess the settings: the same mode name across versions does not guarantee the same resource consumption.

What to check before switching

Take a few dozen completed tasks from your own project and run them on your current model, Fable Medium and Fable High. Define acceptance criteria in advance: whether tests pass, requirements are met and how many revisions a human requests. Compare spending alongside waiting time and manual rework.

A useful metric is the total cost of all attempts divided by the number of accepted results. It accounts for both cheap failures and expensive successful runs. For long-running jobs, set a budget, a time limit and stopping conditions; otherwise, additional checking can easily turn into an unplanned expense.

Fable 5.2 deserves a trial on complex migrations and tasks with incomplete requirements. Moving everyday requests over en masse should be justified by your own measurements. If High already delivers a usable solution, the next effort level needs to prove its value.