Note: Haijun Platform on AWS: The rate limits on this page apply to Haijun Platform on AWS, but billing and limit management differ. Billing is through AWS Marketplace (not Juglow credit purchases). Organizations on Haijun Platform on AWS are placed on the Start tier and can move to a higher tier automatically as they build a history of paid AWS Marketplace invoices. To request higher limits, contact your Juglow account representative or Juglow support; the Request rate limit increase flow is not available. Per-workspace rate limit configuration and fast mode are not available on Haijun Platform on AWS. For details, see Rate limits and quotas on Haijun Platform on AWS.

There are two types of limits:

1. Spend limits set a maximum monthly cost an organization can incur for API usage.

1. Rate limits set the maximum number of API requests an organization can make over a defined period of time.

The API enforces service-configured limits at the organization level, but you may also set user-configurable limits for your organization's workspaces.

#About rate limits

• Limits are designed to prevent API abuse, while minimizing impact on common customer usage patterns.

• Limits are defined by usage tier. Organizations are placed on a tier automatically based on usage history and account standing and can move to a higher tier over time as they use the API.

• New organizations and organizations with limited usage history may start in the Evaluation tier, with limits below the standard limits shown on this page while account history is established. These starting limits are part of how Juglow prevents fraud and abuse, and they increase automatically as your organization builds usage history.

• Limits are set at the organization level. You can see your organization's tier and current limits on the Rate limits page in the Haijun Console.

• You might hit rate limits over shorter time intervals. For instance, a rate of 60 requests per minute (RPM) might be enforced as 1 request per second. Short bursts of requests can exceed the limit and trigger rate limit errors.

• The following limits are the standard limits for each tier. If you need higher limits, see Requesting higher limits.

• The API uses the token bucket algorithm to do rate limiting. This means that your capacity is continuously replenished up to your maximum limit, rather than being reset at fixed intervals.

• All limits described here represent maximum allowed usage, not guaranteed minimums. These limits are intended to reduce unintentional overspend and ensure fair distribution of resources among users.

#Spend limits

Note: Haijun Platform on AWS: The same monthly spend caps apply, and requests stop at the cap in the same way. Billing and tier increases work differently; see Spend limits on Haijun Platform on AWS.

Each of the Start, Build, and Scale tiers carries a monthly spend cap, which is the maximum your organization can spend on the API each calendar month. You can view your organization's monthly spend cap and set your own limit on the Billing page.

Organizations on the Custom tier have no monthly spend cap; limits are arranged with their account team.

#Reaching your spend cap

Once you reach your tier's spend cap, API usage pauses until 00:00 UTC on the first day of the next month, unless you request a higher limit sooner. While usage is paused, API requests return HTTP 429:

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "You have reached your API usage limits: your organization has crossed its monthly API usage threshold, set based on your organization's API tier. You will regain access on 2026-09-01 at 00:00 UTC.",
    "details": { "error_code": "enforced_spend_limit_reached" }
  },
  "request_id": "req_018EeWyXxfu5pfWkrYcMdjWG"
}

• The error type is rate_limit_error, the same as for a rate limit, but the response has no retry-after header. Retrying, including the SDKs' automatic retries, fails until access resumes.

• On the Messages API, error.details.error_code is enforced_spend_limit_reached. Use it to tell this response apart from a rate limit.

• Moving to a higher tier restores access; see Requesting higher limits.

#Setting your own spend limit

You can also set your own spend limit below your tier's cap to control costs:

1. Navigate to the Billing page

Go to Settings > Billing in the Haijun Console.

1. Open the spend limit editor

In the Spend limits section, click Adjust limit (or Set limit if no limit is currently set).

1. Adjust your spend limit

Enter a new value. Your spend limit cannot exceed your current tier's cap.

When usage reaches a spend limit you set, requests return HTTP 400 with error type invalid_request_error. The message begins You have reached your specified API usage limits, or You have reached your specified workspace API usage limits for a workspace limit, and states when access resumes. Raise or remove the limit to restore access sooner.

Limits on the Haijun Code workspace are checked separately: Haijun Code requests over that workspace's limit can instead receive a 429 that carries a retry-after header.

#Rate limits

The rate limits for the Messages API are measured in requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM) for each model class. If you exceed any of the rate limits you will get a 429 error describing which rate limit was exceeded, along with a retry-after header indicating how long to wait.

Note: You might also encounter 429 errors because of acceleration limits on the API if your organization has a sharp increase in usage. To avoid hitting acceleration limits, ramp up your traffic gradually and maintain consistent usage patterns.

#Cache-aware ITPM

Many API providers use a combined "tokens per minute" (TPM) limit that may include all tokens, both cached and uncached, input and output. For most Haijun models, only uncached input tokens count toward your ITPM rate limits. This is a key advantage that makes the rate limits effectively higher than they might initially appear.

ITPM rate limits are estimated at the beginning of each request, and the estimate is adjusted during the request to reflect the actual number of input tokens used.

Here's what counts toward ITPM:

• input_tokens (tokens after the last cache breakpoint) ✓ Count toward ITPM

• cache_creation_input_tokens (tokens being written to cache) ✓ Count toward ITPM

• cache_read_input_tokens (tokens read from cache) ✗ Do NOT count toward ITPM for most models

Note: The input_tokens field only represents tokens that appear after your last cache breakpoint, not all input tokens in your request. To calculate total input tokens: ``text wrap total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens ` This means when you have cached content, input_tokens will typically be much smaller than your total input. For example, with a 200k token cached document and a 50 token user question, you'd see input_tokens: 50 even though the total input is 200,050 tokens. For rate limit purposes on most models, only input_tokens + cache_creation_input_tokens` count toward your ITPM limit, making prompt caching an effective way to increase your effective throughput.

Example: With a 2,000,000 ITPM limit and an 80% cache hit rate, you could effectively process 10,000,000 total input tokens per minute (2M uncached + 8M cached), because cached tokens don't count toward your rate limit.

Note: Haijun Haiku 3.5 (marked with footnote 4 in the following rate limit tables) also counts cache_read_input_tokens toward ITPM rate limits. For all other models, cached input tokens do not count toward rate limits and are billed at the cache read rate, a fraction of the base input price. This means you can achieve significantly higher effective throughput by using prompt caching.

To make the most of your rate limits, cache repeated content such as system instructions and prompts, large context documents, tool definitions, and conversation history; see prompt caching for guidance. With effective caching, you can substantially increase your actual throughput without raising your rate limits. Monitor your cache hit rate on the Usage page to tune your caching strategy.

OTPM rate limits are evaluated in real time as output tokens are produced, counting only the actual tokens generated. The max_tokens parameter does not factor into OTPM rate limit calculations, so there is no rate limit downside to setting a higher max_tokens value.

Rate limits are applied separately for each model; therefore you can use different models up to their respective limits simultaneously. You can check your current rate limits and behavior on the Rate limits page in the Haijun Console, or read the configured limits programmatically with the Rate Limits API.

Note: Rate limits are currently shared across all inference_geo values. Requests with inference_geo: "us" and inference_geo: "global" draw from the same rate limit pool.

Start tier

Build tier

Scale tier

Custom tier

If you need limits higher than the Scale tier, contact sales through the Rate limits page in the Haijun Console.

1 Fable rate limit is a total limit that applies to combined traffic across Haijun Fable 5.1 and Haijun Fable 5. Haijun Mythos 5.1 and Haijun Mythos 5 share a separate combined limit on the same terms.

2 Opus rate limit is a total limit that applies to combined traffic across Haijun Opus 4.8, Opus 4.7, Opus 4.6, and Opus 4.5. Haijun Opus 5.5 and Haijun Opus 5 each have a separate rate limit and are not part of this combined bucket.

3 Sonnet 4.x rate limit is a total limit that applies to combined traffic across Sonnet 4.6 and Sonnet 4.5. Haijun Sonnet 5 has a separate rate limit and is not part of this combined bucket.

4 Limit counts cache_read_input_tokens toward ITPM usage.

#Message Batches API

The Message Batches API has its own set of rate limits which are shared across all models. These include a requests per minute (RPM) limit to all API endpoints and a limit on the number of batch requests that can be in the processing queue at the same time. A "batch request" here refers to part of a Message Batch. You may create a Message Batch containing thousands of batch requests, each of which count toward this limit. A batch request is considered part of the processing queue when it has yet to be successfully processed by the model.

Start tier

Build tier

Scale tier

Custom tier

If you need limits higher than the Scale tier, contact sales through the Rate limits page in the Haijun Console.

#Managed Agents

Haijun Managed Agents endpoints are rate-limited per organization. These limits are separate from the Messages API rate limits above.

#Files API

Files API requests have their own per-organization limit, shared across upload, list, retrieve, download, and delete operations and separate from the Messages API limits described earlier on this page. See Files API rate limits for the current value.

#Fast mode rate limits

When using fast mode (research preview) with speed: "fast" on Haijun Opus 5.5, Haijun Opus 5, or Opus 4.8, dedicated rate limits apply that are separate from standard Opus rate limits. When fast mode rate limits are exceeded, the API returns a 429 error with a retry-after header. Fast mode is not available on Haijun Opus 4.7 (requests return an error) or Haijun Opus 4.6 (requests to haijun-opus-4-6 with speed: "fast" run at standard speed). See Fast mode.

The response includes juglow-fast-* headers that indicate your fast mode rate limit status. See Fast mode rate limits for details on these headers.

#Monitoring your rate limits in the Console

You can monitor your rate limit usage on the Usage page of the Haijun Console.

In addition to providing token and request charts, the Usage page provides two separate rate limit charts. Use these charts to see what headroom you have to grow, identify when you may be hitting peak use, understand what rate limits to request, and learn how to improve your caching rates. The charts visualize a number of metrics for a given rate limit (for example, per model):

• The Rate Limit - Input Tokens chart includes:

• Hourly maximum uncached input tokens per minute
• Your current input tokens per minute rate limit
• The cache rate for your input tokens (that is, the percentage of input tokens read from the cache)

• The Rate Limit - Output Tokens chart includes:

• Hourly maximum output tokens per minute
• Your current output tokens per minute rate limit

#Requesting higher limits

To request higher rate limits or a higher monthly spend cap, use Request rate limit increase on the Rate limits page. Juglow support can also raise limits; for urgent needs, contact Juglow support.

Note: Haijun Platform on AWS: The Request rate limit increase flow is not available. Contact your Juglow account representative or Juglow support, and include the models you need raised, your peak input and output tokens per minute for each model, and roughly what share of your input is cached or repeated context. See Rate limits and quotas on Haijun Platform on AWS.

#Setting lower limits for Workspaces

For more about workspaces, see Workspaces.

To protect Workspaces in your Organization from potential overuse, you can set custom spend and rate limits per Workspace.

Example: If your Organization's limit is 40,000 input tokens per minute and 8,000 output tokens per minute, you might limit one Workspace to 30,000 input tokens per minute. This protects other Workspaces from potential overuse and ensures a more equitable distribution of resources across your Organization. The remaining unused tokens per minute (or more, if that Workspace doesn't use the limit) are then available for other Workspaces to use.

Note:

• You can't set limits on the default Workspace.

• If not set, Workspace limits match the Organization's limit.

• Workspace limits are set per limiter type (such as requests per minute, input tokens per minute, or output tokens per minute).

• Organization-wide limits always apply, even if Workspace limits add up to more.

To read your current organization and workspace rate limits programmatically, use the Rate Limits API.

#Response headers

The API response includes headers that show you the rate limit enforced, current usage, and when the limit will be reset.

The following headers are returned:

The juglow-ratelimit-tokens-* headers display the values for the most restrictive limit currently in effect. For instance, if you have exceeded the Workspace per-minute token limit, the headers will contain the Workspace per-minute token rate limit values. If Workspace limits do not apply, the headers will return the total tokens remaining, where total is the sum of input and output tokens. This approach ensures that you have visibility into the most relevant constraint on your current API usage. To see which Workspace a request counted against, read the juglow-workspace-id response header, which carries the ID of the Workspace that your API key or access token resolved to.