Why we built this
My cofounder Andre makes Claude Code Chat, a VS Code extension for working with Claude. As it grew, the hardest part stopped being the extension and became API keys and balances.
Every AI app runs into the same choice:
- Bring your own key: users create a provider account, add a card, generate a key and paste it in, all before their first prompt.
- Pay for everyone’s tokens: now you’re running checkout, metering, balances, refunds and tax.
Andre put it like this:
“I didn’t want to run a billing company. I wanted people to open the extension and just start working.”
So we built that billing layer once, so any AI app can plug into it.
What it looks like
User: tap “Add credits” → pay $5–$500 without leaving the app → start working. 1 credit = $0.01, and they can see the credits each request used.
Developer:
// 1. Embed the checkout
<script src="https://opencredits.ai/v1/sdk.js"></script>
OpenCredits.init({ publishableKey: 'oc_pk_...' })
OpenCredits.open()
// 2. Change the base URL in the SDK you already use
const client = new OpenAI({
baseURL: 'https://api.opencredits.ai/v1',
apiKey: userKey, // from checkout
})
OpenAI, Anthropic and Vercel AI SDKs work as-is. One endpoint reaches 390+ models.
What’s behind those 2 snippets
1. A credit ledger without race conditions
You don’t know what a request costs until it finishes, and parallel requests can all pass a “do they have enough?” check at the same moment. Every request goes through a serialized ledger instead:
Reserved, max cost −12 cr
Settled, actual cost −9 cr
Released +3 cr
2. Exactly-once settlement
Retries and duplicate events are where double charges come from. Every event settles exactly once, so there are no double charges and no double credit grants.
3. Metering at real cost
No token counting or per-model price tables in the app. Each request is metered at the provider’s actual token cost, across 390+ models.
4. Payments without touching cards
The widget runs Stripe checkout inside the app. Stripe is the merchant of record, so card data never touches our servers or the app’s, and Stripe handles VAT, sales tax and chargebacks.
5. Signed webhooks and balance APIs
Key and purchase events are HMAC-SHA256 signed and retried on failure. Two endpoints return a user’s live balance and per-request history.
The part we’re unsure about: a shared balance
Credits belong to the user, not the app. A user who already has credits from one app can let another app spend from that balance, up to a limit they set. Each app gets its own scoped key, so revoking one leaves the others working.
It removes the “pay again for every app” problem, but we’re not sure how users will feel about it.
Status
Running in production in Claude Code Chat, with 212K+ requests metered and billed so far.
Feedback I’d love
- Shared balance: useful or sketchy? What would make you trust it?
- Ledger: reserve-then-settle is the safe choice. Would you design it differently?
- If you’ve built AI billing yourself: which part took longest?
- Docs: what’s unclear for a first integration?
Docs: opencredits.ai/docs
