Kilo Code
Use the Kilo CLI through AnyAgent: what you can ask for, how it behaves, and the flags underneath.
The kilo-code adapter drives the Kilo CLI through kilo run --format json; import kiloCode from anyagent/kilo-code. Kilo’s CLI is an opencode fork with the identical headless surface, so this adapter shares its implementation with the opencode adapter. Kilo is bring-your-own-key (BYOK) with standard provider env vars, or works through a Kilo account (kilo auth login); neither changes a flag here.
What you can ask for
readOnly, model (as "provider/model"), effort (a provider-defined variant name, passed verbatim), resume, forkSession, and attachments all work on the CLI’s own switches; systemPrompt and schema are provided by AnyAgent. MCP is a config-file concern, reachable via extraArgs. models() runs kilo models, every printed provider/model id valid verbatim as model; authStatus() reads ~/.local/share/kilo/auth.json plus the provider key env vars, a hint rather than a guarantee. The full grid is on the support matrix.
Good to know
- Detection looks for
kilo, thenkilocode, onPATH; the first found wins. - The session id is surfaced once, on first sight, and lands on
result.sessionId. - Usage arrives per step: each
step_finishyields ausageevent with that step’s share, including cache, reasoning, and cost, andresult.usagecarries the summed totals.
Under the hood
Every run executes kilo run --format json --auto with the prompt piped over stdin. Run options append flags:
| Option | Flag or env |
|---|---|
readOnly: true | env KILO_PERMISSION={"bash":"deny","edit":"deny"} |
model | --model <provider/model> |
effort | --variant <name> |
resume | --session <sessionId> |
forkSession: true | --fork, alongside --session, branching before continuing |
attachments | -f <file>, repeated once per attachment |