stripe/ai: Metering LLM Tokens Into Stripe Billing, Plus an MCP Server and Agent Plugins

Two SDKs, Two Different Assumptions About Your Stack

The repository's core offering is a pair of TypeScript packages that both answer the same question: how does LLM usage become a billable event in Stripe? They differ in where they sit in your code. The README describes @stripe/ai-sdk as being for integrating Stripe's billing infrastructure with Vercel's ai and @ai-sdk libraries. That places it inside the framework's abstraction, so if your application already streams completions through the Vercel AI SDK, the Stripe integration is meant to attach at that layer. The second package, @stripe/token-meter, is described as integrating Stripe's billing infrastructure with the native SDKs from OpenAI, Anthropic and Google Gemini, without any framework dependencies. That is the more interesting of the two for teams who never adopted an orchestration framework, or who adopted one and later removed it. The split also tells you something about the intended audience. This is not a product for someone experimenting with a chatbot. It is for teams who already have a Stripe account, already have a metered or usage-based billing model, and now need model consumption to appear as a line item rather than as a flat subscription. The repository is written in TypeScript, and the two packages are scoped under @stripe, which means installation goes through npm rather than through a vendored copy.

The MCP Server Is Hosted, Not Something You Deploy

Alongside the SDKs, the README states that Stripe hosts a remote Model Context Protocol server at https://mcp.stripe.com, and that it allows secure MCP client access via OAuth. The documentation link given is docs.stripe.com/mcp#connect. This is a meaningful architectural decision and worth reading carefully, because it inverts the usual MCP pattern. Most MCP servers in circulation are processes you run locally or inside your own infrastructure, and you control what they can reach. Here the server is operated by Stripe, and the trust boundary is the OAuth grant your client negotiates. The README also points to a separate section of the same documentation for building autonomous agents with MCP, which suggests the endpoint is intended to be driven by an agent loop rather than by a human clicking through a tool call. What the README does not provide is a self-hosting path. There is no Dockerfile, no local server entry point, no configuration for pointing an MCP client at your own instance. If your security posture requires that no third party operate the tool surface your agent calls, this repository does not give you an alternative within its own material. That is a constraint, not a defect, but it should be the first thing you check against your own requirements.

Installing the Skills, and Why the Manual Path Is a Dead End

The repository ships agent skills, which the README describes as instructions that agents can use to build faster and more accurately, with the stated goal of helping agents follow current best practices when building with Stripe. The recommended installation is through official plugins for named harnesses. For Claude Code the command is claude plugin install stripe@claude-plugins-official. For Codex it is codex plugin add stripe@openai-curated. For Cursor it is /add-plugin stripe, with a marketplace link at cursor.com/marketplace/stripe given as an alternative. For Grok Build the command is grok plugin install stripe --trust. The README states that these plugins include additional agent tools and update automatically. There is also a manual route for the Agent Plugins standard, where installation methods vary by client, and you point your client at the Git URL https://github.com/stripe/ai with the subdirectory providers/agent-plugins/plugin/. Finally there is a generic fallback: npx skills add https://docs.stripe.com. The README is explicit that manually installed skills do not auto-update and that you run npx skills update -y to get the latest versions. That warning is the most practically useful sentence in the section. A team that installs manually and then forgets about it will be running stale Stripe guidance inside their agent, and stale guidance about an API surface is worse than no guidance, because the agent will act on it confidently.

What the Repository Does Not Tell You

The README is a directory, not a manual. It names the two packages and links to their subdirectories, but it does not reproduce their APIs, their configuration keys, or their expected inputs. There is no example of a metered event being reported, no code block showing a token count being passed to Stripe, and no description of how the token-meter package reads usage from an OpenAI, Anthropic or Gemini response. The phrase without any framework dependencies tells you the shape of the integration but not its surface. The same applies to the MCP endpoint: the README gives the host and the OAuth requirement and delegates everything else to docs.stripe.com/mcp#connect. There are also no releases retrieved for this repository, which matters more than it might appear. Without tagged versions, there is no changelog to read and no release notes to consult when an integration breaks. The repository was last pushed on 2026-09-10, so it is active, but activity on the default branch is not the same as a versioned contract. If you are evaluating this for production, the material here is enough to decide whether the approach fits your architecture, and not enough to decide whether the current code is stable. You will have to read the package subdirectories and the external documentation to answer that.

Where the Framework-Free Package Earns Its Place

The comparison worth making is between the two packages themselves, because the choice between them is a real architectural decision rather than a preference. @stripe/ai-sdk assumes Vercel's ai and @ai-sdk libraries are present. That is a reasonable assumption for a large share of TypeScript LLM applications, and if it holds, the integration is likely to be the shorter path, since the framework already normalises streaming responses and usage reporting across providers. @stripe/token-meter makes the opposite bet. It assumes you are calling the OpenAI, Anthropic or Gemini SDK directly, and it takes on the job of bridging those native response shapes to Stripe's billing infrastructure itself. The cost is that you own more of the glue. The benefit is that your billing integration is not coupled to a framework's release cycle, and you are not forced to introduce an abstraction layer into an application that does not otherwise need one. For a backend that calls one provider's SDK in a handful of endpoints, adding a framework purely to obtain billing hooks is a poor trade, and token-meter is the package that avoids it. For a product that already routes all model traffic through the AI SDK, the reverse holds. The README does not state whether the two packages can be used together in the same codebase, and nothing in the material confirms or denies it.

Maintenance Surface and the MIT Licence

The repository is MIT licensed, and the README links to a LICENSE file at the root. That is a permissive licence, which in practical terms means you can use, modify and redistribute the code, including in a commercial product, provided you preserve the copyright notice and licence text. This is not legal advice, and the licence text in the repository is the authoritative version rather than this summary. The maintenance picture is more ambiguous. No releases were retrieved, so there are no version tags to pin against and no published changelog. The last push date of 2026-09-10 indicates the repository is being worked on, but the default branch is main, and consuming a default branch directly is a different risk posture from consuming a tagged release. The agent skills add a second, separate maintenance obligation. The README states plainly that manually installed skills do not auto-update, and it names npx skills update -y as the command to refresh them. Teams that install through the harness plugins get automatic updates instead, which shifts the maintenance to the plugin channel. Whichever path you take, the update mechanism is part of the system you are adopting, and the manual path makes it your responsibility rather than Stripe's.

The Decision Hinges on Where Your Billing Already Lives

The narrow question this repository answers is how to get LLM consumption onto a Stripe invoice. If your billing is not in Stripe, none of the SDK material applies to you, and the MCP server and skills are the only parts worth a look, on their own terms. If your billing is in Stripe, the two packages cover the two plausible integration shapes, and the choice between them is determined by whether the Vercel AI SDK is already in your dependency tree. The MCP server is a separate decision with a separate risk profile, since it is a hosted endpoint that your agent authenticates to over OAuth rather than a process you run. The skills are the lowest-commitment part of the repository and also the easiest to let drift, given the README's own warning about manual installations. What the material does not settle is stability. With no releases retrieved and a README that functions as an index rather than a specification, the responsible next step is to read the subdirectory for whichever package you intend to use, confirm it is published under the @stripe scope on npm, and pin the version you install rather than following main.

Editorial conclusion

Adopt this if you are already billing through Stripe and need token or request usage to land on the same invoices as your other line items, whether you build on the Vercel AI SDK or call OpenAI, Anthropic and Gemini SDKs directly. Do not adopt it if your billing lives outside Stripe, or if you want a self-hosted MCP server, since the documented endpoint is the remote host mcp.stripe.com and the README does not describe running your own. Before committing, verify three things in the repository: whether the package you need is published to npm under the @stripe scope, what the token-meter integration expects in the way of usage objects from your provider, and the licence file text, since the README states MIT while the packages carry their own metadata. The repository was last pushed on 2026-09-10 and returned no releases, so pin whatever version you install rather than tracking the default branch.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. stripe/ai on GitHub