Key facts
| Limit type | Requests per minute (RPM) by plan tier, not per-token billing |
| Usage in plans | Unlimited usage within fair-use limits; no per-token or per-request charges |
| Rate error | HTTP 429 with Retry-After on every over-limit response |
| Client behaviour | SDKs retry with exponential backoff and jitter |
| Key-level control | Scoped keys let you isolate services and monitor usage separately |
| Budget guard | Project hard caps with warning thresholds block spend at 100% |
| Limit increases | Request higher limits from the dashboard or via support |
| Product status | Live |
TL;DR
- Plans limit request rate per minute — not tokens, not spend per call.
- 429 always carries Retry-After; back off exactly that long.
- Use separate keys per service so one runaway job cannot starve the rest.
- Add project budget caps even on flat plans, as a runaway-loop guard.
- Scale needs are a plan question, not a per-token negotiation.
How it works, step by step
- Measure your peak requests per minute and concurrency on real traffic.
- Map each service to its own scoped key so usage is attributable.
- Implement 429 handling with Retry-After and jittered exponential backoff.
- Set project budget caps and warning thresholds as a fail-safe against loops.
- Add server-side concurrency limits and request timeouts in your own workers.
- Monitor per-key request rates and error rates in usage analytics.
- Request a higher tier or enterprise limits before a launch, not during one.
Try it yourself
Open the rate limit calculator →
What Plugsky limits — and what it does not
The only self-serve throttle is the per-minute request rate attached to your plan. There are no per-token charges, no per-request charges and no overage fees on self-serve plans; token counts are returned in every response for observability but do not drive billing. Enterprise agreements replace the shared fair-use rate with contracted limits. That model makes capacity planning simple: estimate peak RPM and concurrency, not monthly token spend.
Handling 429 correctly
A 429 means the request is valid but arriving too fast. The response includes Retry-After; wait at least that long before the next attempt, and add jitter so a fleet of workers does not retry in unison. Plugsky SDKs already implement exponential backoff. Custom clients should retry a bounded number of times, apply a per-request deadline, and surface a degraded result rather than queueing indefinitely. Pair rate-limit handling with Idempotency-Key so a retried POST returns the cached response instead of executing twice.
Quotas, caps and key hygiene
- One key per service: chat, embeddings and batch workloads should not share credentials, so one hot loop cannot exhaust the others' headroom.
- Scopes as limits: a key that can only write embeddings cannot accidentally consume chat capacity.
- Budget caps: project-level hard caps with warnings at defined thresholds stop runaway spend; requests beyond a hard block are rejected rather than billed.
- Per-key metrics: usage analytics and request logs show which key drove the spike, which turns incidents into five-minute fixes.
Growing past the default rate
Two levers exist: plan tier and contract. Higher self-serve tiers raise the fair-use request rate and the number of keys and seats; enterprise agreements replace shared limits with committed capacity, private deployment options and support terms documented at /legal/sla. Plan the upgrade before a launch or a seasonal peak — capacity conversations are easier weeks ahead than during an incident. If your workload is spiky, ask whether the limit is on average rate or instantaneous bursts, and align your client-side concurrency with the answer.
Honest comparison
| Capability | Plugsky | Per-token API | Self-hosted inference |
|---|---|---|---|
| Limit model | Fair-use requests per minute by tier | Tokens per minute and per-request caps | Hardware-bound |
| Cost predictability | Flat monthly plans, no token charges | Varies with usage | Fixed infra plus ops |
| Over-limit signal | 429 with Retry-After | 429, sometimes undocumented | Your queue depth |
| Budget guard | Project hard caps with warnings | Often invoiced after the fact | Not applicable |
| Key isolation | Scoped keys per service | Usually available | You build auth |
| Scaling path | Higher tier or enterprise contract | Automatic but costly at volume | Buy more GPUs |
Frequently asked questions
What exactly does Plugsky rate limit?
Requests per minute by plan tier. Self-serve plans include unlimited usage within fair-use request limits — there are no per-token, per-request or overage charges.
What happens when I exceed the limit?
The API returns 429 with a Retry-After header. Wait at least that long, then retry with exponential backoff and jitter. SDKs handle this automatically.
Do token counts affect my limit?
No. Token usage is returned in every response for observability, but the throttle is request rate. Flat plans do not bill per token.
How do I isolate workloads from each other?
Use a scoped key per service and environment. Isolating chat, embeddings and batch workloads means a spike in one does not consume another's headroom.
Can I cap spend on a project?
Yes. Project-level hard budget caps with warning thresholds are available and block requests at the cap instead of letting spend run away.
How do I get a higher limit?
Scale up the plan tier for a higher fair-use rate, or discuss enterprise limits for committed capacity. The dashboard and support can start that conversation.
Are limits shared across all my API keys?
Limits apply at the workspace or plan level, so keys share the tier's rate. Per-key scopes and monitoring still let you attribute and contain usage.
What is the free plan's rate for the free models?
The free plan includes the two free models (plugsky-micro and plugsky-lite) with its own fair-use request rate and two API keys. See the live pricing page for current details.