Key facts
| API compatibility | Drop-in /v1/chat/completions with streaming, JSON mode and function calling (live) |
| Long context | plugsky-longctx for multi-document synthesis (live) |
| Evidence output | JSON mode for claim, source ID and confidence rows |
| Models | 30+ models behind one endpoint, route per stage |
| Migration | Base URL and model-name change; tool code stays as it is |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| Deployment | Region-locked planes, VPC, on-prem and air-gapped options |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Keep the SDK; change the base URL and model names for each research stage.
- Use JSON mode for evidence tables so claims stay machine-checkable.
- Reserve long-context models for synthesis, small models for extraction.
- Cap planning, tool calls and elapsed time so runs terminate predictably.
- Shadow-run against your current provider on the same research questions.
How it works, step by step
- Centralise the model client so base URL, key and model names are configuration per stage.
- Define JSON schemas for evidence rows — claim, source ID, quoted span, confidence — and validate them.
- Set the base URL to https://api.plugsky.com/v1 with scoped keys, mapping planning, extraction and synthesis to different models.
- Keep gather tools unchanged; they already return the sources your pipeline needs.
- Add budgets for sub-questions, tool calls and elapsed time, and a verification pass over claims.
- Shadow-run on a fixed question set and compare coverage, citation accuracy and latency with the current provider.
- Cut over behind a flag, keep rollback in configuration, and monitor traces per stage.
Try it yourself
Open the context window comparison →
Compatibility for research pipelines
Research agents are orchestration around model calls, which makes them a natural fit for a compatible endpoint. Planning, extraction, verification and synthesis are all chat completions with different prompts and models; gathering runs through your own tools. One client covers every stage, so a provider change is configuration plus a validation run.
Plugsky keeps chat completions, streaming, JSON mode and function calling live. Managed conveniences such as batch and assistants-style endpoints are coming soon, so scheduling and run state stay in your orchestration layer — a reasonable place for budgets and retries regardless of provider.
Evidence tables and long-context synthesis
The most useful structure in a research pipeline is the evidence table. Ask extraction steps for JSON rows containing the claim, source ID, quoted span and a confidence value, then validate before synthesis. Structured evidence makes verification mechanical and prevents the writing stage from inventing support.
- Quoted spans: keep the exact sentence so reviewers can verify without opening the source.
- Deduplication: collapse repeated claims across sources before synthesis.
- Conflict handling: represent disagreement explicitly rather than merging it.
- Long context: use plugsky-longctx when many evidence rows must be weighed together.
Provenance and rollout
Every claim in the final brief should trace to an evidence row, and every evidence row to a gathered source. Keep those mappings in the output object, not just in prose, so reviewers and downstream systems can audit the result. Traces per stage — plan, gather, extract, synthesise — let you attribute quality problems precisely.
Roll out on a fixed question set with known answers and analyst review, then compare against your current provider on coverage, citation accuracy and latency. Because the API is OpenAI-compatible and stage models live in configuration, tuning or rolling back is a deploy. For restricted sources, pin the workspace to a region-locked plane or run VPC, on-prem or air-gapped with the same client code.
Honest comparison
| Stage | Plugsky | Staying on OpenAI | Self-hosted |
|---|---|---|---|
| Planning | Small models via one client | Same pattern | Serving stack to operate |
| Extraction | JSON mode evidence rows | Available | Built by you |
| Synthesis | Long-context models (live) | Available | GPU-bound |
| Migration | Base URL and model names | None | Rewrite |
| Pricing | Flat monthly with unlimited fair use on self-serve | Per-token | GPU and ops cost |
Frequently asked questions
Do research tools need changes?
No. Your gather tools keep returning sources; only the model client configuration changes. Tool schemas and orchestration logic stay as they are.
Why use JSON mode for evidence?
Structured rows make verification mechanical and prevent synthesis from inventing support. You can validate every row and reject malformed ones instead of trusting prose.
When is a long-context model necessary?
When synthesis must weigh many sources at once, such as comparing findings across dozens of documents. For shorter briefs, smaller models with retrieved excerpts are cheaper and equally accurate.
How do we keep runs from spiralling?
Cap sub-questions, tool calls and elapsed time, and require the planner to justify additional work. Budgets are enforced in orchestration code, not requested in prompts.
How should we compare providers?
Run the same research questions through both stacks and compare coverage, citation accuracy and latency. Quality differences matter more than price when pipelines behave differently.
What about batch processing for large corpora?
Batch and files endpoints are coming soon. For now, schedule batches in your own pipeline and call the live chat and embeddings endpoints per item.
Can it run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, so restricted sources can stay inside your network.