Key facts
| Flat-rate model | Fixed monthly plan; unlimited fair-use usage; no token meters on self-serve |
| Per-token model | Separate input and output token rates; bill scales with usage |
| Overage | None on Plugsky self-serve plans |
| Throughput constraint | RPM, TPM and concurrency limits instead of token meters |
| Model access | 30+ models under one flat plan on self-serve |
| Free plan | 2 free models (plugsky-micro and plugsky-lite), no card required |
| Best-fit workloads | Flat for steady production; per-token for low or bursty usage |
| Product status | Chat, streaming, JSON mode, function calling, embeddings and RAG are live |
TL;DR
- Flat-rate: fixed cost, fair-use limits, no token meters.
- Per-token: exact cost matching, more variance, more forecasting work.
- Flat-rate wins on steady production traffic; per-token wins on spiky or low volume.
- Agents and retry-heavy flows favour flat-rate because calls multiply.
- Both are available with the same OpenAI-compatible API on Plugsky.
How it works, step by step
- Measure monthly input and output tokens from production telemetry.
- Price those tokens at current published rates to get metered equivalent spend.
- Compare with the flat plan that covers your usage with headroom.
- Assess utilisation: steady daily traffic or short bursts?
- Model a 2x traffic month under both pricing shapes.
- Include retries, evals and re-embedding in the per-token estimate.
- Pick the shape that keeps cost predictable at your expected scale.
Try it yourself
Open the LLM cost calculator →
How each model prices a request
Per-token billing splits every call into input and output tokens and applies a rate to each, so a long prompt, a verbose completion or a retry all add to the bill. Flat-rate billing charges a monthly plan and governs usage with fair-use rate limits, so the same request costs nothing extra.
The difference compounds in multi-step workloads. A chat turn is one call; an agent task may be ten. Under per-token pricing that multiplier lands on the invoice; under flat-rate it lands on throughput.
Cost behaviour as you scale
- Per-token: cost grows linearly with usage. A successful launch doubles traffic and doubles the bill, often before revenue catches up.
- Flat-rate: cost stays fixed within fair use. Growth consumes more throughput headroom rather than more budget, and enterprise committed capacity handles sustained high volume.
Linear cost is not inherently bad — it matches spend to value and keeps low-volume periods cheap. The problem is forecast variance, which is why finance teams often prefer the fixed line.
Where each model wins
Flat-rate wins for steady SaaS traffic, agent loops, prompt-heavy products and any team that values budget certainty over marginal savings. It also removes the incentive to under-serve users to protect a token budget.
Per-token wins for prototypes, seasonal workloads, one-off backfills and low-volume products where a monthly plan would sit idle. It is also the natural model for pass-through reselling of a specific model.
Plugsky self-serve plans are flat-rate with unlimited fair-use usage, and the same OpenAI-compatible API also supports metered evaluation through the free plan and trial.
How to run the comparison on your numbers
- Log tokens per request and requests per month for each workload.
- Apply the live rates from the pricing page to get metered spend.
- Add measured retry and evaluation overhead.
- Compare with the flat plan that covers peak usage with 1.5x headroom.
- Stress both with a doubling of traffic and a prompt change.
The cost calculator runs this arithmetic. Revisit the result quarterly — usage patterns change faster than pricing pages.
Honest comparison
| Dimension | Flat-rate (Plugsky self-serve) | Per-token pricing | Notes |
|---|---|---|---|
| Monthly cost | Fixed plan price | Varies with tokens | Flat favours steady usage |
| Input vs output | Not metered on self-serve | Priced separately, output usually higher | Output-heavy apps feel per-token most |
| Overage fees | None | Common above quota | Flat removes true-up risk |
| Retries and loops | No marginal token charge | Billed when they reach the model | Agents amplify the gap |
| Forecasting | One fixed line plus user growth | Requires token forecasting | Flat shortens approval cycles |
| Best fit | Steady production workloads | Low, spiky or experimental usage | Match the shape to the workload |
Frequently asked questions
Is flat-rate cheaper than per-token pricing?
It depends on volume and utilisation. Flat-rate is cheaper when metered spend at your volume exceeds the plan price and traffic keeps the plan busy. Per-token is cheaper for low or spiky usage.
Does Plugsky charge per token?
No. Self-serve plans are flat monthly with unlimited fair-use usage, and there are no per-token charges or overage fees. See the live pricing page for current plans.
What limits apply on a flat plan?
RPM, TPM and concurrency limits protect shared capacity. They govern throughput rather than billing, so extreme usage leads to backpressure and a conversation about enterprise capacity, not a larger invoice.
Why do output tokens cost more on per-token plans?
Generating text is sequential and compute-intensive while prompts process in parallel. Providers reflect that in their rates, which is why output-heavy products feel per-token pricing most.
Are agents better on flat-rate pricing?
Usually yes. Agent tasks involve planning, tool calls and retries that multiply model invocations. Flat-rate makes those internal steps free at the margin, so engineering optimises quality instead of token count.
Can I start per-token and switch to flat-rate?
Yes. Plugsky keeps an OpenAI-compatible API, so the migration is a plan change plus a base URL and model configuration — not a rewrite of your application.
How do I forecast a per-token bill?
Build a driver tree of users, sessions, requests and tokens per request, then apply current rates. Add retries and evaluation runs. Flat-rate replaces that tree with a fixed plan plus user growth.
Which model should a startup choose?
Start on the free plan to measure real usage, then compare. Early-stage products with low volume often stay on metered access; once traffic is steady, flat-rate usually wins on predictability.