Frontend API client
Use the repo-owned client when you are consuming OpenVibeCoding from a clone or vendored workspace and want convenience helpers for command-tower overview, runs, Workflow Cases, approvals, and role-config preview reads.
Builder quickstart.
OpenVibeCoding is the command tower for AI engineering, and it already exposes a useful builder surface across three layers: a thin frontend API client, contract-facing route/type bindings, and a shared presentation substrate.
If your team already understands the workflow and protocol boundary and now wants the shortest repo-owned package path, this page is the right next click.
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 current official install path
is still clone/workspace reuse or vendor copy, while
@openvibecoding/frontend-shared remains a repo-owned presentation
substrate instead of a standalone package story.
Choose the shortest builder entry
| Need | Open first | Why |
|---|---|---|
| Convenience client | @openvibecoding/frontend-api-client |
Use it when you are working inside a clone or shared workspace copy and want overview, runs, Workflow Cases, approvals, and bootstrap reads through one thin helper layer. |
| Route/type boundary | @openvibecoding/frontend-api-contract |
Use it when your real need is generated contract-facing types without backend imports inside the same repo or a vendored package copy. |
| Shared presentation | @openvibecoding/frontend-shared |
Use it when you need repo-owned copy, locale, and status-presentation substrate for dashboard, desktop, and future web consumers inside the same workspace story. |
| Protocol before packages | Read-only MCP quickstart | Use MCP first when your team still needs the truth boundary before it decides which package layer to import. |
What builders get today
Generated type edge
Use the contract package when you are already inside the same repo or a vendored workspace copy and want route/query/type boundaries without importing backend modules into your frontend surface.
Presentation substrate
Use the shared package when you are reusing OpenVibeCoding from a clone or vendored workspace and want brand copy, locale, and status presentation to stay aligned across dashboard, desktop, and future web consumers.
Still repo-owned
These are real builder entrypoints, but they do not turn OpenVibeCoding into a hosted SDK platform, marketplace artifact, or write-capable MCP product.
Publish-ready, not published
The thin client and contract package are ready for a future release, but no npm publication is live yet. The truthful install path today is still clone/workspace reuse or vendor copy.
Shared stays repo-owned
@openvibecoding/frontend-shared is useful, but it is still the repo-owned presentation substrate rather than a standalone distribution unit.
Repo-owned starter path
If you want the shortest runnable builder path inside this repo, start with the repo-owned control-plane starter example instead of rebuilding the bootstrap story from scratch.
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.4This starter remains preview-first by default. It demonstrates overview + agents + contracts + role-config preview without claiming hosted operator accounts, write-capable MCP, or a full SDK platform.
If your next move is wiring the same repo truth into Codex, Claude Code, or OpenClaw itself, pair this page with the agent starter kits.
Vendor or shared-workspace adoption recipe
- Confirm the host ecosystem first: Codex, Claude Code, or OpenClaw should be understood from their own official docs before you import any OpenVibeCoding package.
- Keep the three OpenVibeCoding packages together in one clone or vendored workspace copy:
frontend-api-client,frontend-api-contract, andfrontend-shared. - Use the repo-owned starter example as the first proof that your workspace wiring is correct.
- Only promote to guarded operator actions such as
--applyafter preview works and your team accepts the trusted-operator boundary.
git clone https://github.com/xiaojiou176-open/OpenVibeCoding.git
cd OpenVibeCoding
npm run bootstrap:host
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.4Official ecosystem anchors for builders
Pair package adoption with the official Codex repo and Codex docs.
Pair package adoption with the official overview and MCP docs.
Pair package adoption with the official OpenClaw repo, skills docs, and ClawHub.
Guarded operator-only add-ons
--applyon the starter stays a trusted repo-operator flow for role-default changes.- Queue preview/cancel helpers stay trusted operator control-plane add-ons, not the default external builder promise.
- These surfaces do not turn the builder story into hosted mutation or public write-capable MCP.
Fast onboarding order
- Read compatibility matrix if you still need the best next click for Codex / Claude Code / OpenClaw / skills / builders.
- Read read-only MCP quickstart if protocol truth still matters more than packages.
- Read API and contract quickstart for the raw HTTP and contract edge.
- Come back here when your next move is package adoption rather than protocol discovery.