Key facts
| API compatibility | Drop-in /v1/chat/completions with streaming, JSON mode and function calling (live) |
| Structured extraction | JSON mode for clause type, position and risk flags |
| Models | 30+ models behind one endpoint, route extraction and synthesis separately |
| Migration | Base URL and model-name change; document pipeline unchanged |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| Controls | Scoped keys, RBAC, SSO/SCIM and SIEM-exportable audit logs |
| Residency | 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 your legal tech stack; change the base URL and model names.
- Use JSON mode for clause extraction so reviews compare structured records.
- Wrap comparisons and calculations in tools rather than trusting free text.
- Keep output labelled as a draft and route every matter through lawyer review.
- Validate on closed matters before any live traffic touches client files.
How it works, step by step
- Centralise the model client so base URL, key and model names are configuration.
- Define JSON schemas for each extraction task — clause type, position, obligation, risk flag, source paragraph.
- Set the base URL to https://api.plugsky.com/v1 with a team-scoped key and map model names per task.
- Run the pipeline on closed matters and diff structured extractions against lawyer-reviewed results.
- Add reviewer gates in the interface so every output is accepted, edited or rejected with a reason.
- Switch live traffic behind a flag and keep the previous provider path for rollback.
- Review retention, key scopes and residency with risk and compliance before expanding practice areas.
Try it yourself
Open the function calling schema generator →
What legal teams can standardise on
Legal technology stacks are heterogeneous and slow to change, which makes compatibility valuable. An OpenAI-shaped endpoint slots into existing integrations without new SDKs: summarise a memo, compare two drafts, answer a question over an agreement or extract clause data. Streaming, JSON mode and function calling are live, covering the operations legal tooling actually needs.
Managed conveniences are on the way rather than available now: files, batch, fine-tuning and assistants-style endpoints are coming soon. Until then, document storage, bulk processing and conversation state stay in your own systems — usually the preferred arrangement for privileged material anyway.
Structured extraction for contracts
Free-text answers are hard to review at volume; structured records are easy. Define a schema per document type — clause type, position taken, obligations, dates, risk flags and the source paragraph — and require JSON output. Reviewers then scan a table rather than reread the contract, and quality can be measured field by field.
- Schema versioning: treat extraction schemas as code and version them alongside prompts.
- Validation: reject records with missing or out-of-range fields instead of repairing them silently.
- Provenance: require the source paragraph in every record so reviewers can verify in context.
- Calculations: dates, notice periods and monetary totals belong in tools, not model arithmetic.
Confidentiality, keys and review
Confidentiality requirements shape deployment. Use team-scoped keys with least privilege, avoid sending full documents when a clause suffices, and log each request with enough metadata for an audit without duplicating privileged content into logs. Pin the workspace to a region-locked plane, or run VPC, on-prem or air-gapped when client files cannot leave the firm's environment.
Roll out on closed matters first: compare structured extractions and drafts against lawyer-reviewed results, and track acceptance, edit and rejection rates. Because the API is OpenAI-compatible and the base URL lives in configuration, rollback is a deploy. Expand practice area by practice area, and keep the human sign-off explicit in every workflow.
Honest comparison
| Aspect | Plugsky | Staying on OpenAI | Point legal AI tool |
|---|---|---|---|
| Client change | Base URL and model names only | None | New vendor integration |
| Structured output | JSON mode for clause records | Available | Vendor-defined schema |
| Model choice | 30+ models behind one endpoint | OpenAI catalogue only | Fixed model |
| Pricing | Flat monthly with unlimited fair use on self-serve | Per-token | Seat or matter pricing |
| Residency | Region choice, VPC, on-prem, air-gapped | Limited options | Usually cloud-only |
Frequently asked questions
Will our existing legal tech integration work?
If it uses OpenAI-style chat completions, yes — change the base URL and model names. Request and response shapes stay compatible, so parsing and retry logic carry over.
Is JSON mode suitable for clause extraction?
Yes, and it is the recommended pattern. Extract into a versioned schema with a source paragraph field, validate every record and reject malformed output rather than repairing it.
Can the assistant calculate dates and notice periods?
Put calculations in tools and let the model call them. Deterministic code is auditable; arithmetic inside the model is neither verifiable nor reliable enough for contracts.
Does it replace lawyer review?
No. The assistant prepares, extracts and drafts; qualified lawyers review and own the advice. Every output should be labelled a draft for verification.
How do we protect privileged material?
Scope keys per team, send only needed passages, keep documents in your systems, and pin deployment to a region or run on-prem where privilege rules require it.
What is coming for document-heavy workflows?
Files, batch, fine-tuning and assistants-style endpoints are coming soon. For now, keep bulk document processing in your own pipeline and use the live chat endpoint.
How do we start?
Use the free plan's plugsky-micro and plugsky-lite models with no card on closed matters, validate structured output, then move to a paid plan or the 14-day full-access trial.