What an AI Agent Costs Per Conversation on AgentCore

Pratik Kulkarni
AI FinOps , AWS
28 Aug, 2026
07 Mins read

You can read AgentCore’s per-service rates straight off the AWS pricing page. What that page can’t tell you — and what you actually need before you build a business on agents — is what one of your units costs: one conversation, one resolved ticket, one document processed. And that number isn’t a constant. It’s set by what happens inside the unit, which is exactly what nobody quotes you. This post is about estimating that.

A “Conversation” Isn’t a Unit Until You Open It Up

“It costs X per conversation” is meaningless until you say what a conversation is. Two examples, both legitimately called one conversation, on a representative mid-tier model (~$3 per million input tokens, ~$15 per million output — the exact rate is a lever we’ll come back to):

A 2-turn FAQ. User asks, agent answers, user clarifies, agent confirms. A ~1.5K-token system-and-tools prefix, almost no history, short replies. Cumulative tokens are tiny. Cost ≈ 1.5¢.
A 12-turn troubleshooting chat that pulls in 8 documents. The agent retrieves ~20K tokens of documentation into context, then reasons over it across a dozen back-and-forth turns. Cost ≈ 90¢.

Same word, ~60× apart. If you priced your product off the first number and your users behave like the second, your margin is gone. So the useful question is never “what does a conversation cost” — it’s “what is my conversation made of.”

What Actually Drives the Number

Almost all of it is model tokens (the infrastructure lines are rounding errors — we’ll show that below). And token cost is driven by one mechanic most people miss:

Every model call re-sends the entire context up to that point — the system prompt, the tool definitions, the full conversation so far, and any documents or tool outputs already pulled in. A 12-turn conversation doesn’t send its context once; it sends a growing version of it twelve times.

That’s why cost scales with round-trips × context size, not just context size. The expensive unit isn’t “a long answer” — it’s “the model re-reading a big context many times.” In the heavy example above, the 20K of documents is cheap to retrieve once and brutal to re-send across twelve turns. The documents, not the conversation length, are the cost.

So the three drivers of any unit are:

Model round-trips — how many times the model runs (one per user turn, plus one per reasoning or tool step).
Context size per call — the stable prefix (system + tool definitions + injected documents) plus everything accumulated so far.
Output tokens — what the model generates each call.

One consequence is worth stating outright, because it catches people: a tool your agent never calls still costs you tokens. AWS is explicit that model input includes the definitions for all allowed tools, and that those definitions add input tokens even if the agent doesn’t invoke them. Every tool you attach is paid for on every model call, for the life of the unit. Trimming the tool list an agent is allowed to see is a cost lever, not just a prompt-hygiene one.

”Resolved Ticket” Tells the Same Story — on the Tool Side

Swap the unit and the lesson holds. “Resolved ticket” hides the same range:

A simple toggle. “Reset my password” → one model call to decide, one tool call to one service, one call to confirm. ≈ 2–4¢.
A diagnosis across a dozen services. “Why did my deployment fail?” → the agent queries logs, metrics, config, and the deploy API — eight model round-trips reasoning over tool outputs that get appended to context and re-sent each step. A single log dump can be 5K tokens. ≈ 50–70¢.

The non-obvious part: you’re not paying for the tool calls. Gateway invocations are fractions of a cent. You’re paying for the model re-reading every tool’s output on every subsequent step. Big tool outputs — logs, documents, query results — are token costs in disguise, because the moment they enter context they get re-sent for the rest of the unit.

Estimating Your Own Unit

You don’t need to have built the agent to estimate it. You need three numbers and one formula:

unit cost ≈ Σ(context tokens per call × input rate) + Σ(output tokens × output rate)

A quick shortcut covers most of it, because input dominates and the prefix is re-sent every call: round-trips × average context size × input rate.

Worked on the heavy conversation: ~12 round-trips, averaging ~23K tokens of context once the documents are loaded, at $3/M → 12 × 23K × $3/M ≈ $0.83 of input, plus ~6K output × $15/M ≈ $0.09. ~92¢, matching the headline. Do this with your expected turns, your document sizes, and your tool-output volumes, and you have a unit cost before you write a line of agent code.

The Levers That Actually Move It

They fall straight out of the drivers, in rough order of impact:

Model choice. This is the ~95% line. Run the frontier model only on the steps that need it and a mid-tier model on the rest, and the unit moves 3–4×.
Retrieve narrowly. Inject the two relevant passages, not ten whole documents. Every token you put in context gets re-read on every later call — retrieval precision is a cost decision, not just a quality one.
Cap round-trips. Each extra model step re-reads the whole growing context. Bounded loops and clean stop conditions keep the multiplier down.
Cache the stable prefix. Prompt caching charges the system + tools + documents prefix at full price once, then a fraction (often ~10%) on every re-read. For a multi-turn, context-heavy unit that can cut input cost by most of it — it directly attacks the re-send mechanic.
Set a memory retention policy. More on this next — it’s the one line that grows on its own.

From One Unit to a Monthly Bill

Multiply unit cost by volume and you have the run-rate. At 10,000 heavy conversations a month, the ~92¢ unit is ~$9,200 — and ~95% of that is model tokens, which is why the levers above are the whole game. Two things to layer on top:

Long-term memory storage accrues monthly, and it compounds. It’s cheap per record ($0.75 / 1,000 records / month built-in, $0.25 self-managed) but it’s the only line that climbs in a flat-traffic month — persist a few facts per user forever and it never stops growing. Set expiry; don’t store what you won’t retrieve.
Tag every operation with a tenant and feature ID. It’s the only way to read unit cost per customer, catch a noisy tenant burning your margin, and enforce budgets. Unit economics you can’t attribute aren’t unit economics.

A Note on Compute (and the Fargate Comparison)

You’ll see AgentCore-versus-Fargate compute comparisons: AgentCore Runtime microVMs bill CPU only while the agent is actively working, so the 30–70% of wall-clock time spent waiting on the model is free, while Fargate bills the provisioned task for its whole lifetime. It’s a real structural advantage — and it decides the Runtime line, which is under 1% of every unit above. Don’t choose your agent platform on a rounding error. The Runtime example: a 60-second session using 1 vCPU for 20 active seconds and 2GB throughout costs ~$0.0008 in compute — next to a ~90¢ model bill, it’s noise. (The platform trade-off that does matter is in AgentCore vs Bedrock Agents.)

Two qualifications, because the “you pay nothing while waiting” line gets repeated too loosely:

Only CPU is free during I/O wait. Memory is not. You’re billed for peak memory consumed up to each second, for the whole session — boot, initialization, active processing, idle, and shutdown. There’s a 128MB minimum, a 1-second minimum, and billing includes system overhead.
Runtime now has a second compute type. Alongside microVMs, Instances run your agents on AWS-managed EC2 in your own account, billed at the EC2 rate plus an AgentCore management fee calculated as a percentage of the EC2 On-Demand price. Sessions persist up to 14 days and you can co-locate multiple agents on one instance. The FinOps detail that matters: your Savings Plans, Reserved Instances and Capacity Reservations apply to the EC2 compute — but not to the management fee. EBS for persistent volumes bills at standard rates, including while a session is stopped. If you pick Instances, the active-consumption argument above no longer applies to you.

The Rates, for Reference

The per-service numbers, so you can plug your own volumes in. The AgentCore harness itself is free; you pay only for what each service consumes, billed per second, with no minimums. New AWS accounts also get up to $200 in Free Tier credits.

Service	Billing basis	Price
Runtime microVMs (also Browser, Code Interpreter)	Active consumption	$0.0895 per vCPU-hour + $0.00945 per GB-hour
Runtime instances	EC2 instance-based	EC2 On-Demand rate + an AgentCore management fee (a percentage of that rate)
Web Search	Per query	$7.00 per 1,000 queries
Gateway	Per invocation	$0.005 / 1,000 API calls; $0.025 / 1,000 searches; $0.02 / 100 tools indexed/mo; $0.006/GB egress to your own VPCs
Identity	Per request	$0.010 / 1,000 token or API-key requests (free via Runtime or Gateway)
Memory	Consumption	$0.25 / 1,000 short-term events; long-term $0.75 (built-in) or $0.25 (override or self-managed) / 1,000 records/mo stored, billed hourly on a 31-day month; $0.50 / 1,000 retrievals
Observability	CloudWatch usage	Standard Amazon CloudWatch pricing
Evaluations	Consumption	Built-in (13 evaluators): $0.0024 / 1,000 input + $0.012 / 1,000 output tokens, model usage included. Custom: $1.50 / 1,000 evals, model billed separately. Batch: $0.0018 / 1,000 input + $0.009 / 1,000 output
Policy	Per request	$0.000025 / authorization request (first 100 temporal policies per engine free) + $0.13 / 1,000 input tokens for natural-language authoring
Optimization	Consumption	Insights free in preview; Recommendations free; Experiments billed on the services they consume. Batch evaluations get a 25% discount
AWS Agent Registry	Consumption	Free monthly tier of 5,000 records, 1M Search calls, 2M List+Get calls; then $0.400 / 1,000 records, $0.020 / 1,000 searches, $0.004 / 1,000 List+Get
Payments	Per wallet operation	Charged at your wallet provider’s rate — Coinbase CDP or Stripe Privy. Other API calls free

Model inference is billed separately by the model provider and is not in this table — which is the whole point: it’s the line that decides your unit economics, and it’s the one AgentCore doesn’t set.

One line here is not a rounding error. Web Search at $7 per 1,000 queries is roughly 0.7¢ per search. On the 90¢ conversation that’s still noise, but on a cheap 2¢ unit an agent that runs five searches has just tripled its cost. If your agent searches the web, meter it separately rather than assuming it disappears into the model bill like the rest of the infrastructure does.

Key Takeaways

The per-service rates are public; your unit cost isn’t — it’s set by what happens inside one conversation or ticket, and the same unit can vary 50–80×.
Token cost dominates (~95%), and it scales with model round-trips × context size, because every call re-sends the whole growing context.
Define your unit’s anatomy before you price it: count round-trips, average context size, and output, then round-trips × context × input rate gets you close.
Levers, in order: model choice, narrow retrieval, fewer round-trips, prompt-cache the stable prefix, expire long-term memory. Trimming the tool list counts too — allowed tool definitions are re-sent on every call whether or not the agent uses them.
Long-term memory storage is the only line that accrues monthly regardless of traffic. Tag by tenant so you can attribute unit cost per customer.
Two infrastructure exceptions to “it’s all model tokens”: Web Search at $7/1,000 queries, and Runtime instances, which bill like EC2 rather than by active consumption.