Example customer view
Acme workspace
$11.58remaining
Proposed AI allowances for SaaS products
Give every customer an AI allowance.
TenantCap is designed for SaaS teams that need a different AI allowance for each customer plan. The proposed integration would reserve an estimated amount before a selected request. Your app would call OpenAI or Anthropic directly, and the integration would settle provider-reported usage afterward so your product could show the resulting balance.
Current site status: a simulated browser demonstration and founding-fit application. The proposed SDK and allowance service are not available through this site.
For SaaS founders and product teams whose applications call OpenAI or Anthropic from TypeScript or Node.js.
Customer AI balance Simulated example
Example customer workspace
Acme workspace
AI included this monthExample
$30Pro plan exampleSelected direct call
OpenAI / AnthropicYour app would call the providerAllowance workflowExample path
Before the requestCheck what remains
After the responseUpdate the balance
The problem
Your AI provider gives you one bill. Your customers have different plans.
A Starter customer and a Pro customer should not receive the same amount of AI usage. OpenAI or Anthropic sees requests from your application, but it does not know what each customer purchased from you.
Most usage tools tell you what happened after an AI request. By then, the provider has already done the work and the cost already exists.
The proposed integration would let your app check one customer's remaining amount first. If the next request did not fit, your app could stop it before sending anything to the AI provider.
Try the example
See what happens when a customer reaches their limit.
This simulated browser example starts with a Starter customer who has used $4.90 of a $5 monthly AI allowance. The next request may cost $0.20, so the proposed check would stop it before the provider. Move the example to Pro to see the simulated path continue.
Interactive customer example
Starter has $0.10 remaining
Check whether a request that may cost $0.20 fits, then move the customer to Pro and see how the balance changes.
No real AI or payment call occurs.This example runs entirely in your browser.
Next AI request
BALANCE CHECKCustomer plan
Starter plan
- Customer
- Acme workspace
- Possible cost
- $0.20
- AI provider
- Not contacted
What happens next
Does Starter have enough left?
Starter has only $0.10 remaining, while the next request may cost $0.20.
Customer balance
LIVE EXAMPLE- Monthly limit
- $5.00
- Used
- $4.90
- Set aside
- $0.00
- Remaining
- $0.10
Starter has $0.10 remaining after $4.90 of its $5.00 monthly allowance was used.
AI provider
Waiting for the exampleThis example never sends a real AI request.
Step by step
What happened
- The balance has not been checked yet.
Proposed flow
How the proposed integration would work.
The future TenantCap SDK is designed to sit beside the selected AI calls where customer limits matter. Your application would keep its prompts, provider keys, and direct provider connection.
Check the customer’s balance
The future integration would look at the customer, their subscription plan, and the estimated cost of the next request. If the request did not fit, your app could receive a clear reason to stop it.
Customer + plan + estimated costMake the AI request
If enough remained, your application would call OpenAI or Anthropic directly. The proposed design would keep the prompt, response, and provider API key in your application.
Your app → OpenAI or AnthropicUpdate what remains
After the response, the future integration would use provider-reported usage to update that customer’s balance. Your product could then show the new amount remaining.
Reported usage → new balance
In the proposed flow, the amount checked before a request would be an estimate. Provider usage may differ, so the integration would update the balance afterward and your provider invoice would remain authoritative.
Your subscription plans
Set the AI amount included with each plan.
You would decide how much AI usage a Trial, Starter, or Pro customer receives in the proposed product. The values below are examples, not product guarantees or provider prices.
| Plan | Monthly example | Per-request max | Status |
|---|---|---|---|
| Trial | $1 per month | $0.10 per request | Example |
| Starter | $5 per month | $0.25 per request | Example |
| Pro | $30 per month | $2 per request | Example |
What the customer sees
Give customers a balance they can understand.
In the proposed product, your application could show each customer how much AI usage remains, when it resets, and what to do when the limit is reached. The example below shows a Pro customer after one simulated selected request.
Pro plan example
What your app could receive
Turn a stopped request into a useful message.
type TenantCapRefusal = {
reason: "MONTHLY_ALLOWANCE_EXHAUSTED";
remaining: "$0.06";
requiredReservation: "$0.18";
suggestedAction: "SHOW_UPGRADE";
};This structured reason would let your app show an upgrade or wait message instead of a generic error. It would apply only to the calls your application chooses to protect.
Proposed data boundary
In the proposed design, prompts, responses, and provider keys stay in your app.
The proposed integration would use only the limited information needed to check and update an allowance: an opaque customer ID, project and plan identifiers, provider and model, estimated usage, reported usage, status, and timestamps.
Would stay in your applicationPrompt + response + provider keyYour TypeScript route
Proposed direct provider callOpenAI or AnthropicSelected request
The proposed integration would not need the prompt, response content, attachment, embedding, provider key, end-user name, or end-user email to make an allowance decision.
Your code would choose which calls to protect, which customer plan to apply, and how to explain the resulting balance. Calls outside that future integration would remain invisible to TenantCap.
How it differs
The proposed TenantCap integration solves one narrow problem.
Other products route AI traffic, help developers inspect requests, or count usage after it happens. The proposed TenantCap integration focuses on whether one customer's next AI request fits the amount included with their plan.
| Option | Primary layer | How the path differs |
|---|---|---|
| LiteLLM | Routes model requests through a gateway | A gateway gives your application a new route to AI providers. The proposed TenantCap integration would keep your direct provider connection and add an allowance check beside selected calls. |
| Portkey | Routes and manages AI traffic | AI operations platforms can manage model traffic through a shared layer. TenantCap is designed for a narrower job: deciding whether one customer’s request fits the AI amount included with their plan. |
| Helicone | Helps developers inspect AI requests | Observability tools explain what happened across model requests. The proposed TenantCap integration would make a plan decision before a selected request and give your product a balance it could display to the customer. |
| Vercel AI Gateway | Provides a hosted route to AI providers | A hosted gateway sits between your application and model providers. The proposed TenantCap design would leave the provider call in your application and check the customer’s allowance around it. |
| OpenMeter | Counts product usage | General metering helps a company count usage for billing or reporting. The proposed integration would also check whether a selected AI request fits before dispatch, then update the customer’s balance afterward. |
| A custom Redis/database ledger | Stores balances your team builds itself | A custom ledger gives your team storage and full control, while your team designs the rules and edge cases. The proposed first release would package the customer limit, pre-request check, balance update, and refusal into one focused workflow. |
A gateway changes the route
A gateway sends AI requests through another service. The proposed TenantCap integration would leave the OpenAI or Anthropic request in your application and add the customer balance check beside it.
Counting usage happens afterward
General metering tells you how much was used. The proposed integration would also check whether enough remains before a selected request is sent, then update the balance afterward.
The balance belongs in your product
Developer tools can explain system activity to your team. The proposed product would give your application a simple amount that one customer could understand.
Planned first release
What the proposed first release would include.
The planned first release is a focused future integration for SaaS teams using OpenAI or Anthropic from TypeScript or Node.js. The current site demonstrates this scope in a browser; it does not ship the SDK or allowance service.
Planned product scope
- A future TypeScript SDK for selected OpenAI and Anthropic text requests
- A plan-specific AI limit for each customer’s subscription plan
- A balance check before each selected request
- A balance update using provider-reported usage after the response
- A clear refusal when the customer does not have enough remaining
- A balance your product could show to the customer
Proposed limits
The limits are part of the proposed design.
The proposed integration would help enforce the AI amount included with one customer's plan. Its boundary covers selected calls and leaves the other systems your business relies on in place.
The proposed integration would see only the AI calls your application chooses to protect.
Calls outside the future SDK would remain invisible and could not be stopped by TenantCap.
The OpenAI or Anthropic invoice would remain the official record of what you owe.
The amount checked before a request would be an estimate, so the final provider charge could be higher.
The proposed product would not replace your billing system, payment records, monitoring tools, or security controls.
The proposed boundary covers selected customer calls. It does not cover your entire provider account.
Founding fit application
Apply when customer AI limits are part of your product.
The application is for SaaS teams whose products need different AI allowances for different customer plans. The current site provides a simulated browser demonstration and application intake; the proposed SDK and allowance service are not available through this site. When your answers have been saved, the form shows a confirmation ID. The application is reviewed against the current product boundary. No payment is collected and no access is reserved when you apply.
First stepFitreviewed against current scope
- TypeScript or Node.js server application
- Direct OpenAI or Anthropic calls
- At least 20 customer accounts
- Plan-specific AI allowances
- A current allowance approach to discuss
- A clear product-boundary confirmation
Apply for founding fit
Submitting the application does not collect payment or reserve access.
Common questions
What you should know before applying.
These questions cover how TenantCap fits your application and what the Founding fit review considers.
Would TenantCap receive my prompts or API keys?
In the proposed design, your application would keep the prompt, model response, and provider API key. It would continue calling OpenAI or Anthropic directly. TenantCap would receive only the limited identifiers and usage information needed to check and update a customer’s allowance.
What happens when a customer has too little remaining?
For a call protected by the future SDK, your app could receive a clear refusal before sending the request to the AI provider. Your product could then explain the limit, ask the customer to wait, or offer an upgrade.
Would the amount always match my provider bill?
The pre-request amount would be an estimate used to decide whether the request fits. The proposed integration would update the balance after the response using provider-reported usage, while the provider invoice would remain authoritative.
Would TenantCap cover every AI call in my account?
The proposed integration would cover only the calls your application chooses to protect with the future SDK. Other calls would remain invisible and could not be stopped by TenantCap.
Who is the founding-fit application for?
The founding-fit application is for TypeScript or Node.js SaaS teams that call OpenAI or Anthropic directly, serve at least 20 customer accounts, and are evaluating different AI allowances for different subscription plans.
How does the Founding fit application work?
You submit the ten qualification answers and response consent. Once your answers have been saved, the form shows a confirmation ID. The application does not collect payment or reserve access.
Founding fit application
Describe where customer AI limits fit your product.
If your app calls OpenAI or Anthropic directly and your plans include different amounts of AI usage, the application compares your use case with the proposed first-release boundary. It does not provide product access.
Apply for founding fitNo payment is collected and no access is reserved.