# Is OpenAI API cost vs Claude lower for your workload? > Compare OpenAI API cost vs Claude by task, cached input, output, retries, and quality, then build a router that chooses per call. API invoices do not answer which provider costs less. They show coefficients. Your workload supplies the variables: uncached input, cached input, output, retries, tool turns, reasoning tokens, and the share of calls that need an expensive model. That distinction changes the answer. OpenAI can be markedly cheaper for a short classification call, Claude can cost less for a frontier call with heavy output, and either provider can win on a repeated long context once cache hits become reliable. A sensible comparison prices completed work, not one million imaginary tokens. The examples below use the public OpenAI and Anthropic API price sheets available when this was written. Both vendors change models and prices, so keep the method and refresh the coefficients before you approve a budget. ## Token prices are coefficients, not a verdict The current list prices produce three useful comparison bands, but the models within a band are not interchangeable. Capability must pass your eval before price matters. - High volume: GPT-5.6 Luna costs $0.20 input, $0.02 cached input, and $1.20 output per MTok. Claude Haiku 4.5 costs $1.00, $0.10, and $5.00. - General production: GPT-5.6 Terra costs $2.00 input, $0.20 cached input, and $12.00 output. Claude Sonnet 4.6 costs $3.00, $0.30, and $15.00. - Difficult work: GPT-5.6 Sol costs $5.00 input, $0.50 cached input, and $30.00 output. Claude Opus 4.8 costs $5.00, $0.50, and $25.00. MTok means one million tokens. Anthropic also lists Claude Sonnet 5 at a promotional $2 input and $10 output through August 31, 2026, then $3 and $15. I would not build a yearly forecast around a temporary rate. Put both periods into the forecast if traffic crosses that date. The OpenAI model comparison page calls Luna cost-sensitive, Terra the balance of intelligence and cost, and Sol the frontier option. Anthropic positions Haiku, Sonnet, and Opus in a similar ascending order. Those labels help you choose candidates, but they do not prove equivalent quality. A support classifier may pass on both cheapest models while a repository migration passes on neither. The first accounting formula is simple: ```text call_cost = uncached_input_tokens * input_rate / 1_000_000 + cached_input_tokens * cache_read_rate / 1_000_000 + output_tokens * output_rate / 1_000_000 + provider_tool_fees ``` Use reasoning tokens in the category where the provider reports and bills them. OpenAI reasoning models can consume internal reasoning tokens that appear in output usage even when the user never sees that text. Do not estimate cost from visible characters. This table also exposes why blanket claims fail. Luna has a strong price advantage over Haiku 4.5 on the listed rates. Sol and Opus 4.8 have equal input and cache-read rates, but Opus output is cheaper. Terra and Sonnet 4.6 sit closer together. Tokenization, response length, retries, and pass rate can reverse a narrow list-price advantage. ## Task shape decides which rate matters A workload profile should describe token flow and acceptance criteria for each task, because task names alone hide the expensive part. "Customer support" might mean a 200-token intent label or a 6,000-token answer grounded in account history. I split production calls into five shapes: - Classification and extraction put pressure on small inputs and tiny structured outputs. The cheapest capable model and its retry rate usually decide the cost. - Retrieval-grounded answers repeat instructions around changing documents. The cacheable prefix and retrieved context size matter most. - Document transformation has large unique inputs and predictable outputs. Input price, output expansion, and batch eligibility decide the bill. - Coding and tool agents send large schemas through growing histories. Total turns, reasoning effort, cache stability, and tool fees matter. - High-stakes synthesis uses large contexts and long answers. Pass rate, review cost, and output price dominate. For classification, a cheap model that returns valid JSON on the first attempt usually wins. Suppose a call sends 1,200 input tokens and receives 80 output tokens. At Luna rates, the token cost is $0.000336. At Haiku 4.5 rates, it is $0.0016. That gap matters at millions of calls, provided both models meet the same accuracy and schema tests. For summarization, output ratio becomes important. A 60,000-token contract distilled to 2,000 tokens is input-heavy. A 3,000-token brief expanded into a 12,000-token draft is output-heavy. The same two models can swap positions because output tokens cost several times more than input tokens. Agents need a different unit. Price the whole run that reaches an accepted state. A model with a lower per-token rate can cost more if it calls tools twice as often, produces verbose intermediate messages, or needs a second repair pass. Record `run_id`, task type, every model call, tool charges, final acceptance, and reviewer minutes. A call-level dashboard without a run-level join will reward the wrong model. Do not equate "frontier" with "must use for every step." A coding agent may need a strong model to plan and review while a cheaper model handles file classification, log condensation, or deterministic formatting. Conversely, routing a subtle security review to the cheap tier can increase cost through missed defects and human rework. Price follows the decision boundary, not the prestige of the model name. ## Caching changes long-context economics Prompt caching pays when a stable prefix is read enough times before it expires. It does not make a large, constantly changing prompt cheap. Both current GPT-5.6 and Claude price a cache read at one tenth of base input. Both charge 1.25 times base input for a short cache write. Anthropic documents a five-minute default cache lifetime and a one-hour write at twice the base input rate. OpenAI supports implicit and explicit caching for GPT-5.6; its model guidance tells developers to track cache writes and cached tokens rather than assume every repeated prompt hits. For a cacheable prefix of `P` tokens, `N` calls, base input rate `R`, write multiplier `W`, and read multiplier `H`, compare: ```text uncached_cost = N * P * R cached_cost = P * R * W + (N - 1) * P * R * H ``` The common token and rate terms cancel when you calculate break-even. With a 1.25 write and 0.10 reads, two calls cost 1.35 units with caching versus 2 units without it. One call loses because you paid 1.25 units to create a cache entry you never reused. A one-hour Anthropic write costs 2 units, so it needs three calls to beat three uncached reads. This math excludes the variable suffix and output because they cost the same in both cases. Here is a concrete GPT-5.6 Terra example. A support agent has a 40,000-token stable prefix containing policy, examples, and tool definitions. It handles 100 requests while that prefix remains reusable. Uncached prefix input costs `40,000 * 100 * $2 / 1M`, or $8.00. One cache write plus 99 reads costs `40,000 * ($2 * 1.25 + 99 * $0.20) / 1M`, or $0.892. The variable user messages and outputs still belong on the invoice. Cache placement matters more than the checkbox. Put stable material first: tool definitions, system policy, reference documents, then the changing conversation. Anthropic states that its prefix order is `tools`, `system`, and `messages`; changing an earlier layer invalidates that layer and everything after it. A timestamp, request ID, shuffled tool list, or per-user sentence near the front can turn an expected hit into a write. I have seen teams celebrate a nominal 90 percent cache discount while their prompts earned almost no hits. They generated tool schemas from an unordered map, embedded the current time in the system prompt, and placed account-specific text before the shared handbook. The dashboard showed plenty of input and a little cached input, but nobody divided cached prefix tokens by eligible prefix tokens. After stabilizing serialization and moving volatile fields to the suffix, the discount became real. Track cache economics with four numbers per task: eligible prefix tokens, cache-write tokens, cache-read tokens, and uncached input tokens. A high request count says nothing about reuse if requests arrive outside the cache lifetime or prefixes differ by one byte. ## Output tokens often control the invoice Output is expensive enough that response policy can outweigh input savings. On the models in the table, output costs five to six times the base input rate, except Opus 4.8 at five times. Consider a general-production call with 8,000 uncached input tokens and 3,000 output tokens. GPT-5.6 Terra costs `$0.016 + $0.036`, or $0.052. Claude Sonnet 4.6 costs `$0.024 + $0.045`, or $0.069. If the OpenAI response grows to 5,000 tokens while Claude finishes in 3,000, Terra costs $0.076 and Claude stays at $0.069. The cheaper rate lost because the system used more billable output. Do not solve this with a vague instruction to "be concise." Define the artifact. Ask for a fixed JSON schema, a maximum number of findings, one patch instead of a tutorial plus a patch, or citations only for claims that need evidence. Then verify that shorter output still passes the task. Reasoning settings deserve the same treatment. OpenAI's model guidance recommends testing the current reasoning effort and one lower setting on representative work. That is sound advice because a lower effort can reduce reasoning tokens and latency, but only an eval can tell you where quality drops. Anthropic's extended thinking also consumes billable tokens. Provider terminology differs; the accounting problem does not. Measure useful output rather than raw length. For a code review, useful output might be unique accepted findings. For extraction, it is valid populated fields. For an agent, it is a completed run with no human correction. Cost per accepted unit catches verbosity and failure in one number: ```text cost_per_accepted_run = total_model_cost + tool_cost + retry_cost + reviewer_cost divided by accepted_runs ``` Reviewer cost belongs here even if finance sees it on a different bill. Saving two cents on inference while adding four minutes of senior engineering review is a loss. This is why model comparisons run only against public benchmarks rarely predict your operating cost. ## A workload ledger beats a monthly average The minimum useful cost dataset stores one row per model call and joins those calls to a completed business task. Aggregate provider spend is too coarse for routing decisions. Use a record shaped like this: ```json { "run_id": "run_7f31", "task": "support_reply", "route": "general", "provider": "openai", "model": "gpt-5.6-terra", "input_tokens": 8421, "cached_input_tokens": 6100, "cache_write_tokens": 0, "output_tokens": 734, "tool_cost_usd": 0, "latency_ms": 2840, "attempt": 1, "accepted": true, "review_seconds": 18 } ``` Keep the raw provider usage fields alongside normalized fields. OpenAI and Anthropic use different names, and those names change. A normalized table helps analysis; raw payloads let you repair the normalization without losing history. For each task and route, calculate cost per accepted run, p50 and p95 latency, first-pass acceptance, retry count, cache-read ratio, and reviewer time. Calculate token ratios as well. A tokenizer can turn identical text into different token counts, so multiplying the same estimated token count by both vendors' rates is not a fair comparison. Send the same production samples, then use each response's reported usage. An evaluation set should contain ordinary calls, edge cases, and expensive failures. Sample by workload segment rather than taking the latest hundred requests. If 70 percent of traffic is short English classification and 5 percent is long multilingual synthesis, your test set should preserve that mix or state the deliberate weighting. Do not let an automatic judge decide alone when the task affects money, access, or customer communication. Use deterministic checks where possible, such as schema validity, exact calculations, test execution, and citation presence. Add a blind human rubric for the judgment that remains. The model that wins another model's preference score may still produce more corrections in production. One weekly view is especially useful: volume, accepted cost, latency, and quality by `(task, route, model_version)`. Pin model versions during a comparison. If an alias changes under one arm of the test, you no longer know whether the router or the model caused the result. ## Batch discounts belong in the route Batching halves input and output token prices on both vendors for eligible asynchronous work, so urgency should be an explicit routing input. A nightly job and an interactive request should not share the same economic path. Good batch candidates include document backfills, catalog enrichment, offline evaluation, transcript labeling, and generated test cases. They already tolerate a queue and usually have enough volume to justify operational handling. Interactive support, IDE completions, and tool agents waiting on the next action do not. A common mistake is comparing an OpenAI synchronous request with a Claude batch request, then attributing the difference to model pricing. Label service class separately from provider and model. Your route should contain at least `interactive`, `deferred`, and `quality_first`, with a latency budget attached to each. Batching does not rescue wasteful prompts. It applies a discount to whatever tokens you send. Remove duplicated documents, bound output, and stabilize cacheable prefixes first. Also record failed and expired batch items. A nominal 50 percent discount becomes less attractive if the pipeline resubmits jobs or delays a business process beyond its deadline. Caching and batching can combine, but verify the exact billing fields for the model and endpoint you use. Anthropic's pricing documentation says prompt-cache multipliers stack with batch discounts. OpenAI lists batch rates by model and reports cached usage. Build a small invoice reconciliation before projecting the combined saving across millions of calls. The right test is operational: take one week of deferred production samples, submit them through each eligible model, and compare accepted cost after retries. Include queue delay and failure handling in the report. If nobody needs the answer now, paying synchronous rates is a choice, not a requirement. ## Route by task, confidence, and service class A practical router starts with the cheapest tested route for a task, escalates on observable uncertainty or failure, and keeps a small exploration budget. It should not ask the model to choose whichever provider it prefers. Define routing policy outside the prompt. The input signals can include task type, estimated context size, cache eligibility, required response format, latency class, data residency requirement, and risk level. Provider health and remaining rate limit also matter, but they should not silently lower the quality tier for sensitive work. I use three capability levels: 1. Economy handles classification, extraction, formatting, and simple retrieval answers after it passes a task-specific threshold. 2. General handles normal coding, grounded synthesis, and multi-step tool use. 3. Frontier handles difficult planning, ambiguous analysis, high-risk review, and escalation after a cheaper attempt fails. The word "after" matters. Do not always run the economy model and then the frontier model as a judge. That doubles calls and can cost more than starting at general. Escalate only when a deterministic check fails, the model returns calibrated uncertainty that correlates with errors, a tool loop exceeds a limit, or the task policy demands stronger review. Data rules can override cost. If one provider, region, or endpoint does not meet your retention and residency requirements, it is not a candidate. OpenAI's data-control documentation notes that extended prompt caching has storage implications and is not eligible for Zero Data Retention. Anthropic documents cache behavior within its own retention framework. Security review comes before the rate table. Keep an exploration slice, perhaps one or two percent of eligible traffic, for challengers. The exact share depends on risk and volume. Without exploration, the router keeps choosing the historical winner and never learns that a model update changed the frontier. Run challenger traffic only where you can evaluate it safely. The popular recommendation to standardize on one model for developer simplicity is often wrong at meaningful scale. It is popular because one SDK, one contract, and one failure mode reduce engineering work. The mistake is treating that convenience as free. Measure the annual cost and quality gap first; then compare it with the real maintenance cost of a second provider. Sometimes one provider still wins, but the decision should have numbers attached. ## A small router can stay explainable The router should return a policy reason with every decision, because unexplained routing is impossible to audit or tune. A rules-first implementation is enough until traffic and eval data justify a learned policy. This JavaScript example separates capability, service class, and provider selection. The prices are configuration, not logic: ```javascript const routes = { economy: ["openai:gpt-5.6-luna", "anthropic:claude-haiku-4-5"], general: ["openai:gpt-5.6-terra", "anthropic:claude-sonnet-4-6"], frontier: ["anthropic:claude-opus-4-8", "openai:gpt-5.6-sol"] }; function chooseRoute(job, telemetry) { if (job.dataPolicy.allowedProviders.length === 0) { throw new Error("No provider satisfies the data policy"); } const tier = job.risk === "high" || job.previousCheckFailed ? "frontier" : job.task === "classify" || job.task === "extract" ? "economy" : "general"; const service = job.deadlineMinutes >= 60 ? "batch" : "interactive"; const candidates = routes[tier] .filter(id => job.dataPolicy.allowedProviders.includes(id.split(":")[0])) .filter(id => telemetry[id].healthy) .filter(id => telemetry[id].evalPassRate >= job.minimumPassRate) .sort((a, b) => telemetry[a].acceptedCost - telemetry[b].acceptedCost); if (candidates.length === 0) throw new Error("No tested route is available"); return { model: candidates[0], service, reason: `${tier}:${service}:lowest_accepted_cost` }; } ``` `acceptedCost` must come from recent task-specific telemetry, not the vendor's input price. Refresh it on a schedule and require a minimum sample size. Use a fallback order that has passed the same evals, and cap retries so a provider incident cannot create an open-ended bill. The code deliberately refuses when no provider satisfies policy or quality. Quietly falling back from frontier to economy is dangerous. For low-risk jobs you may define a degraded mode, but name it in telemetry and product behavior so operators and users can see the compromise. Roll out a router in shadow mode first. It should make a decision and estimate cost while the existing path still serves the request. Compare its choice with actual usage and quality. Then move a small eligible slice to live routing, review regressions, and expand by task. A global switch hides which workload broke. Avoid a learned router until you can explain the labels it would learn from. If the training target is raw call cost, it will favor terse cheap failures. If the target is human acceptance without controlling for reviewer, it may learn one person's preferences. Rules tied to explicit eval gates are easier to operate and usually capture most of the available saving. ## Retries and tool loops erase paper savings The failure pattern I see most often starts with a clean spreadsheet and ends with a larger invoice. The spreadsheet assumes one request per task. Production sends three. A coding agent receives a large repository map and twelve tool definitions. The cheap model chooses a broad search, reads too many files, edits the wrong module, fails tests, and asks for another turn. The frontier model uses more expensive tokens per call but finds the relevant file earlier and passes on its first attempt. A call-price comparison declares the cheap model the winner; a run-price comparison shows the opposite. Set budgets around the run: - Maximum model calls and tool calls - Maximum input, output, and reasoning tokens - Maximum wall time and provider tool fees - An escalation rule and a terminal failure state Budget exhaustion should produce a structured result, not another apologetic model turn. The application can then escalate, queue human review, or stop. Record why the run ended. Tool definitions are also input. Large JSON schemas repeat on every turn unless caching captures a stable prefix. Remove tools the current task cannot use and shorten descriptions without making behavior ambiguous. Anthropic's pricing documentation explicitly says the `tools` parameter, tool-use blocks, tool-result blocks, and a provider-added tool system prompt contribute tokens. OpenAI tool calls likewise add model tokens, and some server tools carry separate fees. Retries need categories. Transport retries with no completed inference differ from schema repairs, safety refusals, rate-limit backoff, and quality retries. Only the provider can tell you whether a failed request incurred usage, so retain response IDs and usage payloads. Never assume every HTTP error costs zero or every retry costs a full call. Watch for cross-provider semantic drift. The same temperature, token limit, tool schema, and system prompt do not guarantee the same behavior. Translate your application contract, not just field names. Test stop conditions, parallel tool calls, JSON enforcement, reasoning controls, and truncation independently for each provider. The router needs a circuit breaker when latency, error rate, or accepted cost crosses a limit. It also needs recovery probes. Sending all traffic away from a provider during an incident is sensible; leaving it disabled forever because no production traffic tests recovery is not. ## One provider can still be the cheaper architecture A two-provider router is worthwhile only when its measured saving or resilience exceeds its engineering and operational cost. Small workloads often should choose one provider and revisit the decision later. A second provider adds SDK behavior, authentication, quotas, invoice reconciliation, observability fields, safety handling, prompt variants, model evals, incident playbooks, and contract review. Those are recurring costs. If annual inference spend is $12,000 and routing saves 15 percent, $1,800 will not fund much engineering. If spend is $1.2 million, the same percentage deserves attention. Use a simple decision calculation: ```text annual_router_value = baseline_accepted_cost minus routed_accepted_cost plus outage_loss_avoided minus router_build_and_operations_cost ``` Treat outage loss carefully; do not invent a heroic number to justify architecture. Use actual revenue exposure, support impact, or contractual penalties. If you cannot estimate it, show a range. One provider is also rational when a unique feature, data policy, committed-spend agreement, or team skill dominates. Keep the routing interface inside your application even then. A provider-neutral task contract and normalized usage ledger preserve the option to test a challenger without pretending the underlying APIs are identical. In my Team & AI Audit, this is the artifact I want to see: task-level volume, accepted cost, cache behavior, reviewer time, and an owner for every routing rule. A polished provider comparison without that ledger cannot support a payroll or architecture decision. Reprice the coefficients monthly and rerun evals when a model version changes. Do not rewrite policy merely because a vendor launches a cheaper model. Put the candidate through the same production samples, calculate cost per accepted run, and promote it only where it wins. The cheapest API call is easy to find. The cheapest reliable workflow has to be measured.