Key facts
| API compatibility | Drop-in base URL change for /v1/chat/completions and /v1/embeddings |
| Embeddings | plugsky-embed and plugsky-embed-multilingual (live) |
| Chat features | Streaming, JSON mode and function calling (live) |
| Models | 30+ models behind one API, from free tiers to frontier |
| Migration effort | One line for the client, plus a re-embedding run for your corpus |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| Free tier | plugsky-micro and plugsky-lite, no card required |
| Deployment | Plugsky cloud, your VPC, on-prem or air-gapped |
TL;DR
- Keep the OpenAI SDK — change base_url and model IDs, and leave the RAG logic untouched.
- Chat and embeddings are both live, so one endpoint covers retrieval and generation.
- Switching embedding providers means re-embedding the corpus; vectors are model-specific.
- JSON mode gives you structured citations or answer objects without parsing prose.
- Start on the free plan, validate quality on your own documents, then scale.
How it works, step by step
- Record your current embedding model and dimensions — you will need to re-embed the whole corpus against the new provider.
- Set the client base URL to https://api.plugsky.com/v1 and store a Plugsky API key in your existing secrets manager.
- Map model names: keep your generation model pinned to a Plugsky chat model and the embedding model to plugsky-embed or plugsky-embed-multilingual.
- Re-embed all chunks and write them to a new vector collection so both old and new indexes exist side by side.
- Run your existing test suite and a golden question set against the new collection; compare retrieval recall and answer quality before switching traffic.
- Update the answer prompt to use JSON mode for citations, then cut traffic over and monitor usage in the dashboard.
- Keep the base URL in configuration so rollback is a deploy, not a code change.
Try it yourself
Open the OpenAI-compatible API tester →
What OpenAI compatibility actually covers
Compatibility is defined by endpoints and parameters, not by branding. Plugsky exposes /v1/chat/completions and /v1/embeddings in OpenAI format, with streaming, JSON mode and function calling live today. That means the same client library, the same request shapes and the same response objects you already parse.
Some specialist endpoints on the roadmap — audio, images, files, batch, fine-tuning, assistants and responses — are coming soon, so document Q&A built on chat plus embeddings is fully supported while those adjacent workflows should stay on your current provider until they ship.
A drop-in migration for a doc Q&A service
For a typical service the migration is a configuration change in one place and a backfill job in another. Create the new client with the Plugsky base URL, then run a batch job that re-embeds every chunk with plugsky-embed into a fresh collection — vectors from different models are not interchangeable, so never mix them in one index.
client = OpenAI(base_url="https://api.plugsky.com/v1", api_key=key)
emb = client.embeddings.create(model="plugsky-embed", input=chunks)
ans = client.chat.completions.create(model="plugsky-pro", messages=msgs)Retrieval, ranking and prompting code stays as it is. Only the client construction and two model strings change.
What to verify before cutover
Run both stacks in parallel on real questions and compare three things: retrieval recall (does the right chunk come back), citation accuracy (does the answer point at the right source) and refusal behaviour (does it decline when the corpus lacks the answer). These degrade silently, so measure them rather than trusting spot checks.
Also confirm operations: usage dashboards, key scoping per environment, and whether your data must stay in a specific region. Plugsky supports region selection plus VPC, on-prem and air-gapped deployment when residency rules demand it, so the same code can move from a pilot to a regulated deployment without a rewrite.
Honest comparison
| Step | Plugsky | Staying on OpenAI | Hosting an open model |
|---|---|---|---|
| Client change | Base URL plus model names | None | Full rewrite to a new stack |
| Embeddings | plugsky-embed, OpenAI-shaped endpoint | Existing model | You run the embedding server |
| Generation | 30+ models behind one endpoint | OpenAI catalogue only | One model per deployment |
| Pricing model | Flat monthly with unlimited fair use on self-serve | Per-token | GPU plus operations cost |
| Rollback | Change the base URL back | N/A | Redeploy and retune |
Frequently asked questions
Do I need to change my RAG code?
No. If you already build chunks, store vectors and assemble prompts, only the client base URL and the model names change. Retrieval and prompting logic is provider-agnostic.
Why must I re-embed my documents?
Embedding vectors are specific to the model that produced them. Mixing vectors from two models in one index breaks similarity search, so re-embed the corpus into a new collection.
Does JSON mode work for citations?
Yes — JSON mode is live. You can request a structured answer object with an answer field and a sources array, then render citations without parsing prose.
Is streaming supported?
Yes. Streaming is live on chat completions, so document answers can render token by token in your interface.
Can I use my existing vector database?
Yes. Plugsky returns standard embedding vectors; any vector store or pgvector index that accepts float arrays works. You only change the embedding call.
What about files and batch endpoints?
Files and batch are coming soon. Until then, keep document ingestion in your own pipeline and send text chunks to the embeddings endpoint.
How do I compare cost before migrating?
Model your current per-token spend against Plugsky's flat plans using the live pricing page, then validate on your real document volume during the free plan or the 14-day full-access trial.