Key facts
| Flat-rate model | Fixed monthly plan with unlimited fair-use usage on self-serve |
| Token-based model | Pay per input and output token, with overage as volume grows |
| Cost variance | Token bills move with prompts, retries and feature launches |
| Break-even | Where measured monthly token spend exceeds the flat plan that covers it |
| Fair use | Unlimited plans are governed by rate limits, not token meters |
| Free plan | 2 free models (plugsky-micro and plugsky-lite), no card required |
| Trial | 14-day full-access trial to measure real usage before choosing |
| Product status | Chat, streaming, JSON mode, function calling, embeddings and RAG are live |
TL;DR
- Flat-rate buys predictability; token-based buys granularity.
- Measure monthly tokens first — the comparison is meaningless without your own volume.
- Flat-rate wins for steady production traffic; token-based wins for rare spikes.
- Prompt changes and retries move token bills but not flat plans.
- Self-serve Plugsky plans have no per-token charges or overage fees.
How it works, step by step
- Log input and output tokens per request for two to four weeks of real traffic.
- Group workloads by pattern: steady chat, batch jobs, agents, embeddings.
- Estimate monthly tokens for each group and apply current published rates.
- Compare that total with the flat plan that covers the same usage.
- Stress the model with a growth scenario — double traffic and a prompt change.
- Choose the model that keeps unit economics stable at your expected scale.
- Revisit quarterly as usage patterns and model mix change.
Try it yourself
Open the LLM cost calculator →
How each pricing model actually behaves
Token-based pricing meters input and output separately, so the bill tracks prompt size, completion length, retries and re-runs. It rewards efficiency and punishes verbosity. Flat-rate pricing charges a fixed monthly amount for unlimited fair-use usage, so the bill tracks the plan, not the prompt. Rate limits replace token meters as the constraint.
The practical difference shows up in month two, when a feature launch doubles traffic: one bill doubles, the other does not. Neither model is inherently fairer; they distribute risk differently.
Finding your break-even with real numbers
Do the arithmetic with your own measurements, never vendor averages:
- Monthly input tokens = requests x average prompt tokens.
- Monthly output tokens = requests x average completion tokens.
- Token spend = (input tokens x input rate) + (output tokens x output rate), using rates from the live pricing page.
- Add measured retry overhead, then compare with the flat plan price.
If token spend is below the flat plan, token-based is cheaper today. If it is consistently above, flat-rate is cheaper and more predictable. The cost calculator runs both sides of the comparison.
When token-based pricing wins
- Low, occasional volume. A side project making a few thousand calls a month rarely justifies a monthly plan.
- Spiky experiments. Fine-tuning runs, evals and one-off backfills are naturally bursty.
- Extreme model diversity. If you need a niche model that only exists on one provider, per-token access may be the only route.
- Cost transparency per feature. Token meters let you attribute spend to a specific endpoint or tenant.
When flat-rate wins
- Steady production traffic. Predictable volume makes a fixed plan cheaper than metered billing at the same level.
- Budget certainty. Finance approves one number instead of a range.
- Prompt iteration. You can improve prompts and context without watching a meter.
- Agents and multi-step flows. Loops multiply calls, which is painful on per-token billing.
- Broad model access. One plan covering 30+ models avoids per-model rate tables.
Plugsky's free plan includes two models with no card, and the 14-day full-access trial lets you measure real usage before choosing a paid plan.
Honest comparison
| Dimension | Flat-rate (Plugsky self-serve) | Token-based pricing | Hybrid committed |
|---|---|---|---|
| Monthly cost | Fixed plan price | Varies with tokens and retries | Commitment plus overage |
| Predictability | High — one line item | Low to medium | Medium |
| Best for | Steady production traffic | Low, spiky or experimental use | Large predictable baselines |
| Prompt iteration | No marginal token charge | Every token change moves the bill | Metered above commitment |
| Scaling behaviour | Covered by fair use; rate limits apply | Cost grows linearly with volume | Overage rates apply |
| Model access | 30+ models under one plan | Priced per model | Negotiated per model |
Frequently asked questions
Which is cheaper, flat-rate or token-based AI pricing?
It depends on your volume and variance. Measure monthly tokens, price them at current published rates, and compare with the flat plan. Steady high usage usually favours flat-rate; low or spiky usage usually favours token-based.
Does flat-rate really mean unlimited?
Self-serve plans are flat monthly with unlimited fair-use usage. Rate limits protect shared capacity, and sustained patterns that would degrade other tenants are throttled rather than billed. Enterprise plans add committed capacity.
Are there overage fees on Plugsky?
No. There are no per-token charges or overage fees on self-serve plans. See the live pricing page for current plan details.
What happens if my usage grows sharply?
On a flat plan, cost stays fixed while rate limits govern throughput, so the risk is backpressure rather than a larger invoice. On token-based pricing, the bill grows with volume.
Can I try both models before deciding?
Yes. Start on the free plan with plugsky-micro and plugsky-lite, then use the 14-day full-access trial to measure real workloads before committing to a paid plan.
Is token-based pricing better for experimentation?
Often yes, because experiments are bursty and short-lived. Per-token access lets you pay only for the calls you make instead of a monthly plan that sits idle between experiments.
How do agents change the comparison?
Agents make many calls per task, including retries and tool loops, which multiplies token consumption. That usually strengthens the case for flat-rate because the marginal cost of each extra step is zero.
How often should we re-evaluate the pricing model?
Quarterly, or after any major feature launch. Token profiles drift with prompt changes, model mix and user behaviour, so a comparison that was true last quarter may not hold.