How do you build coding agents with an OpenAI-compatible API?

Key facts

Endpoint	POST https://api.plugsky.com/v1/chat/completions with function calling for repository tools
Compatibility	Same shape as OpenAI; keep existing agent frameworks and change base_url
Models	30+ models; use plugsky-coder aliases for edits and cheaper models for triage
Execution	All file and test operations run in your CI sandbox, never in the model
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
Free tier	Free plan with 2 free AI models, no card required
Governance	Scoped keys per repository, audit logs and region pinning
Roadmap	Batch and fine-tuning endpoints are coming soon

TL;DR

• The API plans and proposes; your CI applies, tests and reports.
• Compatibility means existing agent frameworks connect with a base-URL change.
• Issue one scoped key per repository so a leak has a bounded blast radius.
• Queue tasks and serialize writes per repository to avoid conflicting patches.
• Evaluate CI pass rate, review acceptance and cost per merged change.

How it works, step by step

1. Change the base URL to Plugsky and verify an existing agent framework runs a tool call end to end.
2. Define repository tools backed by your CI runner: read, search, propose patch, run checks.
3. Issue a scoped API key per repository and keep it in your secret manager, never in prompts.
4. Queue agent tasks, process one per repository at a time, and apply patches on isolated branches.
5. Return check results to the agent for one correction pass, then surface the diff for review.
6. Track CI pass rate, review acceptance, revert rate and cost per merged change.

Original data

Try it yourself

Open the OpenAI compatibility checker →

Architecture: model proposes, CI disposes

Split the agent across two trust zones:

• Model zone: the chat completions call with tool schemas — file reads, searches and patch proposals only.
• Execution zone: a CI worker that owns the workspace, applies patches, runs checks and enforces policy.
• Queue: tasks are queued and processed one per repository to avoid conflicting edits.
• Artifacts: each task produces a branch, a diff and a check report for human review.

Because the request shape matches OpenAI, frameworks you already use for tool calling connect with a base-URL change, and you can swap aliases per step without touching the framework.

Implementation details

Operational choices that keep the agent safe and useful:

• Use function calling for repository operations; never give the model a general-purpose shell tool.
• Send only the context each step needs — target files, interfaces and the failing check output.
• Cap tool loops, patch size and wall-clock time per task; a stuck agent should fail closed.
• Serialize repository writes and use branch-per-task so two agents cannot race.
• Store the full trace — model, tools, patches, checks — in your own logs for audit and replay.
• Rotate scoped keys on schedule and keep them out of prompts and generated code.

Evaluation and operations

Agent value shows up in merged work, not in session logs:

• CI pass rate: first-apply checks passing before human intervention.
• Review acceptance: patches merged with minor or no edits.
• Revert rate: merged changes later undone, tracked per task type.
• Throughput: tasks completed per hour under concurrency limits.
• Cost per merged change: total model work divided by accepted diffs.

Run a replay suite of past tasks after every prompt, tool or alias change. Framework updates are common, so treat the replay set as your regression harness.

Limitations

Honest edges of the API-based approach:

• The model cannot observe runtime behavior, so static analysis and tests are the only evidence.
• Long refactors exceed practical session budgets; break them into scoped tasks with explicit acceptance checks.
• Secrets and credentials must never enter model context, even when the agent is debugging configuration.
• Agent frameworks change quickly; pin versions and validate compatibility on a schedule.
• Batch and fine-tuning endpoints are coming soon; current pipelines should rely on scheduling and prompt design.

Honest comparison

Capability	Agent on Plugsky API	Vendor-locked agent product	Fully local agent stack
Framework support	OpenAI-compatible tool calling	Vendor framework only	Whatever you build
Model choice	30+ aliases, swappable per step	Vendor models	Models you can host
Execution control	Your CI owns the sandbox	Vendor-run execution	Your infrastructure
Keys and audit	Scoped keys per repo plus your logs	Vendor-managed	Fully self-managed
Deployment	Cloud, VPC, on-prem, air-gapped	Vendor cloud	On your hardware

Frequently asked questions

Can I use an existing agent framework?

Yes. The chat completions endpoint is OpenAI-compatible, so frameworks that support tool calling connect by changing the base URL and model names.

Where does the agent run code?

In your CI sandbox. The model only proposes patches; your worker applies and tests them, which keeps execution, secrets and approvals under your control.

How do I scope API keys?

Issue one scoped key per repository, store it in your secret manager, rotate it on schedule, and never place it in prompts or generated files.

How do I prevent two agents from conflicting?

Queue tasks and process one per repository at a time, applying each patch on an isolated branch before review.

Which model should edit code?

plugsky-coder for complex changes, plugsky-coder-fast for routine ones, and cheaper aliases for triage, summarization and log digestion.

What should I measure?

CI pass rate, review acceptance, revert rate, throughput under your limits, and cost per merged change.

Can I evaluate agents cheaply?

Yes. The free plan includes two free models with no card, and the 14-day full-access trial lets you benchmark coding aliases on real repository tasks.