CometAPI’s AUTO option should not enter a budget forecast as a presumed money-saving default. On its AUTO vs Claude Fable 5 comparison page, captured September 15, 2026, AUTO has a higher listed price for both input and output tokens than explicit Claude Fable 5 selection. That creates a measurable hurdle for adoption—not proof that AUTO is poor value.
Start with the displayed rates
| CometAPI selection | API model ID shown | Input, per million tokens | Output, per million tokens |
|---|---|---|---|
| AUTO | auto |
$75 | $75 |
| Claude Fable 5 | claude-fable-5 |
$10 | $50 |
These are dated vendor-page observations, not independently verified invoice rates or evidence of a newly announced pricing change. The page also shows higher reference prices alongside 20% reductions. The table uses the lower displayed rates; applying another 20% discount would double-count that reduction.
For I million input tokens and O million output tokens, holding volumes equal between the two selections:
- AUTO: $75I + $75O
- Claude Fable 5: $10I + $50O
- AUTO premium: $65I + $25O
That premium is positive for any nonzero equal-volume workload. AUTO’s token-price ratio ranges from 1.5× in the output-only limit to 7.5× in the input-only limit. Input-heavy usage therefore faces the larger proportional hurdle.
As a purely hypothetical budgeting example, 1 million input tokens plus 1 million output tokens would cost $150 with AUTO versus $60 with Fable 5: $90 more, or 2.5× the token spend. This is arithmetic, not a measured customer workload or a comparison of equivalent results.
Set an adoption threshold, not a savings assumption
Equal token volumes are useful for isolating the price difference. They do not tell us how many tokens either selection would consume to finish the same task successfully.
For a budget-led evaluation, define an acceptance standard first, then compare both selections on the same tasks. Count token consumption across attempts, including retries, and compare the same number of accepted tasks. At the displayed rates, token-cost parity requires:
75I_AUTO + 75O_AUTO ≤ 10I_Fable + 50O_Fable
All token quantities here are in millions. If both selections retain a 1:1 input/output mix, AUTO would need to consume at most 40% of Fable 5’s token volume to reach parity. That is a derived target—not evidence that AUTO can meet it. Different token mixes require the full inequality rather than that shortcut.
A measured quality or latency improvement could justify spending more even without token-cost parity. Establish that benefit separately and put an explicit ceiling on the premium you are willing to pay.
What this page cannot settle
The comparison does not establish AUTO’s routing policy, underlying model selection, quality advantage, latency, retry behavior, or tokens per accepted task. Its generic FAQ and platform-wide failover language are not evidence of AUTO-specific behavior. Likewise, dashes for context window, maximum output, and cached input are missing information—not zero values or proof that a feature is unsupported.
For this CometAPI choice, use explicit Fable 5 as the lower listed token-price baseline, verify applicable billing terms before spending, and ask an AUTO evaluation to justify the premium. The unresolved question is not whether AUTO costs more at equal token volumes—it does at these rates—but whether it delivers enough measured benefit per accepted task to warrant that difference.