My AI Agent Costs 0.7¢ per Task — the Token-by-Token Breakdown (DeepSeek V4 Flash vs GPT-4o)

Last month I shipped a support-triage agent. It reads an incoming ticket, searches our docs, drafts a reply, and — if it can't find an answer — escalates to a human with a summary of what it tried. Six LLM round-trips per ticket, nothing exotic.

The surprise came when I added token logging and actually looked at the bill. I'd assumed the cost story was about model prices: DeepSeek V4 Flash at $0.35 per 1M input tokens vs GPT-4o at $10. That's a ~28x sticker gap, and it's real. But the thing that actually decides your agent bill is something else entirely: how many times the loop re-sends the same tokens. Nobody models that before they ship, and it compounds fast.

Why agent loops multiply tokens

A chat-completions API is stateless: every step of an agent loop sends the entire conversation so far back to the model. My triage agent does roughly six steps per ticket:

1. Classify the ticket
2. Pull relevant docs (search + rerank)
3. Draft a reply
4. Check the draft against our guidelines
5. Escalate or send

Step 1 ships ~2K tokens. Step 5 ships those same ~2K tokens plus everything the agent produced in between — the classification, the docs, the drafts, the tool-call JSON. Each step is billed at full input price. The token count grows almost linearly with the number of steps, and the growth is pure overhead: the model re-reads what it already wrote.

This is the hidden cost of agents. It's not the price per token. It's that you pay for the same tokens over and over.

The actual numbers

First, the prices I'm comparing (per 1M tokens, as of this writing):

Model	Input $/1M	Output $/1M
DeepSeek V4 Flash	$0.35	$1.10
Qwen3-235B-A22B	$1.60	$6.40
GLM-5-130B	$1.20	$4.80
GPT-4o	$10.00	$30.00

Over a real week of production traffic, the average ticket looked like this: ~2K input + ~300 output tokens per step, six steps, plus a ~500-token final reply. That's ~12.2K input and ~2.3K output tokens per ticket.

Here's the script I wish I'd written before I shipped:

STEPS = 6
IN_PER_STEP = 2_000
OUT_PER_STEP = 300
FINAL_OUT = 500

def agent_cost(p_in, p_out):
    total_in = 200 + STEPS * IN_PER_STEP   # original ticket + re-sent history
    total_out = STEPS * OUT_PER_STEP + FINAL_OUT
    return (total_in * p_in + total_out * p_out) / 1_000_000

for name, p_in, p_out in [
    ("DeepSeek V4 Flash", 0.35, 1.10),
    ("Qwen3-235B-A22B",   1.60, 6.40),
    ("GLM-5-130B",        1.20, 4.80),
    ("GPT-4o",           10.00, 30.00),
]:
    print(f"{name:18} ${agent_cost(p_in, p_out):.4f} per ticket")

DeepSeek V4 Flash   $0.0068 per ticket
Qwen3-235B-A22B     $0.0342 per ticket
GLM-5-130B          $0.0257 per ticket
GPT-4o              $0.1910 per ticket

Per ticket it all looks like noise — fractions of a cent. Scale it to 1,000 tickets a day and the shape of the problem changes:

Model	Cost / ticket	1,000 tickets/day	~per month
DeepSeek V4 Flash	$0.0068	$6.80	~$204
Qwen3-235B-A22B	$0.0342	$34.20	~$1,026
GLM-5-130B	$0.0257	$25.70	~$771
GPT-4o	$0.1910	$191.00	~$5,730

(30-day month, no weekends trimmed. Your mileage will vary with step count — that's the point.)

How I actually track this in production

The math above is useless if you don't measure it. Every wrapper in my codebase logs per-step usage against a price table, so a "cost per ticket" number shows up on the dashboard instead of on the invoice:

PRICES = {
    "deepseek-v4-flash": (0.35, 1.10),
    "qwen3-235b-a22b":   (1.60, 6.40),
    "glm-5-130b":        (1.20, 4.80),
    "gpt-4o":            (10.00, 30.00),
}

def log_step(ledger, model, usage):
    p_in, p_out = PRICES[model]
    cost = (usage.prompt_tokens * p_in + usage.completion_tokens * p_out) / 1_000_000
    ledger.append(cost)
    return sum(ledger)   # running cost for this ticket

The first time I ran it, the ledger told me something the price list didn't: step 4 (the guideline check) was nearly free on DeepSeek V4 Flash but still cost real money on GPT-4o — and it was pure redundancy. I cut it, and the token count dropped by a sixth with zero quality change. Measure first, optimize second.

The honest part: where GPT-4o still wins

I don't want to oversell. I ran the same agent on GPT-4o for a week, and it earned its premium in ways the price table doesn't capture:

• Tool-calling reliability. GPT-4o produced well-formed tool calls on the first try more often than DeepSeek V4 Flash. Each malformed call on the cheap model costs a retry — and a retry re-sends the whole history. On messy JSON workloads that ate a chunk of the price gap.
• Complex reasoning. For the escalated tickets that actually needed multi-step deduction, GPT-4o's answers were noticeably more robust. I'd still use it for the hard 10% — just not for the easy 90%.
• Throughput. GPT-4o streams ~55 tok/s vs ~48 tok/s for DeepSeek V4 Flash. For a user-facing chat that's a small but real difference; for a batch job it doesn't matter at all.

The honest conclusion: for high-volume, structured work, the cheap models win on cost by an order of magnitude and their failure modes are fixable with code (validation, retries, schema checks). For open-ended reasoning where a bad answer is expensive, GPT-4o is still the safer default. The right answer is usually both, on different paths.

Three things that made the bill smaller

1. Trim the history. Tool results from four steps ago rarely matter. I keep a rolling window of the last two turns plus a summary of the rest. Token count per ticket dropped ~40%.
2. Route by difficulty. Classify first with the cheap model, and only escalate to the expensive one when it's out of its depth. A classifier that costs fractions of a cent saves a lot of $0.19 calls.
3. Cache the stable prefix. System prompt + guidelines + doc headers never change. All three Chinese providers discount cache hits by 80% on input tokens (DeepSeek V4 Flash: $0.35 → $0.07 per 1M), so I keep every dynamic bit — dates, ticket numbers, request IDs — at the end of the prompt. One-word edits to the stable block silently destroy the cache, so I stopped editing it casually.

Try the math on your own agent

The annoying part of all this was never the code — it's that DeepSeek, Qwen, and GLM each have separate consoles, separate billing, separate rate limits, so a "measure across models" workflow meant juggling four dashboards. I route everything through tokencnn.com: a single OpenAI-compatible endpoint where deepseek-v4-flash, qwen3-235b-a22b, and glm-5-130b all sit behind one API key, and switching models for an A/B cost run is a one-line change ("model": "qwen3-235b-a22b"). Sign up with just an email — no China phone number, no WeChat — and the $1 free credit is enough to run this exact ledger on your own traffic:

curl https://api.tokencnn.com/v1/chat/completions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "system", "content": "You are a support triage agent."},
      {"role": "user", "content": "Classify this ticket: ..."}
    ]
  }'

Bottom line

Per-ticket costs are a trap: they're all tiny, so nobody does the math — and then the invoice arrives. Agent loops multiply tokens by re-sending history at every step, which turns a 28x model-price gap into a 28x bill gap almost mechanically. Log the tokens, trim the history, route by difficulty, and let the ledger — not the sticker price — decide which model runs which step.

Have you ever shipped an agent and found the real cost driver was somewhere you didn't model? I'd genuinely like to hear what the token ledger taught you.