Skip to content

FAQ

BMO is an open-source, terminal-native AI coding agent built in Go. It integrates directly into your development workflow — reading, editing, and running code in your local environment.

BMO supports Anthropic Claude, OpenAI, Google Gemini/Vertex, AWS Bedrock, Azure OpenAI, Groq, OpenRouter, and any OpenAI-compatible endpoint. See Authentication for setup.

BMO sends your prompts and file contents to the AI provider you configure (e.g. Anthropic, OpenAI). It does not send data to any BMO-operated backend.

BMO itself is free and open-source. You pay only for the AI provider API usage.

Global config lives in ~/.config/bmo/bmo.toml by default. Project-local overrides use bmo.toml or .bmo.toml. Existing JSON config files are still loaded as a fallback, but TOML is the canonical format.

Terminal window
export ANTHROPIC_API_KEY=sk-...

Or set it in bmo.toml:

[providers.anthropic]
api_key = "${ANTHROPIC_API_KEY}"

See Authentication.

Can I use different models for different tasks?

Section titled “Can I use different models for different tasks?”

Yes. Use Phase Model Routing to configure separate planning and execution models, or configure per-agent models in multi-agent setups.

Yes — the bash tool runs shell commands. By default, BMO asks for confirmation before running potentially destructive commands. Use Lifecycle Hooks or the Execution Sandbox to restrict what can run.

Yes. The built-in web tools are web_fetch, web_search, and agentic_fetch. Hide them globally with options.disabled_tools, or remove them from a specific agent via [agents.<id>.tools].

How do I limit what tools the agent can use?

Section titled “How do I limit what tools the agent can use?”

Use the layer that matches what you want to control:

[options]
disabled_tools = ["web_search", "sourcegraph"]
[agents.coder.tools]
allowed = ["view", "grep", "glob", "bash"]
[permissions]
allowed_tools = ["view", "grep"]

options.disabled_tools hides built-ins globally. agents.<id>.tools shapes one agent’s tool set. permissions.allowed_tools skips approval prompts but does not hide the tools.

See Sessions for the full concept: one SQLite-backed conversation, switching, branches, and session checkpoints vs git undo.

Use /session in the TUI to browse and resume prior sessions, or bmo session resume --session <id> for health-checked resume from the CLI.

BMO uses Context Pruning to automatically trim older context as a session approaches the model limit. Tune it with options.pruning.*.

Which BMO artifact should I use to understand what happened?

Section titled “Which BMO artifact should I use to understand what happened?”

BMO does not reduce run evidence to one receipt-like file. It keeps separate surfaces for separate operator questions:

Use caseUse this surface
Replay the ordered timeline of a runAgent Debugger or get_agent_run_events, backed by the durable run ledger
Check what is happening now and who should act nextRun observability and the cue ledger
Preserve enough context to continue after handoff or compactionSession continuity capsules, surfaced through session observability and session-capsule posture
Read a dated narrative with provenance across subsystemsJournal export and Journal posture
Package evidence for a runtime failure/incident or the runtime incident tools, which write a bounded diagnostic capsule
Audit tool authority decisionsPermission prompts and permission audit entries

Capsules are part of the answer, but they are not the whole evidence system: session continuity capsules are for handoff, while edit capsules are for multi-file rollback. For post-run replay, start with the Agent Debugger. For a support incident, start with /incident. For current session state across HTTP, TUI, tools, and MCP, use Session observability parity.

Model Context Protocol — a standard for connecting AI models to external tools and data sources. BMO can act as both an MCP client (consuming external tools) and an MCP server (exposing its tools to editors like Cursor, VS Code, Zed). See MCP Client and MCP Server.