o3 Deep Research Cost Per Query: What the Token Price Doesn’t Tell You

OpenAI’s o3 Deep Research API is listed at $10/$40 per million tokens—then developers run their first query and see $30 on a single call. The gap between list price and real o3 Deep Research cost per query comes down to one number OpenAI never emphasizes: Deep Research generates 2–5 million tokens internally per query through search iteration and extended reasoning chains, making traditional per-token estimates completely unreliable. According to Artificial Analysis, 10 test queries on o3 Deep Research cost $100 total—up to $30 per call—while the same 10 queries on o4-mini-deep-research cost just $9.18. This guide shows you how to calculate actual query-level costs before they hit your production logs.

How Much Does One Deep Research Query Actually Cost?

The published rate for o3 Deep Research is $10.00 per million input tokens and $40.00 per million output tokens, with cached input at $2.50 per million, according to our AI tools comparison coverage. Those numbers are accurate. They are also almost useless for budgeting.

The reason is volume. When you send a single research prompt, the model does not consume the tokens in your prompt and then produce a response. It executes a multi-stage pipeline: it generates search queries, retrieves and reads web content, reasons over intermediate findings, revises its approach, and synthesizes everything into a final output. Each stage generates tokens. Many stages loop. The token count compounds.

Artificial Analysis, an independent AI benchmarking organization, published hard numbers that make this concrete. Across 10 Deep Research test queries using o3-deep-research, the total cost was $100.00—an average of $10 per query, with peaks reaching approximately $30 per single API call. The same 10 queries on o4-mini-deep-research cost $9.18 in total, making o4-mini more than 10 times cheaper in that head-to-head test.

To understand what drives $30 out of a model with a $40/M output rate, consider the math. A single o3 Deep Research query generating 700,000 output tokens costs:

• Input component: assume 100,000 input tokens × $0.010 = $1.00
• Output component: 700,000 output tokens × $0.040 = $28.00
• Total: $29.00 for one query

That 700,000-token output figure is not a worst-case outlier. It falls squarely within the 2–5 million token range that Deep Research queries can generate internally. The model’s 200,000-token context window is a separate constraint from the total tokens it processes across multiple internal turns.

The pricing architecture also creates a 5x cost gap between o3-deep-research and the standard o3 model. According to Artificial Analysis, standard o3 is priced at $2/$8 per million tokens (input/output), while o3-deep-research runs at $10/$40. That is a 5x markup on the same underlying model, justified by the RL fine-tuning for research tasks and the integrated tooling. Whether that markup is worth it depends entirely on whether you need web-grounded research or can work with the model’s parametric knowledge alone.

Why Does Token Counting Fail for Reasoning Models?

Standard token estimation works by looking at your prompt length and multiplying by the expected output-to-input ratio. A 1,000-token prompt generating a 2,000-token response at GPT-4o rates costs roughly $0.035. That math is predictable because GPT-4o does not generate hidden intermediate tokens between your input and the visible output.

Reasoning models break this model entirely. The key distinction is between user-supplied tokens—your prompt—and model-generated thinking tokens—the internal reasoning chain, search queries, retrieved content processing, and synthesis steps the model executes before producing any visible output.

For o3 Deep Research specifically, this internal token generation includes at minimum:

1. Query decomposition: the model breaks your research question into sub-queries
2. Search execution: it generates and evaluates multiple web search queries
3. Content ingestion: retrieved web content gets tokenized and processed
4. Reasoning chains: extended chain-of-thought reasoning over gathered evidence
5. Synthesis: multi-pass drafting and revision of the final report

None of these steps are visible to you in the final response. You see the output. The API bills you for everything.

This is why prompt length is almost useless as a cost predictor for Deep Research. A 50-token research question (“Analyze the competitive dynamics of the cloud storage market in 2025”) can generate the exact same internal token volume as a 500-token version of the same question. The driver is task complexity, not input length. Broad, multi-faceted research questions force more search iterations. Contested topics with conflicting sources force more reasoning cycles. Queries requiring synthesis of many sources push output token counts into the high hundreds of thousands.

The practical implication: any cost estimate built by multiplying prompt tokens by a ratio is fiction for this model class. Developers who built cost-forecasting middleware for GPT-4o will find it gives them numbers that are off by an order of magnitude on Deep Research queries. The only reliable estimator is empirical—run representative queries in a staging environment, record actual token usage from the API response object, and build your cost model from observed data.

Should You Use o3 Deep Research or o4-mini Deep Research?

This is the decision most developers face after seeing their first bill. Here is the direct answer: for the majority of production research workloads, start with o4-mini-deep-research and only escalate to o3-deep-research when you have specific evidence that output quality is insufficient for your use case.

The cost differential is not marginal. According to Artificial Analysis testing, o4-mini-deep-research delivered over 10x total cost savings on identical queries. The per-token rate difference alone explains part of this: o4-mini-deep-research is priced at $2/$8 per million tokens versus o3-deep-research at $10/$40—a 5x rate advantage before accounting for token volume differences. In practice, Artificial Analysis also observed that o4-mini tends to use fewer tokens per query, compounding the savings beyond what the rate difference predicts.

Model	Input $/M	Output $/M	Cached Input $/M	10-Query Test Cost	vs Standard Model
o3-deep-research	$10.00	$40.00	$2.50	$100.00	5x premium over standard o3
o4-mini-deep-research	$2.00	$8.00	$0.50	$9.18	~1.8x premium over standard o4-mini
Standard o3	$2.00	$8.00	$0.50	N/A (no web research)	Baseline
Standard o4-mini	$1.10	$4.40	$0.275	N/A (no web research)	Baseline

Both Deep Research endpoints support OpenAI’s web search tool and remote MCP servers, so you are not trading away features by choosing o4-mini—you are trading reasoning depth on contested, multi-source synthesis tasks. If your queries are factual and well-sourced, that depth gap will not show up in your outputs; if they require adjudicating conflicting primary sources, it will.

Use o3-deep-research when:

• The research output feeds a high-stakes decision where errors cascade (legal analysis, financial due diligence, clinical literature review)
• Your queries require synthesizing conflicting primary sources where stronger reasoning materially improves accuracy
• You have run A/B quality tests on your actual query distribution and o4-mini output fails your quality threshold

Use o4-mini-deep-research when:

• You are building a product where research runs frequently and cost is a primary constraint
• Output quality is evaluated by human reviewers who can catch errors before they cause downstream problems
• You are in a prototyping or evaluation phase and have not yet established quality baselines

What Developers Are Actually Saying About Hidden Costs

The pricing surprise is not the only operational pain point. Community discussions across Hacker News and Reddit reveal a pattern that pricing guides never cover: Deep Research queries sometimes hang without completing, wasting tokens without delivering results.

One Hacker News thread on the Deep Research problem documented the experience of tasks that appear to be running but produce no output. From Reddit discussions about similar behavior in Deep Research implementations, users report queries that run for 30 minutes or more before failing or requiring manual intervention. In a pay-per-token model, a failed or hung query is not free—the model has already consumed tokens during its partial execution, and some of that cost appears on the bill regardless of whether a useful output was produced.

This creates a secondary cost problem beyond the per-query price: failed query cost. If a $20 query hangs and fails, you pay for the partial token consumption without receiving the output. At scale, a 10% failure rate on a pipeline running 50 Deep Research queries per day adds meaningful unexpected spend on top of the already high base cost.

A separate pain point that surfaces in developer discussions is the lack of real-time cost visibility. With standard completion models, developers can estimate cost before submitting by counting input tokens. With Deep Research, the final token count is unknown until the query completes—sometimes 10–20 minutes later. This makes it impossible to implement synchronous cost gates: you cannot check “will this cost more than $X?” before the query runs, only after.

The pattern is consistent enough to be a rule: every developer report that starts with “we got a $400 bill” ends with “we had no per-query logging.” The fix is not architectural—it is a 10-line logging wrapper that should exist before your first non-test API call, not after your first production incident.

Three Strategies to Control Deep Research Costs Before Production

Here are three concrete strategies, in order of implementation priority:

Strategy 1: Build async cost logging middleware before your first production query

The API response object contains token usage data. Log it on every call. This sounds obvious, but most teams add logging after they see an unexpected bill, not before. A minimal Python pattern:

import openai
import logging

client = openai.OpenAI()

def run_deep_research(prompt: str, model: str = "o4-mini-deep-research") -> dict:
    response = client.responses.create(
        model=model,
        input=prompt,
        tools=[{"type": "web_search_preview"}]
    )
    usage = response.usage
    input_cost = (usage.input_tokens / 1_000_000) * (10.0 if "o3" in model else 2.0)
    output_cost = (usage.output_tokens / 1_000_000) * (40.0 if "o3" in model else 8.0)
    total_cost = input_cost + output_cost
    logging.info(f"model={model} input_tokens={usage.input_tokens} "
                 f"output_tokens={usage.output_tokens} cost_usd={total_cost:.4f}")
    return {"output": response.output_text, "cost_usd": total_cost}

This gives you per-query cost data from day one. Run 20–30 representative queries in staging and build a cost distribution. The 95th percentile of that distribution is your realistic budget-per-query figure.

Strategy 2: Set hard per-query cost caps using the max_output_tokens parameter

OpenAI’s API supports a max_output_tokens parameter. Setting this caps the output token count, which directly caps your maximum possible output spend. For o3-deep-research, setting max_output_tokens=250000 limits output cost to a maximum of $10 per query (250,000 × $40/M). This is a blunt instrument—very long research tasks will be truncated—but it prevents runaway costs on unexpected query complexity. Combine it with a retry strategy that increases the limit if the first attempt is truncated.

Strategy 3: Use the web UI for non-critical research and reserve the API for automated pipelines

The ChatGPT Deep Research web interface charges against your subscription, not your API key. For exploratory research, analyst use cases, or any workflow where a human is already in the loop reviewing output, the web UI is the right tool. The API is justified when you need programmatic output, integration with downstream systems, or automated triggering. Mixing both keeps API spend focused on workflows where the programmatic access actually adds value.

1. Profile your query distribution in staging before production deployment
2. Set max_output_tokens as a cost circuit breaker on every API call
3. Log token usage and cost on every request from day one
4. Default to o4-mini-deep-research; promote to o3-deep-research only with evidence
5. Route non-automated research to the web UI to avoid API billing entirely
6. Build alerting on queries that exceed your 95th percentile cost threshold
7. Implement timeout handling for hung queries to limit partial-execution cost

What o3 Deep Research Cost Per Query Means for Your Stack

The $10/$40 per-million-token rate for o3 Deep Research is not a lie. It is just the wrong unit of measurement for this model class. When a single query generates 700,000 output tokens, the per-million rate is less useful than knowing your expected per-query cost—and the only way to know that is to measure it empirically before you build anything that depends on it.

The practical takeaway is this: treat o3-deep-research like a premium professional service billed by the engagement, not a commodity API billed by the character. You would not let a consultant run unlimited hours on an open-ended brief without a scope cap. Apply the same logic here with max_output_tokens and per-query cost logging.

For most teams, o4-mini-deep-research is the correct default. The Artificial Analysis test data—$9.18 versus $100 across 10 identical queries—is the most important number in this entire discussion, and most pricing guides that compare per-token rates across models never calculate it. That 10x cost difference deserves to be the starting assumption of your architecture decision, not a footnote you discover after your first production incident.

The teams that will overpay are those who multiplied $40/M by an assumed 10,000-token output, got $0.40, and shipped. The teams that will build sustainably are those who ran 20 staging queries, found their 95th-percentile cost was $22, and sized their per-user budget from that number instead.

---