Path 01
Spin up your first workspace
01$ exai login
02$ exai ws create --image node-22
03$ exai ws open --in-browser
§ 01 / 05
Docs · operator handbookNightly regen
Operator memory,
not marketing.
Every CLI flag, every schema field, every webhook payload — pulled from the running product, not hand-copied into a wiki.
You landed here from Google or from the in-product help link. Use the search to jump to a flag. Use the categories below to read a full guide. Use the API reference if you are wiring exAI from a service that is not the IDE.
Search the handbook
§ 02 / 05
Quickstart · three paths
Five minutes.
Three starts.
Pick the surface you arrived for. Each path is a real terminal session — not a tutorial. The CLI is installed once and works against any tenant you have a token for.
Open the guide →
Path 02
Run Composer on a real PR
01$ exai composer review pr/142
02$ exai composer apply --gate human
03$ exai composer ship --branch fix/142
Path 03
Define your first orchestrator DAG
01$ exai dag init nightly-migrate
02$ exai dag run --hitl finance-approver
03$ exai dag tail --receipts
§ 03 / 05
Categories · the whole map
Eight surfaces.
One handbook.
The eight categories below mirror the eight teams at exAI. If you are debugging Composer, read Composer. If you are wiring a custom agent, read Agents. Cross-references are inline, not buried in a tree.
Orchestrator
Extensions
§ 04 / 05
API reference · typed REST
Typed REST.
Generated SDKs.
Every public surface is described by an OpenAPI 3.1 document checked into the same repo as the server code. The TypeScript SDK is generated from that document on every release. The Postman collection is a re-export of the same spec.
The reference is split into seven resources — Workspaces, Runs, Composer, Agents, Receipts, Tokens, and Webhooks. Every endpoint documents its idempotency key, its rate limit class, and whether it fails closed or open on provider outage.
Authentication is bearer-token, scoped to a tenant. Tokens are issued from the tenant settings panel or via SCIM 2.0 for automated provisioning. The SDK reads EXAI_TOKEN from the environment by default.
Every response carries an x-exai-receipt header that points back to the run that produced it — every action is auditable from a single id.
$ curl -X POST \ https://api.exai.cloud/v1/runs \ -H "Authorization: Bearer $EXAI_TOKEN" \ -H "Content-Type: application/json" \ -d '{"plan_id":"pln_01HV...","hitl":true}'
§ 05 / 05
Frequently asked, plainly answered
Five honest
answers.
The questions every operator asks before they trust a docs site with a production runbook. No marketing words — just where the files live, how often they update, and how to talk to a human.
5 questions · 5 answers
Have one we missed? File it against exai/docs with the page slug — the docs team triages every business day.
How fresh are these docs?+
Regenerated nightly from in-product behavior. Every code sample, schema, and CLI flag is pulled from the same source-of-truth registry the product reads at runtime. If a flag was renamed today, the docs reflect it tomorrow at 03:00 UTC.
Is there a self-hostable docs site?+
Yes. The same docs ship as a Helm-deployable mirror — a single chart you install inside your perimeter. It indexes against your private API spec, your tenant flags, and your internal extension registry. Air-gapped customers run it offline against a snapshot tarball.
How do I report a docs error?+
Every page has a one-line footer link that opens a pre-filled GitHub issue against exai/docs with the page slug, anchor, and version. Median time to merge a docs fix is under 14 hours.
Do you publish a roadmap?+
Shipped work lives at /changelog. Forward-looking work lives in the public exai/roadmap repo, filtered by the next 90 days issue label. Anything beyond 90 days is intentionally not promised.
Where do I get help fast?+
Discord for the community channel — best for 'someone has hit this before' questions. Support tier is in-product; Team plans get a 24h SLA. Enterprise plans get a named on-call engineer reachable by phone within one hour P1.