Key facts
| Tool type | Free pricing and plan tracker plus comparison worksheet guidance |
| Worksheet dimensions | Pricing model, models, compatibility, residency, security, SLA, migration, exit |
| Evidence rule | Every score points to a document: docs page, contract term or test result |
| Pricing model options | Flat monthly self-serve plans; per-token usage; committed enterprise agreements |
| Compliance inputs | Terms, SLA, DPA and status page |
| Models | 30+ models from free to frontier tiers |
| Free plan | 2 free AI models (plugsky-micro, plugsky-lite), no card required |
| Product status | Live |
TL;DR
- Score the pricing model, not just the price: per-token, flat and committed plans behave differently.
- Attach evidence to every score so discussions end with documents, not opinions.
- Run security and residency as pass/fail filters before commercial scoring.
- Include the exit plan: portability, data export and contract termination terms.
- Refresh the worksheet when plans or catalogues change — it is a living document.
How it works, step by step
- List the workloads you are buying for and their volume, latency and quality requirements.
- Define pass/fail gates first: residency, security certifications, DPA terms and SLA.
- Score each surviving vendor on pricing model, model coverage and API compatibility.
- Record migration effort and rollback options, with the exact changes required.
- Attach evidence links to every score so reviewers can verify claims.
- Have security and procurement review the same sheet instead of separate documents.
- Set a review date and refresh plan structures with the pricing tracker each quarter.
Try it yourself
Open the AI API pricing tracker →
The dimensions that actually matter
A worksheet earns its keep by separating gates from trade-offs. Residency, security controls, DPA terms and SLA are gates: if a vendor fails one, stop scoring. Everything else is a trade-off scored with evidence — API compatibility (is your code a base-URL change or a rewrite?), model coverage (how many of your workloads fit one vendor?), pricing model (per-token, flat monthly or committed?), support terms and migration effort. Add an exit row: how easily can you leave, and does the contract allow it?
Scoring without fooling yourself
Use a small scale, define what each number means, and require a link or quote for every score. "Pricing predictability: 4" means nothing; "flat monthly self-serve plan, no overage on fair use, see pricing page" can be checked. Score from the buyer's workload, not from feature lists: a capability you will never call is worth zero. Where a vendor does not yet offer something — for Plugsky, audio, image, moderation, file, batch and fine-tuning endpoints are roadmap items — write that in the cell rather than leaving it blank, so the gap is visible to decision-makers.
Keeping the worksheet current
Vendor pages change: models are added, plan structures shift and limits are adjusted. A worksheet reviewed once and filed away is a liability. The pricing tracker keeps plan structures and changes in view, and the same pattern works for capability matrices in the docs. Assign an owner, review quarterly, and re-score immediately when a vendor announces a material change. The worksheet is also your onboarding document — the engineering team can read exactly which capabilities were contracted, which are roadmap, and what "done" means for the migration.
Honest comparison
| Dimension | What good looks like | Red flag | Evidence to collect |
|---|---|---|---|
| Pricing model | Predictable, documented, no surprise overages | Estimates only, no published structure | Pricing page, contract terms |
| Model coverage | Enough models to cover your workloads behind one API | Each workload needs a different vendor SDK | Model catalogue, capability matrix |
| API compatibility | Drop-in base URL change for existing code | Proprietary API with no migration path | Quickstart docs, migration guide |
| Residency and security | Region choice, audit logs, SSO, clear DPA | Vague data handling answers | DPA, security page, SLA |
| Migration effort | Measured in days with a rollback plan | "Rewrite required" with no estimate | Pilot results on real prompts |
| Exit plan | Data export and termination terms in writing | No portability terms | Contract, data export docs |
Frequently asked questions
What should a vendor comparison worksheet include?
Pass/fail gates first (residency, security, DPA, SLA), then scored trade-offs: pricing model, model coverage, API compatibility, support and migration effort, plus an exit plan.
How is this different from a feature checklist?
A checklist counts features. A worksheet scores your workloads against evidence, so unused capabilities do not influence the decision.
Who should own the worksheet?
One owner — usually platform or procurement — with engineering and security contributing scores in their areas and reviewing the final sheet.
How do I score pricing without hard-coding prices?
Score the model, not the number: flat monthly self-serve, per-token usage or committed enterprise agreement, and link the live pricing page as evidence.
What about roadmap features?
Mark them explicitly as roadmap with a review date. Do not score them as available, and do not let them block a decision they are not part of.
How often should it be reviewed?
Quarterly at minimum, and immediately after any material vendor change such as a plan restructure or a new model family.
Does Plugsky have a DPA and SLA?
Yes. Review the legal pages for current terms, SLA commitments and the status page for live component health.
Can the worksheet cover self-hosting?
Yes. Add a column for total cost of ownership including GPUs, operations and utilization, and compare it against managed plans.