How to estimate the cost of an AI agent

An AI agent doesn't make one request — it makes dozens, and every step re-sends the growing conversation. That's why agent bills are dominated by input tokens, and why the "price per answer" intuition from chat apps doesn't work. Here is how to estimate the cost before the agent runs, and where the money actually goes.

The formula#

The cost of one request is input tokens times the input price plus output tokens times the output price. Prices are quoted per million tokens:

request_cost = input_tokens / 1,000,000 × input_price
             + output_tokens / 1,000,000 × output_price

The cost of a task is the sum over all requests the agent makes while solving it.

Why agents are input-heavy#

On every step the agent sends the model:

• the system prompt and the tool definitions;
• the whole history so far — earlier messages, the model's previous answers and tool results (file contents, command output, search results);
• the new instruction.

The model usually answers with a short message or a tool call. Then the tool result is appended to the history and the next step sends everything again. So the input of each step grows, while the output stays small.

A worked example#

Conditions (assumptions — replace them with numbers from your agent):

• system prompt and tool definitions: 6,000 tokens;
• each step adds 1,500 tokens of tool results and 500 tokens of model output to the history;
• the task takes 30 steps;
• model: DeepSeek-V4-Flash at $0.0221 per 1M input tokens and $0.10 per 1M output tokens (current prices).

The input of step n is 6,000 + (n − 1) × 2,000 tokens. Over 30 steps:

• total input: 30 × 6,000 + 2,000 × (0 + 1 + … + 29) = 180,000 + 870,000 = 1,050,000 tokens;
• total output: 30 × 500 = 15,000 tokens;
• cost: 1.05 × $0.0221 + 0.015 × $0.10 ≈ $0.0247 per task.

Input is 98.6% of the tokens and almost all of the cost. How much input dominates depends on the scenario: long answers, generated files and reasoning models raise the output share, while a trimmed history and short tool output lower the input share.

The same task on every model at current prices, with OpenRouter's reference prices for comparison:

Estimate it in code#

The same calculation as a function — change the assumptions and the prices:

def estimate(steps, base_tokens, tool_tokens, out_tokens, price_in, price_out):
    """Token totals and cost of one agent task. Prices: $ per 1M tokens."""
    grow = tool_tokens + out_tokens            # what each step adds to the history
    total_in = steps * base_tokens + grow * steps * (steps - 1) // 2
    total_out = steps * out_tokens
    cost = (total_in * price_in + total_out * price_out) / 1_000_000
    return total_in, total_out, round(cost, 5)

# example rates, $ per 1M tokens — put in the current ones from the pricing table below
print(estimate(30, 6_000, 1_500, 500, price_in=0.10, price_out=0.40))
# (1050000, 15000, 0.111)

Note the quadratic term: doubling the number of steps roughly quadruples the input. Long sessions get expensive not because of any single step, but because every step carries the entire history.

Measure instead of guessing#

Every response includes usage.prompt_tokens (input) and usage.completion_tokens (output). Log them for each step of a real task, multiply by the current rates, and you have the actual cost. The dashboard also shows usage by model and by day.

Current rates — the same data as on the pricing page:

Seven ways to cut the cost#

1. Start a new task for unrelated work. A fresh session doesn't carry the history of the previous one.
2. Give the agent fragments, not whole files. A function and its callers instead of a 3,000-line module.
3. Trim tool output. Long logs and command output stay in the history for the rest of the session — limit them, for example with | tail -n 50.
4. Summarize long sessions. Many agents can compact the history; use it before the context gets long.
5. Cap the answer length with max_tokens where long answers aren't needed.
6. Use the right model for the step. Routine steps don't need a reasoning model.
7. Keep a prepaid budget. The balance is prepaid: when it runs out, requests stop with HTTP 402 instead of running up an open-ended bill.

To see how the same workload compares across models and with OpenRouter, use the cost comparison on the home page.