Managed Agents sessions bill on two separate dimensions — the same per-token model rates as the Messages API, plus a session-runtime charge that most people miss until the invoice arrives. Here's exactly how it works, sourced from Anthropic's pricing docs.
| Dimension | Rate |
|---|---|
| Tokens (input/output/cache) | Same as standard model pricing — no markup for running inside a Managed Agents session. |
| Session runtime | $0.08 per session-hour |
Runtime is metered to the millisecond and only accrues while the session's status is running. Time spent idle (waiting on your next message or a tool confirmation), rescheduling, or terminated costs nothing. A session that sits idle overnight waiting for a human doesn't rack up runtime charges.
If you're used to pricing standard API calls, four modifiers you'd normally reach for silently don't apply inside a Managed Agents session:
| Modifier | Why it doesn't apply here |
|---|---|
| Batch API 50% discount | Sessions are stateful and interactive — there's no batch/async mode for a live agent. |
| Fast mode premium (Opus 4.8/4.7) | Inference speed is managed by the runtime itself, not a per-request flag. |
Data residency 1.1x (inference_geo) | inference_geo is a Messages API request field; Managed Agents sessions don't expose it. |
| Cloud platform (Bedrock/Vertex) pricing | Managed Agents isn't available on partner-operated cloud platforms. |
What does still apply: prompt caching multipliers (identical to the Messages API), and the $10-per-1,000-searches web search fee if a session triggers it. Session runtime replaces code-execution container-hour billing entirely — you're not charged separately for container time on top of it.
A one-hour coding session on Claude Opus 4.8 that consumes 50,000 input tokens and 15,000 output tokens, no caching:
| Line item | Calculation | Cost |
|---|---|---|
| Input tokens | 50,000 × $5 / 1M | $0.25 |
| Output tokens | 15,000 × $25 / 1M | $0.375 |
| Session runtime | 1.0 hour × $0.08 | $0.08 |
| Total | $0.705 |
Same session, but 40,000 of those input tokens are prompt-cache reads instead of fresh tokens:
| Line item | Calculation | Cost |
|---|---|---|
| Uncached input tokens | 10,000 × $5 / 1M | $0.05 |
| Cache read tokens | 40,000 × $5 × 0.1 / 1M | $0.02 |
| Output tokens | 15,000 × $25 / 1M | $0.375 |
| Session runtime | 1.0 hour × $0.08 | $0.08 |
| Total | $0.525 |
Caching cut the token cost by a third here — but notice the $0.08 runtime charge doesn't move at all. On a short, token-light session, runtime can end up being the biggest line item, not an afterthought.
Managed Agents draws from its own request-rate pool, not your Messages API RPM/ITPM/OTPM (see the full rate limits breakdown): creating a session is capped at 300 requests/min org-wide; reading, listing, or streaming an existing session is capped at 1,200 requests/min. Neither counts against your per-model Messages API limits.
A support-ticket-style workload (short, token-light, high volume) looks very different from a long-running coding session. Anthropic's own example: ~3,700 tokens per conversation on Haiku 4.5 across 10,000 tickets comes to roughly $37 in token cost — cheap enough that if sessions are also short-lived, the $0.08/hour runtime charge barely registers. It's long, idle-heavy, or slow-tool-call sessions where runtime cost catches people off guard, since a session waiting on a slow external tool call still accrues runtime while running.
Use the full calculator for the token side, or see tool use pricing for what web search/code execution/computer use add on top of plain tokens in any Claude workload, agent or not.