# Stripe AI: the @stripe/ai-sdk and @stripe/token-meter packages for metering LLM usage > Stripe's stripe/ai repository collects two SDKs that connect LLM calls to Stripe billing, plus a remote MCP server and agent skills. It is a metering layer, not a model or an agent framework. **stripe/ai** — One-stop shop for building AI-powered products and businesses with Stripe. - Repository: https://github.com/stripe/ai - Website: https://docs.stripe.com/agents - Stars: 1,849 · Forks: 349 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/stripe-ai ## What stripe/ai actually solves: metering LLM calls into Stripe Building an AI product means paying a model provider per token and charging your own customers for the result. The two systems rarely meet. Token counts live in the provider response, revenue lives in Stripe, and the glue between them is usually a homegrown counter that drifts from the invoice. The stripe/ai repository is Stripe's answer to that gap. It contains a collection of SDKs to help you integrate Stripe with LLMs and agent frameworks, and the README names two: @stripe/ai-sdk for integrating Stripe's billing infrastructure with Vercel's ai and @ai-sdk libraries, and @stripe/token-meter for doing the same with native SDKs from OpenAI, Anthropic, and Google Gemini, without any framework dependencies. The audience is narrow and specific. If you are building a chat product, an agent, or any feature where a customer's usage maps to a price, and you already run billing on Stripe, these packages are aimed at you. If you are building an internal tool where nobody pays per token, the metering layer has nothing to meter. ## Two SDKs, one metering concern: how the packages divide the work The split between the two packages is the clearest design decision in the repository. @stripe/ai-sdk sits on top of Vercel's ai and @ai-sdk libraries, so it assumes your model calls already flow through that abstraction. @stripe/token-meter takes the other route: it works with the native OpenAI, Anthropic and Google Gemini SDKs and carries no framework dependency. That matters because the two audiences have different migration costs. A team already on the Vercel AI SDK gets a shorter path with @stripe/ai-sdk because the wrapper has a known call shape to hook. A team calling openai directly, or mixing providers behind its own interface, would have to adopt Vercel's abstraction first, which is a much larger change than adding a metering call. The repository layout supports this reading. The llm/ directory holds the SDK sources, and the top level also carries providers/, skills/, benchmarks/, tests/ and tools/ alongside per-harness plugin directories such as .claude-plugin/, .codex-plugin/, .cursor-plugin/ and .grok-plugin/. The README does not describe a shared runtime that ties these together; the packages are published separately and the agent plugins are a distribution channel for instructions, not a service. ## Installing the SDKs and wiring the first metered call The README does not print install commands for @stripe/ai-sdk or @stripe/token-meter. It links to the subdirectories llm/ai-sdk and llm/token-meter, and those are where the package-specific setup lives, so read the relevant one before you start. What the README does give verbatim is the manual skills install, run from your project directory: ```bash npx skills add https://docs.stripe.com ``` That command pulls Stripe's agent skills into the project. The README warns in a blockquote that manually installed skills don't auto-update and that you should run npx skills update -y to get the latest versions. If you use a supported harness, Stripe recommends the plugin route instead, because those include additional agent tools and update automatically. For Claude Code: ```bash claude plugin install stripe@claude-plugins-official ``` For Codex: ```bash codex plugin add stripe@openai-curated ``` For Cursor, the README gives a slash command rather than a shell command: ``` /add-plugin stripe ``` For Grok Build: ```bash grok plugin install stripe --trust ``` For the newer Agent Plugins standard, the README states that installation methods currently vary by client, and offers a Git URL, https://github.com/stripe/ai, with the subdirectory providers/agent-plugins/plugin/ as the location to point a client at. None of these commands install the billing SDKs. They install instructions for coding agents, which is a different job, and conflating the two is the most likely first mistake. ## The remote MCP server at mcp.stripe.com and what it does not cover Separate from the SDKs, Stripe hosts a remote MCP server at https://mcp.stripe.com. The README states that this allows secure MCP client access via OAuth and points to the docs at https://docs.stripe.com/mcp#connect, and that you can also build autonomous agents with MCP. Two things are worth being precise about. First, this is a hosted endpoint, not something in the repository you run yourself, so its availability and behaviour are governed by Stripe's service rather than by the MIT licence that covers the code here. Second, the README does not describe the tool surface the server exposes, the scopes an OAuth grant requests, or what an agent can do once connected. Those details sit behind the docs link. If your evaluation depends on knowing exactly which Stripe operations an agent can reach, the repository alone will not answer that, and you should treat the MCP server as a distinct integration to assess on its own terms. ## Where stripe/ai is the wrong tool The repository is a metering and integration layer, and the README never claims otherwise. It does not route between model providers, it does not manage prompts, and it does not give you an agent runtime. If your problem is that calls to OpenAI time out and you want failover to Anthropic, @stripe/token-meter is not the answer; it wraps native SDKs so their usage can be billed, and provider selection stays your code's job. The same applies to cost control. Metering records what was consumed, which is a prerequisite for capping spend, but a recorded token count is not a budget enforcement mechanism, and the README documents no rate limiting, retry policy or spend ceiling. There is also a framework tax worth naming. Choosing @stripe/ai-sdk ties your metering to Vercel's ai and @ai-sdk libraries; if you later move off that abstraction, the metering integration moves with it. The framework-free @stripe/token-meter exists precisely to avoid that coupling, which suggests Stripe expects some teams to outgrow the first option. ## How this differs from a general LLM gateway A gateway such as LiteLLM or an AI proxy in front of your model calls solves a different problem: one endpoint, many providers, shared retries, logging and key management. Those tools sit between your application and the model provider and are largely indifferent to how you charge customers. stripe/ai sits on the other side of the call. It assumes the model provider relationship already exists, whether through the Vercel AI SDK or a native client, and its concern is what that call costs the customer and how Stripe records it. The practical consequence is that the two are not substitutes. A team running LiteLLM in front of several providers still needs something to turn usage into billable events, and that is the slot @stripe/token-meter occupies. A team that only needs provider multiplexing will find nothing here for them, because the repository contains no routing or failover component at all. ## Licence, maintenance and the cost of keeping skills current The repository is MIT licensed, with the licence text in LICENSE. For the SDK packages that is a permissive arrangement: you can use and redistribute them, subject to the usual attribution terms, though nothing here is legal advice and you should read the file rather than this summary. The maintenance picture is mixed by surface. The last push to the default branch was on 2026-09-10, so the code is recent. The agent skills are the part with an ongoing cost, and the README is explicit about it: manually installed skills don't auto-update, and you are told to run npx skills update -y to stay current. That is a recurring task you own. Stripe's own recommendation is to install through a harness plugin instead, because those include additional agent tools and update automatically, which shifts the update burden to the plugin channel. Either way, the skills encode current best practices for building with Stripe, so a stale copy means your coding agent is working from outdated instructions. The SDKs themselves carry no comparable update note in the README. ## Conclusion Adopt stripe/ai if you already bill through Stripe and need LLM token usage to show up as metered billing, and pick @stripe/token-meter over @stripe/ai-sdk when you are not on the Vercel AI SDK. Do not adopt it as a model gateway, a prompt framework or an agent runtime; it is none of those, and the README documents no rate limiting, retry policy or cost cap. Before writing code, verify three things in the subdirectory READMEs: that the token-meter wrapper covers the provider SDK version you ship, that the metering path you want is supported for your Stripe account, and that the MIT licence in LICENSE is compatible with how you redistribute the package. The remote MCP server at https://mcp.stripe.com is a separate surface with its own OAuth setup, so treat it as a second decision rather than part of the SDK install. ## FAQ ### What is stripe/ai? It is a Stripe repository that collects SDKs for integrating Stripe with LLMs and agent frameworks, along with a remote MCP server and a set of agent skills. The README names @stripe/ai-sdk for Vercel's ai and @ai-sdk libraries and @stripe/token-meter for native OpenAI, Anthropic and Google Gemini SDKs. ### How does Stripe use AI? The repository shows the integration direction Stripe publishes: SDKs that connect LLM usage to Stripe's billing infrastructure, a remote MCP server at https://mcp.stripe.com for OAuth-based MCP client access, and agent skills that help coding agents follow current Stripe practices. The README does not describe Stripe's own internal use of AI. ### Is Stripe an AI company? The README presents Stripe as billing infrastructure that AI products build on, not as a model provider. The packages here meter LLM usage into Stripe billing and connect agents to Stripe through MCP. ### Is Stripe using AI? The repository documents Stripe's AI-facing tooling rather than its internal systems: two billing SDKs for LLM usage, a hosted MCP server, and agent skills distributed through harness plugins or npx skills add. Nothing in the README states how Stripe uses AI in its own operations. ### What is stripe z ai? The repository does not use that name anywhere. It documents @stripe/ai-sdk and @stripe/token-meter, a remote MCP server at https://mcp.stripe.com, and agent skills, and there is no component called stripe z ai in the README or the top-level directory listing. ## Sources - [Issues](https://github.com/stripe/ai/issues) - [License: MIT](https://github.com/stripe/ai/blob/main/LICENSE) - [Project website](https://docs.stripe.com/agents) - [README](https://github.com/stripe/ai/blob/main/README.md) - [stripe/ai on GitHub](https://github.com/stripe/ai) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stripe-ai