Skip to main content
A visible balance doesn’t guarantee that a request passes the pre-authorized charge, token quota, group, and permission checks. The most common cause is a large input whose estimated cost exceeds your balance; the next is a token that has used up its own quota. Last verified October 5, 2026; the console is the source of truth for prices and quota rules.

​
Most common cause: the pre-authorized charge exceeds your balance

Before each request runs, LaoZhang API estimates the maximum it could cost from the model’s price, the input size, and the expected output, and reserves that amount from your balance. When the request finishes, it’s settled on actual usage and the unused part is released.
  • If your balance covers the reserved amount, the request goes through.
  • If it doesn’t, the request is rejected before it runs with insufficient_user_quota. The model isn’t called and nothing is charged.
The error body looks like this:
  • quota is your current available balance.
  • preConsumedQuota is the amount this request needs to reserve.
  • Both use internal quota units, where 500,000 is about $1. Here the balance is about $100 and the reservation about $300, so the request is rejected.
The reservation is a worst-case estimate, not the final charge. To fix it:
  1. Trim the input to the code, documents, or chat history the task actually needs.
  2. Set an explicit output limit to lower the expected output. See max_tokens.
  3. If you really need the large input, top up until your balance exceeds the reservation. See payment methods.
Tokens have their own quota too.
  • If you turned off unlimited quota when creating a token, requests with that token are rejected once its quota runs out, even with money left in the account.
  • Edit the token in Tokens and raise its quota; you don’t need a new key.

​
Troubleshooting sequence

​
1. Record the actual error

Do not diagnose from a generic “insufficient balance” client message alone. If the error body contains insufficient_user_quota, start with the section above. Record:
  • Request time and time zone
  • Model ID and endpoint
  • API key group
  • HTTP status and platform error
  • Whether the request produced usage or a charge

​
2. Confirm current pricing and billing unit

Open the console pricing page and confirm whether the target model is billed by token, request, image, video duration, or another unit. Do not use an upstream provider’s price or an old static documentation table to predict the charge.

​
3. Reduce input size

Long context, multiple images, large files, PDFs, videos, or a large output limit may increase estimated usage. Retry with a minimal input:
  • Keep one short message
  • Temporarily remove images, files, and tool calls
  • Use an explicit, smaller output limit
  • Keep other variables unchanged so the result is diagnostic

​
4. Check group, permission, and endpoint

The same model name may use different routes depending on the API key group, billing type, or endpoint. Confirm that:
  • The key permits the target model and billing mode
  • The endpoint matches the current documentation
  • The model ID is exact
  • The account does not require a permission adjustment from the site owner or support

​
5. Separate platform and upstream errors

If a minimal request still fails, check for rate limits, safety blocks, upstream unavailability, timeouts, or temporary routing problems. Do not retry indefinitely. Fix parameters, permissions, or balance for non-retryable errors; use bounded retries and backoff for temporary errors.

​
What to provide to support

  • Account email or username
  • Request time and time zone
  • Model ID, endpoint, and API key group
  • Redacted error and request identifier
  • Screenshots of the console balance and pricing page
  • Result of a minimal reproduction
Do not send complete API keys, full prompts or responses, or unrelated customer data. For refunds or balance adjustments, see payment methods and refunds.