Skip to main content
The Stigg Agent SDK is in public beta.

​
What it is

The Stigg Agent SDK adds Stigg where your code already calls models: an LLM provider’s client, an AI gateway, or the agent framework that runs your agents. From then on, every model call goes through three steps:
  1. Meter usage. The tokens, and the cost where a gateway reports one, are read from each response and reported to Stigg, straight from the LLM provider or gateway you call.
  2. Enforce access. Before a call leaves your process, the SDK checks that the agent has enough credits or metered capacity to perform its task, so an agent that has run out never reaches the provider.
  3. Govern usage. Each agent gets its own identity and budget, under teams and orgs, so you know which agent spent what and can stop one without stopping the rest.
Your AI product
Your applicationcalls models through a wrapped client, fetch or orchestrator
1. Model call
4. Response, unchanged
Stigg Agent SDK
Check accesscredits and agent budgets, before the call
Ingest usagetokens and cost, after the call
2. Allowed calls only
3. Response with usage
Your agentic stack
LLM providersOpenAI, Anthropic, Gemini + more
LLM gatewaysOpenRouter, Amazon Bedrock, Cloudflare + more
OrchestratorsVercel AI SDK, LangChain, Google ADK
How you add Stigg depends on how your code calls models. See How it works. The quickest start is to wrap a provider’s client:

stigg-agent-sdk-ts on GitHub

The Agent SDK is open source under the MIT license. Browse the source, run the examples, or contribute a recipe for a new vendor.
The wrapped client takes the same arguments, returns the same types, and raises the same errors as the original. The client you passed to wrap() is left as it was, so calls through it are not metered or checked. The stiggContext tells Stigg who the call is for. The SDK removes it before the request is sent, so the provider never sees it. Every way of adding Stigg takes the same fields. You can pass the context in two places:
  • On each call, as above. One wrapped client then serves every customer, which is what a server handling many customers needs.
  • Once, on wrap(), as the default for every call through that client: stigg.wrap(new Anthropic(), { stiggContext: { customerId, entitlement } }). Use this in a process that only serves one customer. A stiggContext on a call still takes precedence over the default for the fields it sets.
Either way, every call must end up with a customerId.

​
Why use it

Meter AI usage from the client you already use

Token counts and gateway costs flow into Stigg as usage events. Price them in a plan, draw them down from a credit balance, or pass them through with a margin.

Stop spend before it happens

Most metering tools tell you a budget was exceeded after the fact. Tell the wrapper which credits or metered feature to enforce, and it checks them before each request leaves, so an agent that has run out never reaches the provider.

Charge for what each call actually cost

If you route calls through an LLM gateway, the wrapper reports what the gateway actually charged for each call, not an estimate from token counts and a price list. When the gateway falls back to a different model, you see which model served the call and what it cost.

Your AI calls keep working

Usage is reported in the background, so it adds no delay to the call. If a report fails, your user still gets their response, and the error goes to your onError hook.

​
How it works

Stigg works the same way wherever you add it. Before a model call, the SDK checks access with Stigg. After the response, it reports the usage. What changes is where the SDK sits, which depends on how your code calls models: In every case:
  • Each call says who it’s for. Each call names its customer, and optionally its agent, so one integration serves every customer. See StiggContext.
  • Checks happen only when you ask. Tell Stigg which credits or metered feature to enforce, and calls without enough left are denied before they reach the provider. Otherwise every call goes through and is only metered. See Access enforcement.
  • Streams are metered. A streamed response is reported when the stream ends. See Usage metering.

​
Agent frameworks

An agent framework, such as the Vercel AI SDK, LangChain, LangGraph or Google ADK, runs a team of AI agents. A lead agent splits up the work and hands parts to other agents, for example a researcher that searches the web and a writer that drafts the answer. Each agent calls models and uses tools, and each call costs money. You add Stigg once, in the framework’s own extension point, and your agents need no changes. Stigg then checks every model call and paid tool, and reports its usage as the agent that made it:
  • Before a model call or a paid tool runs, Stigg checks that the agent has budget left. If it doesn’t, Stigg returns a denial, and your agent decides what to do next, such as switch to a cheaper model, hand the work to another agent, or stop.
  • After the call succeeds, Stigg records what it cost against that agent’s budget.
Each agent can have its own budget, under a parent budget that caps the whole team. When one agent runs out, only that agent is denied, and the rest of the team keeps working. Each framework has its own integration: a middleware for the Vercel AI SDK, a callback handler for LangChain and a plugin for Google ADK. For any other framework, stigg.middleware() wraps each step. To set it up, see Vercel AI SDK, LangChain and LangGraph, Google ADK or your own framework.

​
Example use cases

A developer platform charges per million input and output tokens. Each wrapped call reports input_tokens and output_tokens as one event, and two metered features in Stigg sum them for the invoice. Adding a new model changes nothing in your code.
A writing assistant sells monthly credit packs. The wrapper converts tokens into credits with a weights table, checks the balance before each call, and shows the user a top-up prompt when the balance runs out instead of an error page.
A company routes all traffic through OpenRouter. The OpenRouter recipe reports the credits OpenRouter actually charged for each call, so the customer is charged real cost plus margin, even when OpenRouter falls back to a different model.
A product offers free AI usage up to a cap. With the cap modeled as a metered feature that the wrapper enforces, calls past the cap are denied before they cost anything.
A customer runs a support agent, a research agent and a coding agent from one credit balance. Each agent gets its own monthly budget, so when the research agent loops on a bad prompt, it is stopped at its own budget and the other two keep serving users.
Stigg knows how many credits each customer has left and which models their plan includes. When credits run low, or the plan has no premium access, the premium model’s call is denied before it runs. Your workflow catches the denial and switches to a cheaper model, so the job still finishes. Give each model its own budget with a budget per model, and handle the denial as shown in When access is denied.
Before a run starts, stigg.check() returns the customer’s remaining budget. Pass it to your agents with their instructions, so they plan the whole run within the limit and pick the steps, tools and models that fit. During the run, every step is still checked, so a step that would run over the budget is denied. See Access enforcement.
Each agent gets its own budget, under a parent budget that caps the whole team. Agents that run in parallel each stop at their own limit, and together they can’t spend past the parent’s. To hold credits for a whole task before it starts, reserve them up front and settle the real cost when the task ends.
Because Stigg meters each run end to end, you know what a workflow actually costs. Use that to set and revise your pricing, whether you charge by tokens through a usage mapper or by outcome, such as a fixed number of credits per report, through a paid tool’s usage.