Rate limits

Limits exist to keep the Grove fast and fair for everyone. They are generous for interactive and production use, and every limited response tells you exactly how long to wait.

The limits

Limit Value What happens when you hit it
Requests per minute 600 per account 429 with a Retry-After header
Concurrent requests 10 in-flight per account 429 with Retry-After: 2
Output tokens 32,768 per request Your max_tokens is capped, the request still succeeds

Notes on how these behave:

  • The request limit is a continuously refilling budget, not a fixed window. You can burst up to 600 requests at once; capacity then refills at about ten requests per second. Steady traffic at or below 10 requests/second never hits it.
  • Streaming responses count toward concurrency for their full duration. Ten long-running streams will occupy all ten slots until they finish.
  • Limits apply per account, across all of your API keys. Multiple keys are encouraged for organization and safe rotation, but they share one budget: creating more keys does not add throughput.
  • Limits may be adjusted over time (see the Terms of Use, Section 1). This page always shows the current values.

Coding plan concurrency

Coding plan keys have their own concurrency model: the parallel agent count on your tier card is how many requests can run at the same time on your plan key. It scales with tier: 3 agents on Basic, 5 on Pro, 6 on Elite, 7 on Ultra, 8 on Canopy. The per-account request budget above applies to plan keys as well.

Coding plan limits and the Flash floor

Plan usage has four parts, and every request runs at full speed:

  • The 5-hour window. A window starts with your first request and lasts 5 hours. One window can use up to a fifth of your weekly allowance.
  • The week. Your weekly allowance resets at the same day and time every week.
  • The bank. Whatever you leave unused in a week moves into your bank at the weekly reset, up to ten days of it. Once a week's allowance is used, the bank keeps you going, and it also keeps a window open after the window's own share is spent.
  • The month. Your plan's total for each billing period, renewing with your plan.

When a limit is reached, requests return a standard 429 with a Retry-After header and a message that names the limit (window, week or month) and exactly when it lifts, in UTC and as a relative time. SDKs and coding agents honor Retry-After automatically, so a session resumes on its own. A 429 with Retry-After: 5 and the words "concurrency wait" means requests already running on your account are holding the rest of your allowance; one frees within seconds. Nothing is ever cut off mid-response, and pacing never rewrites what you send (plan keys do carry a short safety message ahead of your messages; see Request parameters).

Every plan response carries the same four readouts as headers, so an agent can plan around them: X-PGS-Window-Left, X-PGS-Window-Resets, X-PGS-Week-Left, X-PGS-Week-Resets, X-PGS-Bank-Days, X-PGS-Month-Left, X-PGS-Month-Renews and X-PGS-Limit (the limit stopping you, or none). Percent and days only; times are ISO 8601 in UTC. GET /v1/usage returns the same numbers as JSON.

Even with your allowance fully drawn down, Flash models keep answering on a separate reserved lane, at a steady pace, a few requests at a time. Use deepseek-v4.1-flash for this (the first one every 429 suggests) or the new, lightning-fast deepseek-v4.1-flash-1017; glm-5.3-flash, mimo-v2.6-flash, deepseek-v4-flash-0731 and deepseek-v4-flash ride the same lane. To have walled requests served on a Flash model automatically, send the header X-PGS-Floor-Fallback: auto (it works on every protocol: OpenAI, Anthropic, Responses and Ollama). This is what makes messages near-endless: the Flash floor keeps answering from its own allotment when a window fills up. Higher tiers get bigger windows, deeper banks, and a faster Flash lane.

Taster keys are different. The $3.99 Taster plan (first month free) includes an API key scoped to five Flash models, deepseek-v4.1-flash-1017, deepseek-v4.1-flash, mimo-v2.6-flash, deepseek-v4-flash-0731 and glm-5.3-flash, drawing the tier's fixed allowance (about 18M+ Flash tokens a month, shared with your app usage). Taster is a fixed allowance, not a windowed plan: when the allowance is used up, requests return a quota error until it refills, and the near-endless-messages behavior above applies to plans above $3.99. Requests for any other model on a Taster key are declined with a tier error.

Two kinds of 429

Not every 429 means you sent too much. Check the message:

  1. "Rate limit reached for your account": you hit your account's request or concurrency limit. These return instantly. Back off for Retry-After seconds and continue.
  2. A busy model: when a model is congested, we first ride it out for you with an internal retry ladder (up to ~20 seconds). Only if the model stays busy do you see a 429 (with a longer Retry-After) or a 503. These are not about your usage; honor the header and retry.

Full status-code reference and backoff recipes: Errors & retries.

Best practices

  • Honor Retry-After. It is present on every 429 and is the fastest safe retry time. The OpenAI SDKs do this automatically (max_retries).
  • Add jitter to retries in high-concurrency workers so they don't retry in lockstep.
  • Keep a client-side concurrency cap (≤10) in batch jobs: a semaphore in your worker pool is simpler than handling 429s. The concurrency limit, not the per-minute limit, is what a large fan-out hits first: a small stagger (even ~100ms between launches) keeps you comfortably under it.
  • For sustained batch workloads, pace to ~10 requests/second and the request limit disappears entirely.

Requesting higher limits

To request higher rate limits, please email support@pgsgroveinternal.com with your use case and expected volume. Higher rate limits are not guaranteed to be granted.