Key facts
| Layer | Managed model service |
| API style | OpenAI-compatible |
| Model source | Plugsky catalogue |
| Integration | Any HTTP client; custom base URLs in AI SDK |
| Pricing | Flat monthly self-serve plans |
| Deployment | Cloud, VPC, on-prem, air-gapped |
| Free access | Free plan with plugsky-micro and plugsky-lite |
| Feature status | Chat, streaming, JSON mode, function calling and embeddings live |
TL;DR
- The Gateway routes; Plugsky serves. The layers are complementary.
- Vercel apps get the smoothest path through the Gateway and AI SDK.
- AI SDK applications can point at Plugsky with a custom base URL.
- Migration is usually a base URL and model-name change plus evaluation.
- Keep the Gateway if you rely on Vercel-specific observability and routing.
How it works, step by step
- Identify whether your app uses the AI SDK, raw HTTP or both.
- List the models and gateway features in use, such as fallbacks and usage views.
- Configure the AI SDK to call Plugsky with a custom base URL and model names.
- Run your evaluation set and compare structured output and streaming behaviour.
- Check residency and deployment requirements against both options.
- Move workload by workload, keeping the endpoint configurable.
Try it yourself
Two layers on one request path
A gateway exists so one endpoint can reach many providers with policy in between. The Vercel AI Gateway does that with tight AI SDK integration: model selection, fallbacks and usage views without extra infrastructure. Requests still execute on upstream provider infrastructure under those providers' terms.
Plugsky is the destination rather than the intersection. It runs 30+ models itself, meters usage itself, and answers with a single accountable service. That difference determines what you own: with a gateway you own integration and routing; with a managed platform you buy serving and capacity.
AI SDK integration on both
The AI SDK is provider-agnostic by design. It supports custom OpenAI-compatible base URLs, which means the same application code can call the Gateway or Plugsky by changing configuration. That is the practical test of portability, and it is worth running early.
Plugsky's OpenAI-compatible endpoints cover chat, streaming, tool calls, JSON mode and embeddings, with flat monthly self-serve plans and a free plan covering plugsky-micro and plugsky-lite. Enterprise deployment adds VPC, on-prem and air-gapped options. Current plans are on the live pricing page. If you rely on gateway-only features such as cross-provider fallback or centralised caching, those remain with the Gateway.
Migration and coexistence
Start by measuring. Run a representative workload through both paths and compare latency, output quality, structured-output validity and cost. Because the SDK abstracts the provider, this is a configuration change rather than a rewrite.
Then decide the boundary: frontend product surfaces may stay on the Gateway for convenience, while backend, batch or regulated workloads route to a managed platform with residency guarantees. Keep the base URL and model names in environment configuration, and document which layer owns routing, retries and logs in the final architecture.
Honest comparison
| Dimension | Plugsky | Vercel AI Gateway | What to verify |
|---|---|---|---|
| Role | Serves 30+ models | Routes to upstream providers | Which layer owns serving |
| API compatibility | OpenAI-compatible | OpenAI-compatible gateway | AI SDK custom base URL support |
| Pricing | Flat monthly self-serve plans | Upstream token rates plus gateway policy | Cost at your volume |
| Provider options | Plugsky catalogue only | Many upstream providers | Catalogue requirements |
| Data path | Region choice and private deployment | Vercel plus upstream providers | Residency guarantees |
| Operations | None | None | Who owns retries and logging |
Frequently asked questions
Can I point the Vercel AI SDK at Plugsky?
Yes. The SDK supports custom OpenAI-compatible base URLs, so migration is a configuration change plus model-name mapping and re-testing.
Does Plugsky offer cross-provider fallbacks?
No. Plugsky serves its own catalogue, so provider-level fallback is not part of the service. Keep a gateway if that capability is a requirement.
Is the Gateway a model provider?
No. It routes to upstream providers. Data handling and terms depend on those providers, which is why the Gateway and a managed platform are different buying decisions.
How does pricing differ?
The Gateway passes through upstream token pricing; Plugsky self-serve plans are flat monthly with unlimited fair use on paid tiers. Compare at your real volume.
What happens to observability if I move?
Vercel-native analytics stay with the Gateway. Plugsky provides platform usage views. If cross-vendor analytics matter, keep both or instrument your application.
Can I run both?
Yes, and it is a common pattern: frontend workloads through the Gateway, backend or regulated workloads on a managed endpoint with residency options.
Is there a free way to test Plugsky with AI SDK?
Yes. The free plan includes plugsky-micro and plugsky-lite with no card, and the 14-day full-access trial covers heavier models.