The Hidden Cost (and Savings) of AI Agent Skills
The same agent capability can cost ~10,000 tokens as an MCP server or ~100 as a skill. What that gap costs at scale - and why it's a governance signal.
Most conversations about agent skills are about risk. This one is about the invoice. The same capability, delivered as a skill instead of an MCP server, can sit in an agent’s context at roughly one percent of the token cost - and at scale, that difference stops being a rounding error and starts being a line item.
It’s worth being precise about where the saving comes from, because it isn’t magic and it isn’t free. Understanding it tells you something useful about how to run agents economically - and, as it turns out, something useful about how to govern them too.
The same task, two footprints
Take a concrete example: browser automation with Playwright, a widely used library for driving a web browser programmatically. It exists both as an MCP server and as a skill, doing the same underlying job. The difference in what they cost an agent at rest is stark.
As an MCP server, Playwright runs as a standing process. It exposes a fixed set of tools - navigate, click, screenshot, and so on - and to make those available, their schemas sit resident in the agent’s context for the whole session. It keeps a browser session alive across calls and returns an accessibility-tree snapshot after each one. Before the agent has done anything, that’s roughly 10,000 tokens of standing context.
As a skill, Playwright doesn’t expose fixed tools at all. It teaches the agent how to write and run Playwright code itself, using whatever code-execution the host already has. At rest, it costs about 100 tokens - its name and description - and only loads the full API reference when a task actually calls for it.
Same capability. Roughly a hundred-fold difference in standing footprint. The obvious question for anyone who owns an agent budget is: what does that actually cost?
Why a rounding error becomes a line item
Per call, it costs almost nothing. Ninety-nine hundred tokens at a typical input rate is a fraction of a cent. If that were the whole story, no one would care.
The reason it matters is that standing context isn’t paid once. It’s re-sent on every turn of every session, because the model needs the full context each time it reasons. Multiply a fraction of a cent by every turn, by every session, by every agent carrying that footprint, across a month - and the arithmetic changes character.
The figures above are illustrative rather than a benchmark - they take one documented ~9,900-token difference and scale it across a plausible workload to show order of magnitude. Your real number will depend on session length, model, how aggressively you cache, and how many of your agents carry the heavier footprint. But the shape holds: a per-call rounding error becomes a monthly line item once it’s standing context multiplied by scale.
The honest caveat matters here, because it’s the kind of thing a finance partner will ask about immediately. Prompt caching narrows the gap substantially - cached input is billed at roughly a tenth of the standard rate, which pulls our illustrative figure down by an order of magnitude. It narrows the gap; it doesn’t close it. Cached or not, the heavier footprint still costs more on every turn, and caching is a mitigation you have to actively design for rather than something you get by default.
The part that ties back to governance
Here’s the connection that makes this more than a cost-optimization tip. A leaner agent is not only a cheaper agent - it’s a more legible one.
An agent carrying ten thousand tokens of standing tool schemas is an agent with a large, permanent surface of capability sitting resident in its context whether or not the current task needs it. An agent that loads a hundred tokens at rest and pulls in the rest on demand is one whose active capability at any given moment is smaller, more specific to the task in hand, and easier to reason about. The thing that lowers the token bill - capability that’s present only when it’s actually needed - is the same thing that makes the agent’s behavior easier to audit.
This is why cost and governance aren’t separate conversations about agents; they’re two readings of the same underlying property. How much an agent is carrying at rest shows up on your invoice and in your risk posture at the same time. Teams that get visibility into their agents’ standing footprint tend to find both a cost story and a control story sitting in the same data.
The property that lowers the token bill - capability present only when it’s needed - is the same property that makes an agent easier to audit.
What to take from this
- Audit standing footprint, not just usage. Look at what your agents carry in context at rest, before any task runs - that’s where the recurring, invisible cost lives, and it’s the number most usage dashboards don’t surface.
- Ask where a skill can replace a standing server. For capabilities an agent uses occasionally rather than constantly, an on-demand skill can deliver the same outcome without the resident context cost. Not every case fits, but the expensive ones are worth checking.
- Design for caching deliberately. It’s the single biggest lever on standing-context cost, but only if your session and prompt structure are built to benefit from it - it isn’t automatic.
- Read cost and control together. A lighter agent is cheaper and more auditable for the same reason. The team that owns the budget and the team that owns the risk are often looking at the same footprint from two directions.
Token footprint is one thread in a much bigger picture. Our whitepaper, A Guide to Agent Skills, sets out the full model: how skills reshape agentic cost, where their risk actually lands in the agent lifecycle, and six practices for bringing them into your governance and security posture.
