Managed AI Agents Pricing: Session Fees vs Token Costs Explained
Claude, Gemini and AWS now bill managed agents by session hours on top of tokens. Here's how that cost model works and what it means for your bill.
What is the pricing model for managed AI agents?
Managed agent platforms charge for two separate things: the tokens the underlying model consumes, and the time the session itself stays alive. Anthropic’s Claude managed agents already bill a session hour fee on top of token usage. Google’s Gemini agents aren’t charging for session time yet during preview, but the pattern is the same one Anthropic set: you pay for duration, not just for what the model generates. That’s a meaningful shift from the chat-completion pricing most developers are used to, where a single API call and its token count is the whole bill.
TL;DR
- Session-hour billing is now stacked on top of token costs, meaning a long-running agent accrues charges for the wall-clock time it stays active, not just the tokens it processes.
- Token burn per interaction is large and mostly invisible to you: Google’s own documentation notes a single antigravity agent interaction can use somewhere between 100,000 and 3 million tokens because one request triggers multiple internal reasoning and tool loops.
- Six major vendors shipped a managed agent product in under five months, starting with Anthropic around April, followed by Google (antigravity, then Gemini agents) in May, AWS Agent Core in June, Microsoft Foundry hosted agents also in June, and LangChain’s deep agents public beta in August.
- Model vendors and cloud vendors are placing opposite bets: Anthropic and Google want to lock you into their own models through the agent product, while AWS, Azure, and Google Cloud are building runtimes that keep the model swappable but lock you into their infrastructure instead.
- Long-running agents are structurally the highest-revenue product a model company can sell, because the loop runs unattended, racks up server-side reasoning and tool calls you don’t directly control, and bills you for all of it.
- Zero data retention and self-hosting requirements can rule out managed agents entirely, since session history and sandbox state typically live on the provider’s servers by design.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Why did token billing turn into session-hour billing?
A plain chat API call is a single round trip: you send a prompt, the model replies, done. Pricing that model is simple because the token count is bounded by one exchange.
A managed agent is different. It runs a loop that can call the model, call tools, check results, call the model again, and keep going until the task is finished or it hits a limit. All of that happens server-side, inside the provider’s infrastructure, often while you’re not watching. Google’s documentation puts a number on this: a single antigravity agent interaction can burn between 100,000 and 3 million tokens, because one interaction can trigger multiple reasoning and tool loops that you don’t have direct control over.
That variability is exactly why vendors added a second billing dimension. Token counts alone don’t capture the cost of keeping a sandbox alive, holding state, managing memory, and running scheduling infrastructure for a session that might last minutes or might run for hours. A session-hour fee lets the provider charge for the infrastructure the agent occupies, independent of how many tokens it happens to consume in that window.
How does a managed agent actually work under the hood?
It helps to think of a managed agent as three layers. The bottom layer is the model itself, whether that’s Claude, Gemini, or one of the GPT models running on AWS or Azure. The middle layer is the harness: the loop that calls the model, picks tools, runs them, feeds results back into context, and manages the context window. The top layer is the runtime: where that loop actually executes, the sandbox holding credentials, the observability and tracing, the process that survives and keeps running in the cloud on its own.
“Managed” means the provider owns the harness and the runtime, not just the model. Anthropic’s version of this, which set the template most others have followed, breaks into four concepts: the agent (model, system prompt, tools, MCP connections, and skills, created once and referenced by ID), the environment (the cloud sandbox it runs in, which can be the provider’s own or self-hosted), the session (one running instance handling one task), and events (the messages, tool results, and status updates that flow through that session).
Gemini’s managed agents follow a similar structure, giving each agent a fresh Linux sandbox as its remote environment, with the ability to mount a custom file system, your own skills, or an agents configuration file.
There are also two distinct flavors of managed agent product. In the first, the provider supplies the entire loop: you send a task and a configuration, and you never write the loop or call the model directly. Claude managed agents, Gemini agents, and LangChain’s managed deep agents fall here. In the second, you bring your own loop, built with a framework or from scratch, and the provider just hosts it, handling session isolation, tool execution, and memory server-side. AWS’s Agent Core and similar cloud offerings fit this pattern.
One coffee. One working app.
You bring the idea. Remy manages the project.
Why are model vendors and cloud vendors making opposite bets?
For a company that owns its own model, a managed agent product is a lock-in mechanism. If you want to use Claude’s managed agents, you need to use a Claude model. If you want Gemini’s managed agents, you need a Gemini model. The harness and runtime are built specifically around that model family, so adopting the agent product means committing to the model vendor’s whole stack.
Cloud providers without a dominant proprietary model are making the reverse bet. AWS, Azure, and Google Cloud’s agent runtimes are designed to keep the model interchangeable while making the infrastructure the sticky part. You can plug in different models, but you’re running on their serving architecture and likely their memory system, so the lock-in shifts from the model to the operational layer.
LangChain sits in a third position entirely. It’s neither a model company nor a cloud provider, so its deep agents product is framework-first: any model, any sandbox, and it can even be self-hosted. Its lock-in strategy is operational rather than technical. Once your traces, evaluations, and deployments live in LangChain’s tooling, migrating away from that workflow becomes the real switching cost, not the model or the infrastructure underneath it.
Is a managed agent worth paying for?
It depends on what your agent actually needs to do. Managed agents make sense when you need state that survives a disconnect and can resume a task days later, or when you need a server-side sandbox for code execution that has to persist independent of your own infrastructure. In both cases, building and maintaining that yourself is a real engineering cost, and a managed offering removes it.
They make less sense if the agent loop itself is your product, or if you’re building something custom enough that you need full control over how the harness behaves. In that case, you’re often better off self-hosting the loop and selectively using pieces of a managed platform, like a hosted sandbox, a memory tool, or an observability layer, rather than adopting the whole package.
Data governance is the other deciding factor. If your organization requires zero data retention, or your data legally cannot leave your own infrastructure, most current managed agent offerings are disqualified outright. Session history and sandbox state generally live on the provider’s servers as a core part of how the product works, which is incompatible with strict data residency or retention requirements common in regulated industries.
Frequently Asked Questions
What’s the difference between token billing and session-hour billing for AI agents?
Token billing charges you based on how much text the model processes and generates. Session-hour billing charges you for how long an agent session stays active in the provider’s infrastructure, regardless of token count. Managed agent platforms increasingly charge both, since a long-running session consumes server-side resources beyond just model inference.
Why do managed agents use so many tokens per task?
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
A managed agent doesn’t make one call to the model, it runs a loop that can trigger multiple rounds of reasoning and tool use before returning a result. Google’s documentation notes this can range from roughly 100,000 to 3 million tokens for a single antigravity agent interaction, since each interaction may involve several internal reasoning and tool cycles you don’t directly control.
Does using a managed agent lock me into one AI model?
It depends on the vendor. Model companies like Anthropic and Google build their managed agent products around their own models, so using Claude’s or Gemini’s managed agents generally means using their respective models. Cloud infrastructure providers like AWS and Azure design their agent runtimes to support multiple models, trading model lock-in for infrastructure lock-in instead.
Can I self-host a managed agent instead of using a provider’s platform?
Yes, if the harness is open. LangChain’s deep agents framework, for example, can run with any model and any sandbox, including self-hosted infrastructure. Closed harnesses like Claude’s managed agents or AWS Agent Core are designed to run primarily within the provider’s own environment.
When should I avoid managed agents entirely?
Avoid them if your organization requires zero data retention or your data cannot leave your own infrastructure, since session history and sandbox state in most managed offerings live on the provider’s servers. You should also consider self-hosting if the agent’s loop and behavior are central to your product and you need full control over how it operates.
