Machine-facing contract
Use the public OpenAPI document when you want the raw HTTP route contract before client or UI sugar.
API and contract quickstart.
OpenVibeCoding is the command tower for AI engineering, and it already exposes a useful API and contract edge for dashboard, desktop, and custom frontend consumers. This page is the shortest truthful map when your first question is about HTTP routes, type boundaries, thin client helpers, or builder bootstrap.
If your first question is instead about protocol-level inspection, read-only MCP, or how a coding-agent team should adopt the system truthfully, this page should route you to the better next click instead of making you reverse-engineer the package story from source.
Current package boundary: @openvibecoding/frontend-api-client and
@openvibecoding/frontend-api-contract now carry publish-ready metadata,
but no public package release is live yet. The truthful external adoption path
today is still clone-and-reuse or vendor-and-adapt, while
@openvibecoding/frontend-shared remains a repo-owned presentation
substrate rather than a standalone registry story.
Choose the shortest starting point
| My first question | Start here | Why |
|---|---|---|
| I need the raw HTTP contract | This page | Stay here when your team needs OpenAPI, route/query boundaries, and the package edge first. |
| I need the protocol boundary first | Read-only MCP quickstart | Jump to MCP when the main question is machine-readable inspection rather than package import. |
| I need the best next click for Codex / Claude Code / OpenClaw / skills / builders | Compatibility matrix | Use it when the team still needs the adoption ladder answer before deeper onboarding. |
| I need repo-owned builder packages | Builder quickstart | Use it when you already know you want the workspace-local package layer rather than the protocol or proof-first story. |
What builders can do today
Thin frontend API helpers
Use @openvibecoding/frontend-api-client when you are working inside a clone, shared workspace, or vendored internal package path and want convenience helpers over runs, Workflow Cases, approvals, and command-tower reads.
Generated type boundary
Use @openvibecoding/frontend-api-contract when you are inside the same repo or a vendored workspace copy and want route/query/type boundaries without importing backend modules.
Locale and presentation reuse
Use @openvibecoding/frontend-shared when you are reusing OpenVibeCoding from a clone or vendored workspace and need shared copy, locale helpers, and status presentation across dashboard and desktop surfaces.
Repo-owned starter path
Teams that want the shortest repo-owned starter should begin with createControlPlaneStarter(...) on top of the client when they are working inside a clone or vendored workspace copy, because it bundles the current overview + agents + contracts + role config bootstrap path without implying a hosted SDK platform.
The repo-owned starter example shows the same bootstrap + preview path as runnable code instead of leaving builders to reconstruct it from prose alone.
node packages/frontend-api-client/examples/control_plane_starter.local.mjs \
--base-url http://127.0.0.1:10000 \
--role WORKER \
--mutation-role TECH_LEAD \
--preview-provider cliproxyapi \
--preview-model gpt-5.4Guarded operator-only add-ons
A few extra HTTP surfaces exist for trusted repo operators, but they are intentionally outside the default external builder promise.
/api/agents/roles/{role}/config/previewand/applystay repo-owned role-default control-plane paths./api/queue/from-run/{run_id}/previewand/api/queue/{queue_id}/cancelstay queue-only operator routes for trusted maintainers.- These guarded routes do not upgrade the public story into hosted mutation, public write-capable MCP, or a full SDK platform.
Current boundary
Builder edge, not full SDK
This is a useful builder edge today, but it is still not a full SDK platform.
Read-oriented story
The public builder story is still read-oriented and repo-owned, not a hosted operator service.
Guarded add-ons stay guarded
Role-config preview/apply and queue preview/cancel stay operator-only helpers, not the primary external onboarding promise.
Publish-ready, not published
The thin client and contract package are ready for a future public release, but no npm publication is live yet, so the truthful install path is still clone/workspace reuse or vendor copy rather than npm install.
Shared stays repo-owned
@openvibecoding/frontend-shared remains the repo-owned presentation substrate for dashboard and desktop surfaces, not a standalone distribution unit today.
Minimal onboarding order
- Read the OpenAPI document if you need the raw HTTP contract.
- Use the compatibility matrix if you need the best next click for Codex / Claude Code / OpenClaw / skills / builders before deeper onboarding.
- Use the thin client package when you want convenience helpers over that contract.
- Use contract-facing types when you want typed route/query boundaries without importing backend modules.
- Pair the result with the builder quickstart so package-level adoption stays aligned with the current MCP/API story.