What the customer actually buys
The customer buys a CorvusLLM key with prepaid USD balance. The key is the identity used for requests, tracking, dashboard login by key, and top-ups.
- The customer does not need their own provider keys.
- The customer does not need to manage separate keys per provider.
- The customer keeps one dashboard view of balance, requests, and model breakdown.
How model routing works
Customers keep using the public CorvusLLM model slugs. CorvusLLM then routes the request internally by model family to the correct upstream credential pool.
| Customer requests | CorvusLLM does internally |
|---|---|
| Anthropic family slugs | Routes to the Anthropic or Haiku upstream credential pool. |
| OpenAI family slugs | Routes to the OpenAI upstream credential pool. |
| Gemini and GLM slugs | Routes to the shared Google + Z.AI upstream credential pool. |
Important billing rule
Billing follows the CorvusLLM model the customer requested. The customer balance is not tied to the internal upstream key that actually carried the request.
What happens when a payment clears
- The order becomes
paid_confirmed. - CorvusLLM creates a customer key or credits the customer's existing key.
- The key and base URL are shown on the confirmation page immediately.
- The delivery email and claim flow are sent in parallel.
- The same key can then be used in the API and the personal dashboard.
What happens at zero balance
CorvusLLM stops the key instead of silently letting it overspend.
- API response:
429out of balance. - Dashboard: remaining balance shows the true current state on the same key.
- Top-up: the same key is credited again and starts working again as soon as the top-up confirms.