Key facts
| API compatibility | OpenAI-compatible chat and embeddings |
| Request path | Plugsky serves its own catalogue directly |
| Authentication | One Plugsky API key tied to your plan |
| Billing model | Flat monthly self-serve plans; free plan with two models |
| Routing | Model choice per request |
| Operations | None beyond your application |
| Private deployment | Cloud, VPC, on-prem, air-gapped |
| Feature status | Chat, streaming, JSON mode, function calling and embeddings live |
TL;DR
- Both APIs accept the same OpenAI-style requests, so client code barely changes.
- A LiteLLM proxy keeps you on provider keys and per-token provider billing.
- Plugsky replaces that layer with a managed catalogue and flat monthly plans.
- Choose the gateway for provider flexibility; choose the managed API for less ops.
- Verify tools, JSON mode and streaming per model after any switch.
How it works, step by step
- Inventory the endpoints and model aliases your clients call through the gateway.
- Confirm which can be served by Plugsky today and which must stay on provider keys.
- Point a staging environment at the Plugsky base URL with a test key.
- Rewrite model aliases to Plugsky model names and keep them environment-driven.
- Run compatibility tests for streaming, function calling, JSON mode and embeddings.
- Compare quality and latency per workload, then cut over endpoints that pass.
Try it yourself
Open the OpenAI-compatible API tester →
The API surfaces side by side
For most application code the two are interchangeable. Both accept chat completions requests with messages, streaming and tool definitions, and both expose an embeddings path, so an OpenAI SDK client mostly needs a new base URL and key.
The differences appear in model naming and metadata. Plugsky models are named in the platform catalogue, while a LiteLLM proxy typically uses provider-qualified names. Audit any place where your code parses model names, usage fields or provider headers before switching.
Keys, billing and the layer you own
A LiteLLM proxy concentrates every provider credential in one service, which is convenient for control and risky for security: key leakage or a proxy compromise exposes all connected accounts. The billing that follows those keys is per token at each provider, usually on separate invoices.
Plugsky reverses that arrangement. One key, one plan, one endpoint, and no provider credentials in your stack. Self-serve plans are flat monthly with unlimited fair use on paid tiers, and the free plan covers plugsky-micro and plugsky-lite; see the live pricing page for current plans. What you give up is the ability to keep traffic on specific provider accounts and cloud credits.
A migration that stays reversible
Keep the switch reversible by leaving the base URL and model alias in configuration rather than hard-coding them. Move one endpoint at a time, starting with the least critical workload, and keep the gateway running in parallel until the new path has passed your tests.
Pay attention to features that vary by model rather than by platform: context limits, function calling reliability, JSON mode and streaming behaviour. Testing one model does not prove another, so repeat the checks for every model you plan to run in production.
Honest comparison
| Dimension | Plugsky | LiteLLM proxy | What to verify |
|---|---|---|---|
| Request format | OpenAI-compatible | OpenAI-compatible | Model naming and usage fields |
| Model access | 30+ managed models | Providers you connect | Coverage of the models you use |
| Credentials | One Plugsky key | All provider keys in the proxy | Key rotation and secret storage |
| Billing | Flat monthly plans | Per-token at each provider | Cost at your real volume |
| Routing | Model choice per request | Fallbacks, retries and budgets | Retry and timeout semantics |
| Deployment | Cloud, VPC, on-prem, air-gapped | Wherever you host containers | Data path and residency |
Frequently asked questions
Can I switch from a LiteLLM proxy to Plugsky without rewriting code?
Usually yes. Both are OpenAI-compatible, so you change the base URL, replace the key and map model names. Re-run your tests because feature support varies by model.
Does Plugsky support provider fallbacks?
No. Plugsky serves its own catalogue rather than routing to third-party keys, so cross-provider fallback is not part of the managed API. Keep a gateway if you need that.
Which is cheaper?
It depends on your mix. A gateway on top of per-token providers scales with usage, while Plugsky self-serve plans are flat monthly. Estimate at your real volume and compare with the live pricing page.
Do I still need LiteLLM if I use Plugsky?
Only if you must keep some providers on your own keys, for example to use cloud commitments. Then run the gateway for those and Plugsky for everything else.
Is the Plugsky API OpenAI-compatible for embeddings too?
Yes. Chat completions and embeddings are available through OpenAI-compatible endpoints; check the docs for the current model and parameter matrix.
How do I test compatibility quickly?
Send chat, streaming and tool calls to the endpoint with the OpenAI-compatible API tester, then run the same payloads through your own test suite.
What about streaming, JSON mode and function calling?
These are live on Plugsky for supported models. Confirm the specific model you plan to use, since capabilities differ across the catalogue.