Key facts
| Integration | One OpenAI-compatible endpoint behind your service layer |
| Tenancy | Per-tenant keys and quotas for metering, isolation and BYOK upsell |
| Model routing | 30+ models behind one endpoint; route light steps to plugsky-micro or plugsky-lite |
| Reliability | Streaming, JSON mode and function calling are live; plan retries and fallbacks in your loop |
| Cost model | Flat monthly plans with unlimited fair-use usage on self-serve; see the live pricing page |
| Residency | Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) |
| Audit | Usage analytics per key and SIEM-exportable events for enterprise customers |
| Endpoint status | Chat completions is live; assistants and responses endpoints are coming soon |
TL;DR
- Keep one integration and vary tenancy at the key and quota layer.
- Route classification and extraction to cheap models, reserve frontier tiers for hard steps.
- Run agent evals in CI so prompt changes ship with evidence.
- Flat-plan pricing keeps gross margin stable as usage grows.
- Ship on live chat completions; assistants-style endpoints are still roadmap items.
How it works, step by step
- Choose a feature where an agent adds clear value — onboarding assistance, data cleanup, report drafting or in-product search.
- Wrap the OpenAI-compatible endpoint in your own service so tenant context, authorisation and quotas are enforced in one place.
- Issue per-tenant keys or quotas and record usage against the tenant for metering and plan enforcement.
- Expose your own APIs as tools with strict schemas, and require tenant-scoped authorisation on every call.
- Route each step: small models for classification and extraction, larger models for planning and synthesis.
- Add streaming for responsive UX, plus retries, timeouts and a fallback model per step.
- Run an evaluation suite in CI covering tool selection, refusal behaviour and tenant isolation before each release.
Try it yourself
Open the best model for agents selector →
Embedding agents without breaking tenancy
The agent is a feature of your product, so it must obey the same rules as the rest of your product: tenant resolution, authorisation, quotas and audit. Put the model call behind your service layer and treat the OpenAI-compatible endpoint as an internal dependency. Tools are your own APIs, called with the requesting tenant's identity — never a shared super-user.
Per-tenant keys give you the scaffolding for metering, fair-use limits and, for larger customers, a bring-your-own-key option on encryption. That keeps a single codebase serving every tier while the commercial boundaries stay configurable.
Unit economics that survive success
Agent features get used more than forecasts expect, so cost control belongs in the architecture. Route routine steps — intent detection, field extraction, classification — to plugsky-micro or plugsky-lite, and reserve plugsky-pro or frontier models for steps where quality changes the outcome. Cache deterministic lookups, cap loop iterations, and set per-tenant budgets.
- Measure per tenant: key-level analytics reveal which customers are unprofitable before renewal.
- Degrade gracefully: define fallback models and timeouts so a capacity squeeze becomes slower answers, not errors.
- Price the feature, not tokens: flat monthly plans with fair-use usage keep margin stable; check the live pricing page for current plans.
Shipping safely and iterating fast
Prompt changes are product changes. Keep prompts, tool schemas and evaluation sets in version control, and gate releases on tests for tool selection, refusal correctness and tenant isolation. A regression here is a customer-visible bug, not an internal quality dip.
Instrument every run with tenant, feature, model alias and latency, and feed failures back into the evaluation set. The 30+ model catalogue makes experimentation cheap: when a new model looks better for one step, change an alias, rerun the suite, and ship if it wins.
Honest comparison
| SaaS concern | Plugsky | Typical model API | Building in-house |
|---|---|---|---|
| Tenancy controls | Per-tenant keys, quotas and usage analytics | Single account key | You build metering |
| Cost model | Flat monthly with fair-use usage | Per-token billing | GPU and ops |
| Model choice | 30+ models behind one endpoint | One vendor catalogue | You serve each model |
| Model routing | Change an alias to switch tier | Per-provider code paths | Your own router |
| Residency | Region-locked planes plus VPC and on-prem tiers | Few region choices | Wherever you deploy |
| Portability | OpenAI-compatible; change base URL | Vendor-specific APIs | Full control |
Frequently asked questions
How do we keep one tenant from exhausting capacity?
Use per-tenant keys with quotas and budgets, cap agent loop iterations, and route heavy but simple steps to smaller models. Key-level analytics show who is consuming what.
Should agents call our APIs directly?
Only through your service layer with tenant-scoped authorisation. The model proposes tool calls; your platform decides whether the tenant may execute them.
How do we handle model upgrades?
Treat the model alias as configuration, keep an evaluation suite in CI, and roll changes behind a feature flag so you can compare and revert quickly.
What does streaming cost us in complexity?
Little. Streaming is supported on the same endpoint; assemble tool_call deltas for server-side execution while tokens stream to the client for responsiveness.
Can enterprise customers bring their own keys?
Yes — customer-managed encryption keys are supported on enterprise plans, which is a common ask in security reviews.
How predictable is cost?
Self-serve plans are flat monthly with unlimited fair-use usage, so your delivery cost does not scale linearly with conversations. Check the live pricing page for current plan details.
Can we start before a paid commitment?
Yes. The free plan includes plugsky-micro and plugsky-lite with no card, and a 14-day full-access trial exists for heavier load testing.