Key facts
| Billing | Flat monthly plans with unlimited fair-use usage on self-serve |
| No token billing | No per-token charges and no overage fees on self-serve plans |
| Limits that apply | RPM, TPM and concurrency caps protect shared capacity |
| Fair use | Sustained patterns that degrade other tenants trigger review, not billing |
| Free plan | 2 free models (plugsky-micro and plugsky-lite), no card required |
| Enterprise | Committed capacity and negotiated limits for predictable heavy usage |
| Visibility | Usage analytics per key and rate-limit response headers |
| Product status | Chat, streaming, JSON mode, function calling, embeddings and RAG are live |
TL;DR
- Unlimited means no token meters or overage fees, not infinite concurrency.
- RPM, TPM and concurrency caps are the real constraints on any shared API.
- Fair use targets abuse and sustained monopolisation of shared capacity.
- Usage analytics and limit headers show exactly where you stand.
- Heavy, predictable workloads belong on enterprise committed capacity.
How it works, step by step
- Read your plan's documented RPM, TPM and concurrency limits before launch.
- Track 429 rate and p95 latency per key in your monitoring.
- Measure peak requests and tokens per minute from usage analytics.
- Keep client concurrency below the cap so retries have headroom.
- Implement backoff with jitter and cap retries at three to five attempts.
- Contact the team when sustained peaks approach the documented limits.
- Move heavy scheduled work off peak or to enterprise committed capacity.
Try it yourself
Open the rate limit calculator →
What unlimited actually includes
Unlimited refers to the billing model: on self-serve plans there are no token meters, no per-token charges and no overage fees. You are not billed more because a prompt grew, a retry fired or an agent loop ran an extra step.
It does not mean infinite throughput. Every shared inference platform enforces RPM, TPM and concurrency limits because GPUs serve a finite number of sequences. Those limits exist so one workload cannot degrade everyone else's latency.
What fair use means in practice
Fair use is the boundary between normal production traffic and patterns that would harm other tenants. It is not a hidden token allowance.
- Normal traffic: steady API usage from an application, including peaks around launches, runs without intervention.
- Review territory: continuous saturation at the concurrency ceiling, automated scraping loops, or workloads that look like resale of capacity.
- Enterprise territory: sustained high volume that needs guaranteed capacity and negotiated limits.
The response to review is a conversation and rate limiting, not a surprise invoice.
How to check whether you are within fair use
- Open usage analytics and look at peak RPM, TPM and error rate per key.
- Compare peaks with the documented plan limits.
- Check response headers on a sample request to see current limit values.
- Compute headroom: limit divided by peak. Below 1.5x, plan a change.
- Correlate 429 spikes with deploys — retry storms often look like traffic growth.
The rate limit calculator turns those measurements into a headroom number you can track over time.
When to move to enterprise
Choose enterprise terms when you need guaranteed capacity rather than best-effort fair use: sustained high concurrency, contractual throughput, dedicated regions, VPC, on-prem or air-gapped deployment, and a published SLA. Committed capacity turns a shared fair-use boundary into a specified number in your contract.
For most products, self-serve fair use is the right home for years. The signal to move is simple: you are planning launches around rate limits instead of product milestones.
Honest comparison
| Question | Plugsky self-serve | Typical metered API | Plugsky enterprise |
|---|---|---|---|
| Token billing | None — unlimited fair use | Per input and output token | Committed capacity |
| Overage fees | None | Common above quota | Negotiated true-up terms |
| Throughput limits | Documented RPM, TPM, concurrency | Quota-based or spend-based | Negotiated and guaranteed |
| Behaviour when exceeded | Rate limited with 429 backpressure | Bill grows or requests fail | Scales within committed capacity |
| Capacity guarantee | Best effort under fair use | Varies | Contractual with SLA |
| Best fit | Production apps with normal traffic | Low or spiky usage | Sustained heavy workloads |
Frequently asked questions
Is unlimited usage really unlimited on Plugsky?
It is unlimited under fair use: no token meters, per-token charges or overage fees on self-serve plans. RPM, TPM and concurrency limits still apply to protect shared capacity.
What triggers a fair-use review?
Sustained saturation of rate limits, automated loops that monopolise capacity, or patterns consistent with reselling access. Normal application traffic, including launch peaks, does not trigger review.
Will I get a surprise bill for heavy usage?
No. There are no per-token charges or overage fees on self-serve plans. The failure mode for extreme usage is backpressure and a conversation about enterprise capacity, not an invoice.
How do I see my current rate limits?
Plan limits are documented in the docs, usage analytics show requests, tokens and errors per key, and API responses include rate-limit headers with current values.
What is the difference between fair use and a quota?
A quota is a hard allowance that stops or bills you. Fair use is a behavioural boundary: normal traffic flows, and only patterns that harm other tenants get throttled or reviewed.
When should I move to an enterprise plan?
When you need guaranteed throughput, committed capacity, a contractual SLA or sovereign deployment options. If you are timing launches around rate limits, that is the signal.
Does fair use apply to the free plan too?
Yes. The free plan includes two models with fair-use limits and no card. Paid self-serve plans raise limits while keeping the same no-per-token model.
Do retries count against my limits?
Yes. Retries consume rate-limit budget even though they carry no per-token charge on self-serve plans, which is why backoff with jitter and retry ceilings matter.