Limits and rate limits
Per-key spending limits, what happens when your balance runs out, rate limits, per-model limits, the request size limit, and the errors returned when you go over each.
Requests to Echo have the following 5 limits.
| Limit | Set per | HTTP status when exceeded |
|---|---|---|
| Key spending limit | Key (optional) | 403 or 401 |
| Balance | Account | 403 |
| Rate limit (the number of requests you can send in a period) | Account, source IP address | 429 |
| Per-model limits (requests, tokens, concurrent requests) | Account and model together, and the model as a whole | 429 |
| Request body size | Request | 400 |
Key spending limits
- If you enter 「利用上限（円）」 (Spending limit (JPY)) when issuing a key, the key can spend up to that amount. A key without a limit can be used up to your account balance
- The spending limit goes down as you use it. It is never reset automatically, for example each month
- Before a request is sent, its estimated price is compared with the key's remaining spending limit. If the estimate is higher, the request is not sent and 403 is returned (
This API key has reached its spending limit) - The price is fixed from the actual token counts after the answer ends, so a key can go over its spending limit. If you send several requests at the same time, each of them passes the check above, and the amount over the limit can be more than one request. The amount over the limit is also deducted from your balance. To keep it small, send fewer requests at the same time
- A key that has used up its spending limit returns the same 401 as a wrong key (
Invalid API key). If you get 401 with a key you believe is correct, check the key's status and remaining spending limit in 「APIキー」 (API keys) in the console - You can change the limit for each key with 「利用上限を変更」 (Change spending limit) in 「APIキー」 in the console. A key that has reached its limit also resumes automatically when you raise the limit. You do not need to replace the key in your program
How to issue keys and read the key list is in API keys and usage.
When your balance runs out
When your balance is used up, requests are stopped (HTTP 403, Insufficient balance). However, like the key spending limit, the balance is checked against the estimated price before a request is sent, so the price can exceed the balance (if you send several requests at the same time, the excess can be more than one request). The excess makes the balance negative and is deducted from your next top-up.
Once a top-up is reflected in your balance, you can use the API again. This can take a few seconds to about a minute. Details of pricing and top-ups are in Pricing and top-ups.
Rate limits
| Counted per | Limit (provisional) | When exceeded |
|---|---|---|
| Account. All keys of the same account are counted together | 60 per minute. 600 per minute for Premium members | Returns 429 and Rate limit exceeded for your account, please retry after 60 seconds, with a Retry-After: 60 header |
Source IP address. Requests to paths that start with /v1 are counted | 3,000 per minute | Returns 429 and Too many requests from your IP address, please retry after the number of seconds in the Retry-After header. The Retry-After header holds the number of seconds to wait |
The upstream APIs (the APIs of the providers that actually run the models) also have rate limits. When you exceed an upstream rate limit, Echo returns 429 and The model service is temporarily rate limited, please retry after 60 seconds, with a Retry-After: 60 header.
Requests rejected by a rate limit are free. 429s caused by an upstream rate limit are also free.
Per-model limits
Some models have their own limits in addition to the rate limits above. Three things are counted. The values differ by model and by account.
| Limit | How it is counted |
|---|---|
| Requests per minute | The number of requests accepted in the last 60 seconds |
| Tokens per minute | The number of tokens used in the last minute (input plus output). It is based on actual usage, so it lags by about 10 to 20 seconds |
| Concurrent requests | The number of requests whose response has not finished yet. A streaming response counts as finished when the last part has been delivered |
There are two levels. Going over either one returns 429, and the Retry-After header holds the number of seconds to wait.
| Limit exceeded | Message returned |
|---|---|
| The share your account can use on that model | You have reached your rate limit for the model <model ID> (<kind of limit>), please retry after <seconds> seconds |
| The limit for the model as a whole (all users together) | The model <model ID> is receiving too many requests right now (<kind of limit>), please retry after <seconds> seconds |
<kind of limit> is one of requests per minute, tokens per minute, or concurrent requests. The error body has the same format as other 429s (the Anthropic format on /v1/messages, the OpenAI format elsewhere; see Errors and fixes).
Wait at least the number of seconds in Retry-After before sending again. The OpenAI and Anthropic SDKs retry a 429 automatically and follow Retry-After. If you hit the concurrent request limit, send fewer requests at the same time, or wait for the previous request to finish before sending the next. Requests rejected by a per-model limit are free.
To count per-model limits, Echo receives the whole request body before sending it to the model. If the body takes too long to arrive, Echo returns 408 and The request body was not received in time, please send the request again. You are not charged; send the same request again. If this happens with requests that carry large images or files, check your upload speed or put less in a single request.
Request size
| Item | Contents |
|---|---|
| Maximum request body size | 128 MB (provisional). Larger requests return 400 and Invalid request: request body exceeds 128 MB: request body too large |
| Number of input tokens | Up to each model's context length (the number of tokens it can handle at once), listed on each model's page in the model list |
Each upstream API also has its own request size limit. We have confirmed that a request containing a 4 MB image in base64 reaches the upstream as is. If the input is longer than the context length, the upstream API returns 400.
Sources
| What | Source | Checked |
|---|---|---|
| Rate limit values, the maximum request body size | Echo relay server settings (as of 2026-09-28) | 2026-09-28 |
403 when the estimated price exceeds the spending limit, 401 for a key that has used up its limit, the rate-limit 429 and Retry-After, counting rate limits per account, no charge for requests rejected by a rate limit, the 400 for requests larger than 128 MB | Measured in Echo's test environment, with the same relay settings as production and a server that returns test responses in place of the upstream API | 2026-09-28 |
| Requests sent at the same time each passing the estimate check and together going over the spending limit and the balance; the amount over the limit also being deducted from the balance | Measured in Echo's test environment (as above) | 2026-09-28 |
| A 4 MB image reaches the upstream | Measured in Echo's test environment (as above) | 2026-09-27 |
| Changing the spending limit, resuming a key that reached its limit, handling of a negative balance | The Echo Token Station console (screens as of 2026-09-28) | 2026-09-28 |
The 429 and the two messages when a per-model limit is exceeded, Retry-After, no charge for rejected requests, the 408 when the body arrives too slowly | Measured in Echo's test environment (as above) | 2026-10-11 |