Quick Start
Build from the mono-repo
target/release/aura.
Run it
HTTP mode (connect to an aura-web-server)
Standalone mode (no server needed)
Standalone mode is enabled by default. The CLI loads agent configs directly and runs without an HTTP server. When--api-url is not set, standalone mode activates automatically:
aura-web-server. MCP tools from the TOML config are available. CLI local tools (Shell, Read, Update, …) become available when both sides opt in — pass --enable-client-tools and set [agent].enable_client_tools = true in the loaded TOML config (single-agent configs only; orchestrated configs drop client tools). See Client-Side Tools for details. The /model command works identically — it lists all loaded configs and lets you switch between them.
Generating a starter config (aura init)
New to AURA? aura init walks you through creating a ready-to-run config.toml — no hand-editing TOML required.
- Sense your environment for a provider API key (
OPENAI_API_KEY,ANTHROPIC_API_KEY, …) and suggest that provider. - Pick a provider from a validated list (openai, anthropic, bedrock, gemini, ollama, openrouter).
- Handle the API key: if the provider’s conventional env var is already set it asks whether to use it; otherwise it prompts for the key (input is masked). The generated config references the key by its native env var (
api_key = "{{ env.OPENAI_API_KEY }}") — secrets are never written intoconfig.toml. - Verify & list models: it queries the provider’s live model list and shows a short, curated shortlist (newest per family — pick by number, accept the default, or type any id). For Ollama it lists whatever you have installed.
- Write
config.toml, plus a.envonly when you enter a new key that isn’t already in your environment. The.envholds a secret — add it to your.gitignore.
aura-web-server and the standalone CLI load .env automatically at startup, so a config generated here runs as-is.
Flags
For scripted/CI use, supply the required values as flags:
Backends
AURA CLI supports two backends, selected by the presence of--api-url:
Both backends produce identical SSE event streams and share the same stream parser, so all CLI features (stream panel, tool display, orchestration events, etc.) work identically regardless of backend.
Feature flag: standalone-cli
The standalone-cli Cargo feature is enabled by default. It includes the full agent framework, MCP integration, and provider support. To build a lightweight HTTP-only client with no agent or MCP dependencies, disable default features:
Features
- Interactive REPL with conversation history, streaming responses, and markdown rendering
- One-shot mode for scripting and pipelines (
--query) — stdout is the raw assistant response, no markers or markdown rendering - Local tool execution — the model can read files, search code, list directories, run shell commands, and edit files on your behalf
- Standalone mode (default) — run agents directly from TOML config without a web server
- Conversation persistence — pick up where you left off with
--resumeor/resume - Tab completion — cycle through matching models and conversations with
Tab/Shift+Tab - Model selection — browse and select models from the server (or loaded configs in standalone mode)
- Permission system — control which local tools are allowed, denied, or prompted before execution
- SSE streaming — real-time token-by-token output with a toggleable event panel
- Auto-compaction — automatic context management when conversations grow large
- Mid-stream commands — execute slash commands while the model is still streaming
- Works with any OpenAI-compatible API — not locked to a single provider
Environment Variables
Command Line Arguments
Precedence: CLI flags > environment variables > project
cli.toml > global cli.toml > defaults.
Configuration File
The CLI looks for a TOML preferences file in two places, with the project file overriding the global one on a per-field basis:
The project lookup walks up from the current working directory until it finds a
.aura/ directory (the same convention used by .git, .editorconfig, etc.).
Run the CLI from anywhere inside your project tree and the closest .aura/cli.toml
wins. $HOME is explicitly skipped so the global file is never picked up twice.
Renamed from
config.toml. Older versions read ~/.aura/config.toml. The file is still read with a one-time deprecation warning — rename it to cli.toml at your convenience. The old name collided with AURA agent config TOMLs and will stop being read in a future release.Note on system prompts: In HTTP mode,
--system-prompt is intended for OpenAI-compatible backends that support system messages. AURA’s server ignores system role messages — the CLI will prompt you to confirm whether you’re connecting to AURA or another service. In standalone mode, --system-prompt can append to or replace the agent’s TOML-configured system prompt (you’ll be asked which). In one-shot mode (--query), standalone silently appends; HTTP mode requires --force.One-Shot Mode
--query <text> runs a single round of the conversation and exits. The
output contract is strict: stdout contains only the raw assistant
response — exactly what the model produced, with no bullet markers, no
themed headers, no tool-execution summaries, no markdown rendering, and no
trailing response-summary line.
Anything that isn’t the response goes to stderr:
- Diagnostic logs from
--log-file/AURA_LOG_FILE(file destination unchanged; the file is the same destination in REPL and one-shot mode) - Permission prompts for local tools (interactive, on TTY)
- Errors and warnings (with
error:/warning:prefixes, no markers) - The “no result for server tool X — set
AURA_CUSTOM_EVENTS=true” hint
0 ⇒ stdout is the complete
response; non-zero ⇒ stderr explains why and stdout is empty.
The REPL retains its rich formatting (bullet markers, markdown rendering,
tool-call summaries, animated headers). The strict-output rules above
apply only to --query mode.
Interactive Commands
Once inside the REPL, the slash commands below are available. All slash commands can be executed while output is streaming.Keyboard Shortcuts
When the stream panel is visible, arrow keys and page keys scroll through SSE events instead. Press
Esc to exit stream panel focus.
Model Selection
Use/model to browse and select which model to use for requests.
/v1/models endpoint. In standalone mode, it comes directly from the loaded TOML configs (each config’s alias or name becomes a selectable model).
Client-Side Tools
By default, AURA CLI is a pure chat client — no local tools are advertised to the model and the REPL never executes anything on the host. Pass--enable-client-tools (or set AURA_ENABLE_CLIENT_TOOLS=true) to opt in, at which point the model can call tools like Shell, Read, and Update and the REPL runs them locally with permission checks (Permissions).
[orchestration].enabled = true — tools advertised to an orchestrated config are dropped with a warning.
Both the CLI and the server agent must opt in for local tools to fire — see Client-Side Tools: Backend symmetry for the full mode/effective-behavior table. Precedence for resolving the CLI flag: --enable-client-tools argument or AURA_ENABLE_CLIENT_TOOLS env var > <project>/.aura/cli.toml > ~/.aura/cli.toml (enable_client_tools = true|false) > default (false). If local tools never fire when you expect them to, check that the agent’s TOML has enable_client_tools = true (and the config is single-agent) as well as the CLI flag — in standalone mode the CLI prints a startup warning when the flag is set but no loaded config opts in.
Permissions
AURA CLI includes a permission system that controls which local tools the model is allowed to execute. Permission rules only matter when client-side tools are enabled (see Client-Side Tools). Configure permissions by creating a.aura/permissions.json file in your project directory:
- Allow rules — matching tools execute immediately without prompting.
- Deny rules — matching tools are blocked with a guidance message.
- No match — tools with no matching rule prompt you for approval.
.aura/permissions.json, the same way it finds cli.toml. Permissions are
project-scoped only — there is no ~/.aura/permissions.json. Running the
CLI from outside any project directory means no permissions are loaded, and
every local tool call prompts.
Renamed from
settings.json. Older versions read .aura/settings.json. The file is still read with a one-time deprecation warning; new “always allow” rules accepted at the prompt are written to permissions.json, migrating any existing rules forward.Available Local Tools
Conversations
Conversations are automatically saved to~/.aura/conversations/ and can be resumed:
Logging
The CLI is silent by default — no tracing events are emitted unless you opt in by pointing the CLI at a log file. When set, fmt events are written to that path in both REPL and one-shot mode so stdout (and any pipe consuming it) stays untouched. Three places can supply the path, in precedence order:
The file is opened in append mode and created if missing. The default
filter mirrors
aura-web-server’s verbose mode (info-level for aura crates
and rig request handling); override it with RUST_LOG if you need different
levels.
Standalone-mode OpenTelemetry
When running in standalone mode (the default when--api-url is absent), the
CLI runs the agent in-process. Set OTEL_EXPORTER_OTLP_ENDPOINT and the CLI
will install an OpenTelemetry layer alongside (or instead of) the file fmt
layer — the same trace structure (agent.stream → agent.turn →
mcp.tool_call, with orchestration.* between them in orchestration mode)
that aura-web-server exports. See Tracing & Span Layout for the full span reference.
The CLI omits the chat_completions / streaming_completion infrastructure
spans because there is no HTTP layer in standalone mode — those live on a
separate trace in the server. HTTP-mode CLIs skip OTel entirely: your
traces come from the server process.
OTel init is independent of --log-file; you can run with traces only
(no log file), logs only (no OTel endpoint), or both.
Other relevant OTel env vars (read by the aura crate, unchanged from the
server):
SSE Stream Panel
Toggle with/stream to see raw SSE events in real time. Supported event types:
aura.tool_requested/aura.tool_start/aura.tool_completeaura.usage/aura.tool_usageaura.progress/aura.session_info/aura.reasoningaura.orchestrator.*— multi-agent orchestration events
Compatibility
AURA CLI speaks the standard OpenAI Chat Completions API and works with any compatible backend:- AURA by Mezmo
- OpenAI API / Azure OpenAI
- Local models via Ollama, LM Studio, vLLM, etc.
- Any service implementing
/v1/chat/completions
Hybrid Tool Execution
When client-side tools are enabled, both backends execute server-side tools (MCP, RAG) within the agent’s stream and pause for client-side tools (Shell, Read, …) to be executed in the REPL with permission checks. The CLI follows up with arole: "tool" result and the agent resumes. Server-side tool results arrive via aura.tool_complete SSE events; the CLI uses those rather than executing locally.
When --enable-client-tools is off, the CLI only sees server-side tool execution. See Client-Side Tools for the full flow.
