GPT-4o costs $2.5 per 1M input tokens and $10 per 1M output tokens. If you want the real bill, don’t guess from prompts, count tokens and do the math.
Why this number matters more than the model name
Developers tend to talk about models like they’re fixed-price tools, but usage is what actually bills. GPT-4o is a good example because its cost depends on the mix of input and output tokens, plus whatever your app does with retries, tool calls, and long context. If you only know the model name, you still don’t know the cost.
That’s why the useful unit is always per 1,000,000 tokens. It lets you normalize across providers, compare models cleanly, and estimate spend before you ship. If you want the broader market view, the AI Cost Index gives you a blended benchmark instead of a single-model snapshot.
For GPT-4o specifically, the pricing split is straightforward:
- Input: $2.5 per 1M tokens
- Output: $10 per 1M tokens
That 4x gap matters. A chatty app, a code generator, or a tool-using agent can rack up output tokens fast, and output is the expensive side here.
Worked example: what a real GPT-4o request costs
Let’s do the math with a realistic request: 12,000 input tokens and 3,000 output tokens.
Use the standard formula:
cost = (input_tokens / 1,000,000) × input_price + (output_tokens / 1,000,000) × output_price
Now plug in the numbers:
- Input cost = (12,000 / 1,000,000) × $2.5 = $0.03
- Output cost = (3,000 / 1,000,000) × $10 = $0.03
Total cost = $0.06.
That looks tiny until you scale it. If your agent does that 500 times in a month, you’re at $30. If each run is longer, or if your output side doubles because the model is writing code, summarizing logs, or revising itself, the bill climbs quickly.
Here’s the same idea with a higher-output workload. Suppose you send 8,000 input tokens and get 8,000 output tokens back:
- Input cost = (8,000 / 1,000,000) × $2.5 = $0.02
- Output cost = (8,000 / 1,000,000) × $10 = $0.08
Total cost = $0.10.
Same request size, different mix, very different bill. That’s the part people miss when they only look at prompt length.
GPT-4o compared with nearby options
If you’re choosing between models, the question is not just “which is best,” it’s “which is best for the token pattern I actually have.” Here’s a small comparison using only the current figures we can verify:
| Model | Input price per 1M | Output price per 1M | Notes |
|---|---|---|---|
| gpt-4o | $2.5 | $10 | General-purpose, expensive output side |
| gpt-4o-mini | $0.15 | $0.6 | Much cheaper for high-volume workloads |
| claude-sonnet-4-5 | $3 | $15 | Higher output cost than GPT-4o |
| gemini-2.5-flash | $0.3 | $2.5 | Cheaper on both sides for many tasks |
That table doesn’t say one model is universally better. It says price structure matters. A model with cheap input but pricey output can still be a bad fit for agentic workflows, while a cheaper output model can be surprisingly strong for long-form generation and iterative coding.
If you want a live catalog instead of a static snapshot, check live prices for 4,220 models. It’s the fastest way to sanity-check whether a model is actually cheap for your workload, not just cheap on paper.
What usually drives GPT-4o bills up
Most surprises come from the same few patterns:
- Long context, especially when you keep appending chat history instead of summarizing it.
- Verbose output, which is common in code generation, debugging, and agent loops.
- Retries and tool calls, where one user action turns into several model calls.
- Repeated system prompts, which quietly eat input tokens every time you send a request.
There’s also a hidden multiplier: success rate. A cheap request that fails twice can cost more than a pricier model that gets it right once. That’s why a raw token bill is only half the story. The better metric is cost per successful task, not just cost per call.
For a broader lens on how developers spend across models and tools, the State of AI page is useful context. It shows where the ecosystem is moving, not just what one model costs today.
How to track this without guessing
If you’re using coding agents, the easiest way to see actual spend is to inspect the logs they already keep locally. Run npx mytokentracker and it reads those local usage logs, then prints a 30-day cost table at API prices. Your usage data stays on your machine.
If you want a synced dashboard, create a free account and run npx mytokentracker init. It asks for the API token, uploads history, and then syncs every 30 minutes. It works with Claude Code, Codex, GitHub Copilot CLI, Antigravity, OpenCode, Amp, Qwen Code and more.
MyTokenTracker also captures cost, input/output/cache/reasoning tokens, latency, and success, broken down by provider, model, platform, and use-case. If you build on OpenAI, Anthropic, Gemini, or Mistral, the drop-in wrappers auto-capture usage, and any other provider can be supported with a single POST to the events API.
That matters because GPT-4o cost is not just a price card. It’s a live stream of token events. If you can see daily totals per agent and model, you can spot the expensive loop before it becomes a monthly surprise.
FAQ
Is GPT-4o cheap enough for production apps?
Sometimes, yes, but only if your token pattern fits. GPT-4o’s output side is $10 per 1M tokens, so apps that generate a lot of text or run multi-step agent loops can get expensive faster than expected. For short, bounded tasks, it can be perfectly reasonable.
Why does the output side matter so much?
Because output tokens are often the bigger share of an interactive workload. If the model writes code, explains itself, or retries tool calls, output can dominate the bill even when prompts are modest. That’s why a model with a cheap input rate can still be costly in practice.
How do I know whether GPT-4o or a cheaper model is better for my app?
Measure your own mix of input, output, cache, and success rate. Then compare against live prices, not vibes. A model like gpt-4o-mini may be enough for many tasks, while GPT-4o makes sense when quality or tool reliability matters more than raw token cost.
If you want to see your own numbers instead of estimating them, start with MyTokenTracker.