How boostmyagents is built.

The parts

• Web application. A server-rendered Python (FastAPI) app that handles GitHub sign-in, boost pages, badges, the dashboard, and checkout.
• Gateway. A self-hosted, version-pinned LiteLLM proxy at api.boostmyagents.com. It issues the virtual keys, meters spend, and forwards requests to Anthropic.
• Database. Managed PostgreSQL holding the boost ledger and the gateway’s spend records. It accepts connections only from the application over a private network.
• Payments. Hosted Stripe Checkout. Card details never touch our servers.
• Models. Anthropic’s API, and only the models on the supported list.

The application, gateway, and database run on DigitalOcean.

What happens to a request

1. Your client sends a normal Anthropic Messages request to the gateway with your virtual key.
2. The gateway checks the key and the shape of the request: the model, the options, and the names and types of tools. It does not read the text of prompts, system instructions, or tool results.
3. It counts the request’s input tokens exactly and works out the most the request could cost.
4. If needed, it lowers the maximum output length so the request fits what is left of your boost. If the request still cannot fit, it is rejected before reaching Anthropic and is not charged.
5. The request goes to Anthropic and the response streams back to you.
6. The actual cost is recorded against your key.

Each key runs one request at a time, so two requests can never race past the limit together. If the gateway cannot work out a request’s cost in advance, it rejects the request instead of guessing.

Requests reach the gateway directly. No CDN or third-party proxy sits between your client and the gateway.

How money is tracked

• Every boost is a ledger entry in whole cents, created only when Stripe confirms the payment.
• The ledger is the single source of truth for credit, fees, refunds, and disputes. The gateway is the source of truth for what has been spent.
• A key’s spending ceiling is recalculated from the ledger each time the ledger changes. It is never edited by hand.
• Reconciling the two can only correct or flag differences. It can never create credit.
• Token counts shown anywhere are illustrations. Cents are the accounting unit.

What we store

For each gateway request

A spend record, kept for accounting and so limits can be enforced:

• The key it was made with, the model, token counts, and the cost.

Technical metadata, deleted after 30 days:

• The client software name and version.
• The feature flags the request asked for.
• Timings, token counts, and error codes. A rejection is logged with a fixed reason code.

For developers

• Public GitHub ID, username, and avatar URL.
• The identifier and display prefix of the gateway key, never the secret.

For supporters

• The Stripe payment reference, the amount and fees, and which developer was boosted.
• The optional message, if one was written.
• A keyed, one-way hash of the email or Stripe customer ID to limit abuse, never the email itself.

What we never store

• Prompt or response content.
• Card numbers.
• Gateway key secrets. A key is shown once; if it is lost, it is regenerated, not recovered.
• Repository contents. GitHub sign-in never requests repository access.

The Privacy Policy is the authoritative version of this list.