How do you build code generation with an OpenAI-compatible API?

Key facts

Endpoint	POST https://api.plugsky.com/v1/chat/completions with streaming and JSON mode for code tasks
Compatibility	Same shape as OpenAI; change base_url and model name
Coding models	plugsky-coder and plugsky-coder-fast are in the 30+ model catalogue
Structured edits	JSON mode can return patch instructions that your pipeline applies and verifies
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
Free tier	Free plan with 2 free AI models, no card required
Tools	Function calling lets the model request file reads or test runs from your runner
Roadmap	Fine-tuning and batch endpoints are coming soon

TL;DR

• One API call generates; your pipeline compiles, lints and tests.
• Send interfaces and conventions, not the whole repository.
• Prefer unified diffs or JSON patch objects over full-file rewrites.
• Stream for editors; use JSON mode for automated apply-and-verify pipelines.
• OpenAI compatibility means the SDK, retry and test harness all carry over.

How it works, step by step

1. Change the base URL to Plugsky and confirm an existing code-completion request works unchanged.
2. Build a context assembler that pulls target files, interfaces and conventions under a token budget.
3. Request a unified diff or a JSON patch object rather than a full rewrite.
4. Apply the patch in a sandbox and run the compiler, linter and tests.
5. Feed exact failures back once, then present the diff and check results for human review.
6. Log generation, checks and outcome per task, and track revert rate over time.

Original data

Try it yourself

Open the SDK code converter →

Architecture: API call plus verification pipeline

The API handles language; your pipeline handles truth:

• Context assembler: selects files, interfaces and convention snippets under a token budget.
• Generation call: streams or returns a patch in JSON mode using a coding alias.
• Patch applier: validates the diff, applies it in a sandbox and rejects malformed output.
• Checks: compiler, linter, type checker and tests, with exact errors captured.
• Review: a human sees the diff plus check results, and their decision feeds evaluation.

Implementation details

Small choices with large effects:

• Ask for a unified diff with file headers; it is easy to validate and safer to apply than free-form code.
• Use JSON mode when the result drives automation: fields for path, operation and patch content keep the pipeline deterministic.
• Cap max_tokens so a single response cannot attempt a repository-wide rewrite.
• Include the version of relevant dependencies in the prompt; API changes across versions are a common source of wrong calls.
• Stream only for interactive surfaces; batch-style pipelines get more value from a complete, validated patch.
• Keep secrets out of prompts and run all generated code with no network access.

Evaluation that reflects maintenance cost

Measure outcomes, not volume:

• Compile rate: patches that build on first apply.
• Test pass rate: including held-out tests the model never saw.
• Review acceptance: diffs merged with minor or no edits.
• Revert rate: accepted changes later found defective — the strongest signal of real utility.
• Context efficiency: tokens sent versus task size, to keep large-file workflows practical.

Keep a frozen set of representative tasks and run it when you change aliases, prompts or patch formats.

Limitations

Compatibility does not make generation reliable on its own:

• The model cannot observe runtime behavior; tests and static analysis remain the only evidence.
• Long files and monorepos hit context limits, so scoping is a product decision, not a prompt trick.
• Streaming partial code into an editor can confuse users; buffer by function or statement boundary.
• Fine-tuning and batch endpoints are coming soon; adapt prompts and retrieval rather than planning around them today.
• Treat every generated patch as untrusted: sandbox execution, credential isolation and human review before merge.

Honest comparison

Capability	Code generation on Plugsky	Hosted coding assistant	Local code model
Integration	OpenAI-compatible SDK call	Vendor IDE plugin	Serve the model yourself
Structured edits	JSON mode and unified diffs	Editor-specific format	Prompt-dependent
Verification	Your compiler, linter and tests	Plugin-provided checks	Your pipeline
Model choice	Coding models among 30+ aliases	Vendor model	Models you can host
Deployment	Cloud, VPC, on-prem, air-gapped	Vendor cloud	Your hardware

Frequently asked questions

How is this different from an AI coding assistant?

An assistant is a user interface; this is an API pipeline. You own the context assembly, patch application and verification, which makes it suitable for CI, batch migrations and internal tools.

Should I stream code responses?

Stream for interactive editing experiences, but buffer at function boundaries. For automated pipelines, a complete validated patch is easier to apply and test.

How do I make the model return only a diff?

Use JSON mode with a schema describing path, operation and patch content, and include a diff example. Validate strictness upstream by rejecting anything that does not apply cleanly.

Which model should I use?

plugsky-coder for complex changes and plugsky-coder-fast for routine edits. Benchmark both on your repository tasks, since coding performance varies by language and framework.

Can I reuse my OpenAI code?

Yes. The chat completions request shape is compatible, so changing the base URL and model names is enough to run existing code against Plugsky.

How do I evaluate generated code?

Track compile rate, held-out test pass rate, review acceptance and revert rate. Revert rate is the best proxy for long-term maintenance cost.

Can I test code models for free?

Yes. The free plan includes two free models with no card, and the 14-day full-access trial lets you evaluate plugsky-coder aliases on your own tasks.