Daemon Backend Mimocode

MiMo Code Daemon Backend — Flag Discovery Entrypoint

The installed CLI's own help is the authority for MiMo Code (npm package @mimo-ai/cli, binary mimo) flags; this page is only the entrypoint. Conversion rules, key safety, and persistence live in the parent reference/cli-backends/SKILL.md.

Backend identity and spawn shape

mimo is a short alias: the daemon canonicalizes it to mimocode, and persisted daemon entries use the canonical name. The backend spawns mimo run --format json <prompt>; converted backend_options tokens sit between the harness flags and the trailing prompt positional.

Discover flags from the installed CLI

1. Run, in bash: mimo --version, mimo --help, and mimo run --help. The daemon backend wraps mimo run, so mimo run --help is the relevant flag surface. These are local read-only commands; no session is started.
2. Translate what you found into backend_options with the parent's generic conversion rules. Nothing MiMo-specific is added to that contract here.

Example: model selection via the generic route

{
  "backend": "mimo",  // canonicalizes to "mimocode"
  "tasks": [{
    "task": "Implement and validate the change.",
    "tools": [],
    "backend_options": {
      "model": "mimo-auto"
    }
  }]
}
// spawned argv: mimo run --format json --model mimo-auto <prompt>

The flag/value vocabulary belongs to the installed CLI — LingTai does not validate, enumerate, or simulate it.

Subscription & auth

Provider/model credential discovery stays with swiss-knife xiaomi-mimo; the CLI reads its configured credentials at spawn. LingTai does not inject or rotate them.

Official docs: https://github.com/XiaomiMiMo/MiMo-Code

Harness boundary

mimocode reserves --format (daemon progress/result extraction depends on --format json JSONL events) plus its own session selectors — --session (-s), --continue (-c), and --fork — MiMo-specifically. Passing any of them in backend_options refuses the whole batch before any process is spawned, because session/resume is harness-owned: daemon(action="ask", input={"id": ..., "message": ...}) asynchronously runs mimo run --session <mimocode_session_id> --format json <message>, with the session id captured from the first session-shaped JSON event into daemon.json. Non-session backend_options (e.g. --model) still pass through unchanged.

Verified JSONL answer/error contract (MiMo Code 0.1.5)

MiMo tags every JSONL event with a type and carries a nested part.text on many of them (reasoning, tool, step, step-start, ...), not only the answer. LingTai surfaces the user-visible answer from only the type == "text" event's part.text string; reasoning/tool/step part.text is ignored and never becomes the daemon result. A structured type == "error" event makes the run fail loudly even when the process exits 0; the human-visible detail is bounded (≤500 chars) and secret-redacted, not the raw nested payload. The same answer/error contract applies to the ask resume stream. Non-JSON stdout lines are still recorded as cli_output.

For source-reported usage, LingTai accepts only type == "step_finish" whose nested part.type == "step-finish" has a non-empty string part.id and all five non-negative, non-boolean integer counters: tokens.input, output, reasoning, cache.read, and cache.write. It maps input directly, output directly, reasoning to thinking, and the two cache counters to combined cached tokens. Malformed or all-zero parts are ignored; each distinct part.id is counted once across initial and resume streams, and the nested source part is kept in the cli_usage event raw field. This is UI-only cli_tokens state: it never writes either token ledger and does not infer provider or model.

Per-run daemon_common MCP injection is not wired for mimocode yet, so the MCP completion contract is not enforced on this backend; parent MCP registrations reach the run as prompt catalog only.