ACE CLI
The ACE CLI is the public OSS/core path for local and agent-friendly onboarding. Use it when you want to bootstrap a repository, validate a self-managed setup, generate starter playbooks, benchmark whether ACE improves results, or move playbook artifacts between hosted and local contexts.
This guide covers the shipped CLI commands in the current runtime:
ace initace doctorace seedace benchmarkace exportace import
If you want the hosted dashboard path first, use the Quick Start. If you want the local-first path, start here and then connect your agent through MCP.
Typical Flows
Bootstrap a local project
Use this flow when you want to stand up ACE in a repository and hand the setup to a developer or coding agent.
ace init --path .
ace doctor --path .
ace seed --path .
ace benchmark --input benchmarks/starter.json
If you need deterministic, machine-readable setup output for an agent, start with:
ace init --path . --agent
Move playbooks between hosted and local contexts
Use this flow when you want a local backup of hosted playbooks, want to migrate artifacts into a self-managed environment, or want to restore a bundle into a hosted workspace.
export ACE_API_URL=https://aceagent.io
export ACE_TOKEN=your-token
ace export --output ace-bundle.json
ace import --input ace-bundle.json
ace export writes a portable bundle to a local JSON file. ace import reads
that bundle and uploads it into the hosted ACE API.
ace init
Use ace init when you are starting ACE in a repository for the first time.
It writes ace.toml with both local and hosted profiles so a project has a
single starting point for self-managed and cloud-connected workflows.
When to use it:
- A repo does not have
ace.tomlyet. - You want a standard local profile that launches the MCP server over stdio.
- You want an agent to bootstrap config deterministically with
--agent.
Example:
ace init --path . --default-profile local
Agent-friendly example:
ace init --path . --agent
What it gives you:
- a project config with local and hosted profiles
- a default MCP stdio command for
python -m ace_platform.mcp.server stdio - recommended follow-up commands:
ace doctor,ace seed,ace benchmark
ace doctor
Use ace doctor right after ace init, before handing a repo to another
developer or agent, or whenever a local ACE setup stops behaving the way you
expect.
When to use it:
- You want to verify Python, config schema, and project paths.
- You want to catch missing Git or MCP dependencies before setup fails later.
- You changed
ace.toml, environment variables, or local runtime settings.
Example:
ace doctor --path .
What it checks:
- Python 3.10+ is available
ace.tomlparses and matches the expected schema- local and hosted profile settings are valid
- stdio MCP commands or hosted MCP URLs are configured correctly
ace seed
Use ace seed when a repository already has useful context in its README,
docs, and examples, and you want starter playbooks without writing them from
scratch.
When to use it:
- You just initialized ACE in an existing repository.
- You want starter playbooks based on current docs and example files.
- You need to refresh generated playbooks after major documentation changes.
Example:
ace seed --path .
Overwrite generated playbooks when you intentionally want to replace prior generated output:
ace seed --path . --force
What it produces:
- starter playbooks in the configured playbooks directory
- generated guidance based on repository structure, docs, and examples
ace benchmark
Use ace benchmark when you need evidence that ACE-assisted behavior is better
than a baseline response or process.
When to use it:
- You want a measurable activation moment after setup.
- You are comparing a weak baseline against an ACE-assisted output.
- You want to show improvement before adopting a playbook more broadly.
Example:
ace benchmark --input benchmarks/starter.json
Minimal benchmark input:
{
"id": "starter-benchmark",
"metric": "exact_match",
"cases": [
{
"id": "case-1",
"prompt": "Summarize the release notes",
"expected_output": "ready",
"baseline_output": "draft",
"ace_output": "ready"
}
]
}
The CLI compares baseline and ACE-assisted outputs case by case and reports the net improvement.
ace export
Use ace export when you want to pull hosted playbooks and traces into a local
portable bundle.
When to use it:
- You want a local backup of hosted playbooks.
- You want to inspect or version a portable bundle in your own environment.
- You want to move hosted artifacts into a self-managed workflow.
Example:
ace export \
--api-url https://aceagent.io \
--token "$ACE_TOKEN" \
--output ace-bundle.json
You can also set ACE_API_URL and ACE_TOKEN in the shell and omit the flags.
What it produces:
- a portable JSON bundle of hosted playbooks and traces
- a file you can archive locally or hand to
ace import
ace import
Use ace import when you want to upload a portable bundle into a hosted ACE
workspace.
When to use it:
- You exported playbooks and want to restore them later.
- You want to move artifacts from a local or backup bundle into hosted ACE.
- You want a repeatable handoff format between environments.
Example:
ace import \
--api-url https://aceagent.io \
--token "$ACE_TOKEN" \
--input ace-bundle.json
What it does:
- reads a local portable bundle file
- posts the bundle into the hosted ACE API
- reports how many playbooks were imported
How The CLI Fits The Product Boundary
The ACE v2 architecture treats local bootstrap, validation, benchmarking, and portability as public OSS/core capabilities. That is why these commands live in the local runtime path and are suitable for self-managed onboarding.
Use the CLI when you want:
- local-first setup
- agent-friendly repository bootstrap
- portable artifact movement between local and hosted contexts
Use the hosted dashboard when you want:
- managed auth and sessions
- billing and workspace administration
- hosted convenience after local setup is complete