The Manual.

Knockout ships as a single Go binary called ko. The installer autodetects your OS (Linux, macOS) and architecture (amd64, arm64), downloads the matching release, drops it in /usr/local/bin/ko and marks it executable.

# One-liner
curl -fsSL https://fightclub.pro/install.sh | sh

# Verify
ko version

The installer needs curl or wget and network access to the release archive; it doesn't build from source. For a fully manual install, grab the binary for your platform from https://fightclub.pro/api/ko/releases/<version>/ko-<os>-<arch> (read <version> from https://fightclub.pro/ko/latest-version.txt), make it executable, move it into your PATH.

To upgrade an installed binary, run ko update. It checks https://fightclub.pro/ko/latest-version.txt, and if a newer release exists it downloads and replaces the running binary in place. Already current, it says so and exits. ko also nudges you when a newer version is out.

ko update   # check for a newer ko and upgrade in place

All of ko's state lives in ~/.ko/: credentials, session history, memory, skills and settings. Projects can also have a local .ko/directory for project-scoped memory and snapshots.

Ko uses scoped API tokens. ko auth login is the interactive path, it opens your browser at the Fight Club platform, you sign in, grant the CLI scope, and a token is written to ~/.ko/credentials.json.

ko auth login       # browser OAuth, for personal machines
ko auth token <tok> # paste an existing token, for CI/headless
ko auth status      # show which account + wallet balance

For CI, servers, or containers where browser-based OAuth isn't possible, create an API token from the web dashboard at /dashboard/settings. The preferred way to hand it to ko in an automated environment is KO_TOKEN_FILE: point it at a file holding the token and ko reads it on startup, no on-disk credentials cache and no token in the process environment or shell history.

# preferred: token in a file, referenced by env var
echo "$KO_TOKEN" > /run/secrets/ko-token
KO_TOKEN_FILE=/run/secrets/ko-token ko -p "run the checks"

# interactive/one-off: cache a pasted token under ~/.ko
ko auth token <tok>

ko auth token <tok> still works and caches the token in ~/.ko/credentials.json. The older KO_API_TOKEN env var is deprecated, it prints a warning at runtime and points you at KO_TOKEN_FILE; don't use it in new setups.

The API token itself doesn't expire, revoke it from the platform dashboard if needed. For unlocking your BYOK provider keys so ko can decrypt them, see Vault (BYOK unlock).

Your provider keys sit on our server, encrypted under a password we never receive. When you run ko vault unlock, the password stays on your machine. scrypt derives a key from it locally at N=131072, r=8, p=1, ko sends only the derived key, and the server holds that key just long enough to decrypt your Anthropic key and make the call.

So we cannot reset your vault password. No recovery path. There is no plaintext copy anywhere on our side to recover from, which is the same property that stops an attacker who walks off with our database from reading your keys. Forget the password and you reset the vault and paste your keys in again.

The derived key caches in ~/.ko/credentials.json at mode 0600, and the CLI vault session it opens on the server locks after 4 hours idle. Every real turn rolls that window forward, because only actual cryptographic use extends it, not status checks. Leave a terminal open overnight and the next turn prompts you again.

ko vault unlock   # prompts for vault password (once per machine)
ko vault status   # show whether the vault is locked/unlocked + local cache
ko vault lock     # revoke the CLI session + wipe the cached key

Web and CLI sessions are independent. Unlocking from ko does not open the web session. The web vault locks after 1 hour idle (with a 12 hour absolute cap); the ko CLI vault locks after 4 hours idle, with no absolute cap beyond that idle window.

If the machine is lost or compromised: log into the web UI and change your vault password. This re-encrypts every BYOK entry under a new vault key; any cached key on the lost machine is now useless (ko's auto-restore checks the vault verifier before re-creating the session and silently fails against a stale key).

If you never use your own provider keys (only fc:* platform-pool models), you don't need to run ko vault unlock at all, those models route through platform-managed credentials that never touch the vault.

Close the terminal on a long piece of work and you normally lose the thread. ko doesn't. Every message, tool call and file edit is written to the server as it happens, so ko -c tomorrow morning on a different laptop picks up mid-thought.

Sessions are pinned to the directory they started in. Start one in ~/project-a, run ko -c from ~/project-b, and you get a fresh session for B rather than project A's context bleeding into unrelated code. The binding is the feature.

ko                      # start a new session in $(pwd)
ko "quick question"     # start with an initial prompt
ko -p "one-shot"        # non-interactive: print answer, exit
ko -c                   # continue the most recent session in $(pwd)
ko -r                   # pick from a list of recent sessions
ko --resume-id <id>     # jump straight to a specific session
ko sessions             # list all past sessions
ko resume <id>          # same as --resume-id

The first time you run ko in a new directory, it auto-registers the folder as a ko project. Subsequent runs pick up the same project record.

Root flags

Running the loop in-process (ko local)

ko local runs the whole agent loop in-process on your machine. The loop, tool execution and your BYOK provider key all stay on the box. ko fetches the pipeline and system-prompt assignment from the platform once, then everything after that is local.

ko local "review the diff"     # run the agent loop in-process
ko local --detach "long job"   # background process that survives terminal close
ko local --attach <id>         # reattach to a detached (running or finished) session

Web UI alongside the TUI (--listen)

--listen <address> starts a browser UI next to the terminal one on the same session (--listen 127.0.0.1 for local only, --listen 0.0.0.0 to expose it on the network). --port pins the bind port; left off, ko picks a free one and prints the URL.

Ask three good engineers to fix the same bug and you get three shapes of answer. One reads the whole module before touching anything, another writes a failing test first, and the third patches it and runs the suite to see what screams. A pipeline is you picking which of those ko is, before it starts.

Each step carries its own model, system prompt and tool allowlist. The allowlist does more work than people expect. A planner that physically cannot call Write won't drift into implementing, because the option isn't on the table, so you get a plan back instead of a half-finished patch.

Ten pipelines seed to a new account:

Swap pipelines mid-session with the /pipeline slash command. Your conversation history is preserved; the next task uses the new flow. Build custom pipelines in the visual editor at /dashboard/pipelines.

/pipeline              # list available pipelines (TUI)
/pipeline KO_consensus # switch to a named pipeline

Switching a pipeline mid-session also resets any model override you picked with /model, so the new pipeline runs its own per-step models. The TUI prints "Model reset to pipeline default"to make the reset explicit.

During a pipeline run, each step transition banner shows which model is handling that phase, e.g. ─── Plan → Implement: Step Implement · claude-sonnet-4-6 ───. The top-bar model label also swaps to the step's model as soon as streaming starts.

Per-step caps

Each step in the editor has three caps. The pipeline editor surfaces them as Max $, Max In, Max Out (hover the ⓘ icons next to each label for the live definitions). In short:

Pipelines are where ko goes from "generic agent" to "opinionated workflow that beats a single-model baseline." Design matters: the same three frontier models wired differently (parallel vote vs. plan→implement→verify vs. adversarial A/B debate) produce wildly different quality, latency and cost profiles. This section unpacks every field in the editor at /dashboard/pipelines.

Anatomy of a step

Every step in a pipeline has the following fields. Most are surfaced as form controls in the visual editor at /dashboard/pipelines; all of them show up in the JSON if you export or edit a pipeline config directly.

Multi-model strategies

When models has more than one entry, the step runs all N through one of four strategies, chosen by multiModelStrategy. Each has different cost, latency and quality trade-offs:

Transitions

Transitions are the state-machine layer. After a stage emits its structured artifact, an outcome string is derived from the artifact via the stage's outcomeRule (e.g. simpleSuccess returns success or no_work; fieldEnum:verdict reads the artifact's verdict field and returns it directly). That outcome is then matched top-to-bottom against the stage's transitions array; the first match's goto picks the next stage.

The outcome rules ship with the platform; the common ones are:

• simpleSuccess, returns no_work when the artifact set no_work: true, otherwise success.
• implementOutcome, returns success if any executed step in the artifact reported completed, else failure.
• fieldEnum:verdict, reads the artifact's verdict field (pass / fail on Verify stages).
• fieldEnum:outcome, reads the artifact's outcome field (Test / Review stages emit this directly).

The goto side supports three reserved targets plus any step name:

The special condition default matches everything and is almost always the last rule, it's the fallback when no named condition matched.

transitions:
  - { condition: "tests_fail",       goto: "Implement" }   # loop back
  - { condition: "security_issue",   goto: "SecurityFix" } # branch
  - { condition: "budget_exceeded",  goto: "_done" }       # stop on cap
  - { condition: "default",          goto: "_next" }       # otherwise advance

Common patterns

A few recurring shapes worth copying:

Design principles

• Shorter tool allowlists beat longer ones. A planner that can't write files won't try to implement. A reviewer that can only Read + Grep won't "fix" problems instead of reporting them.
• Use slots, not fixed model addresses. slot:code_frontier lets the platform swap the concrete model without touching your pipeline. Your KO_custom stays current through frontier model upgrades automatically.
• Cheaper verifiers, expensive planners. Planning errors cascade; verification errors are local. Spend the budget where a bad decision is costliest to undo.
• Branch on the artifact, not on text. When a stage's outcome has more signal than success/failure ("tests failed", "security issue found", "needs human review"), pick an outcomeRule that reads the structured field carrying that signal (e.g. fieldEnum:verdict for a Verify stage, fieldEnum:outcome for Review). The model emits the field; the orchestrator does the routing.
• Cap ambition with maxCostUsd. Even if the cap fires reactively (after the step finishes), it's still the fastest way to keep a runaway _self loop from draining a wallet.
• Test pipelines on small tasks. Edit your pipeline in the visual editor, switch to it with /pipeline <name>, and ask something cheap like "summarize README.md" to watch the flow execute before committing to an expensive run.

Ko uses model slots, abstract roles like code_frontier, code_planner, code_verifier, budget_fast. The platform admin maps each slot to a concrete model address (e.g. fc:anthropic/claude-sonnet-4.6). Pipelines reference slots, not concrete models, so the same pipeline works across model upgrades without edits.

19 providers are supported, routed through the platform pool for Fight Club models and directly for user-managed API keys:

OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI (Grok),
Cohere, Groq, Together, Fireworks, Cerebras, SambaNova,
Perplexity, OpenRouter, Ollama, Azure OpenAI, Bedrock,
HuggingFace, Replicate

Override the model for a single session with -m, or swap mid-session with the /model command inside the TUI:

ko -m fc:openai/gpt-4o "summarize src/"
ko -m user:<config-id>/mistral-large "write a README"
/model   # list models; pick a number to switch for the rest of this session

The fc: prefix uses Fight Club's platform wallet; the user: prefix uses your own vault-encrypted provider config. Add your own provider keys at /dashboard/settings.

Model picks are session-scoped, they are not persisted to disk. Closing the TUI and reopening it starts fresh with the pipeline's own per-step models. Swapping pipelines mid-session also drops any active override (see Pipelines). If you want a sticky preference, pass-m on every launch or configure it platform-side in your slot mapping.

Ko agents have 19 tools. Each pipeline step declares which subset it can use, and that allowlist is the strongest control you have over how a step behaves. Shorter lists produce more focused work.

Pipelines also use auto-generated Emit{Schema} tools (one per stage, named after the stage's declared artifactSchema: EmitPlan, EmitImplement, EmitVerify, etc.). Each stage ends when the model calls its emit tool with a structured artifact; the orchestrator validates the artifact against the schema and the stage's contract rule, then transitions. You don't define these tools; the orchestrator wires them in per stage based on artifactSchema.

Skills are prompt + tool bundles that teach ko a specific domain or workflow (e.g. "write Next.js Server Components correctly", "apply these brand guidelines", "run this CI workflow"). The marketplace at /dashboard/skills lists installable community skills.

ko skills                    # list installed skills
ko skills install <id>       # install from the store
ko skills uninstall <name>   # remove a skill
ko skills update             # update all installed skills
ko skills create <name>      # scaffold a new skill in the current project
ko skills audit              # inventory every loaded skill with hash + signature status

ko skills audit is the supply-chain view. It lists every loaded skill (pre-installed, global and project) with its source, a SHA-256 hash of the content and its signature status, verified for a valid Ed25519 signature, INVALID for one that doesn't check out, unsigned or bundled otherwise. The hash lets you spot silent content drift between installs; the signature column tells you whether a skill is what its author signed.

Skills are sourced from ~/.ko/skills/ (global) and .ko/skills/ (project-local). Global skills apply to every session; project skills only apply when ko runs in that directory.

Skill Seekers, coming soon, will be a specialized skill that reads external documentation URLs and caches them as an in-agent reference. Point it at any library's docs site and ko becomes an instant expert in that library.

Memory is a lightweight, file-based long-term store. Two scopes:

ko memory list             # list all memory files (global + project)
ko memory show <name>      # print a memory file
ko memory edit <name>      # open a memory in $EDITOR (creates from a template if missing)
ko memory delete <name>    # remove a memory and reindex
ko memory reindex          # re-derive MEMORY.md from frontmatter (self-heal)

edit, show, delete and reindex all take a <name> argument, the bare command errors. Scope the operation with --global (~/.ko/memory/) or --project (.ko/memory/). ko memory edit MEMORY.md is refused unless you pass --force: MEMORY.md is the auto-derived index that the agent's MemoryWrite regenerates, so hand edits get overwritten on the next save. Edit the individual memory files, not the index.

Inside a session, ko writes to memory autonomously when you tell it something worth remembering ("I always use pnpm, not npm"), it'll save a memory file and recall it in future sessions. The index file MEMORY.md is loaded into every session's system prompt; individual memory files are loaded on demand.

Cross-device memory sync

File memories are local by default. Enroll a scope in cross-device sync and ko keeps its .ko/memory/ in step across your machines through the vault, encrypted, so the server stores opaque blobs it can't read.

ko memory sync on          # enroll this scope for cross-device sync
ko memory sync status      # enrollment state + local/remote memory counts
ko memory sync off         # opt out (wipes the vault copy, keeps local files)
ko memory sync             # manual full pull+push now

# add --global to any of the above to operate on ~/.ko/memory instead of the project

Promoting memories into the Brain (ko brain)

File memories are sealed, encrypted so the platform can't read them. The semantic Brain is the opposite: the agent retrieves promoted memories by relevance, which means the platform embeds their plaintext. Promotion therefore de-seals, and it's gated behind a one-time confirmation.

ko brain import-memory                 # promote eligible file memories into the Brain (DE-SEALS)
ko brain import-memory --dry-run       # list what would promote, write nothing
ko brain import-memory --project       # limit to <cwd>/.ko/memory  (--global for ~/.ko/memory)
ko brain import-memory --name <name>   # promote a single named memory
ko brain import-memory --prune         # drop promoted Brain docs whose source memory is gone
ko brain auto [off|manual|auto]        # show or set the memory→Brain promotion mode

Eligibility follows each memory's promote frontmatter flag (project and reference memories default to promotable; user and feedback memories don't), and anything that looks like it carries a secret is skipped server-side. The first real import prints a de-seal warning and asks for confirmation; --yes skips that prompt once you understand the tradeoff.

The memory section above covers human-edited memory files. This section covers the vector-indexed surfaces ko manages for you: workspace index, cross-session memory, session scratchpad and audit log. Chunks are retrieved by meaning rather than by exact string match, which is the difference between "find the auth handler" landing the right file and returning nothing.

All four sit on the same Ringside vector_stores API that ships to external customers, so ko is its own biggest user of that infrastructure.

Workspace (ko workspace)

Indexes the repo so the agent can answer concept queries. A one-shot walk on first init, plus an fsnotify watcher that re-embeds changes with a 5-second debounce. The walker honors .gitignore and an optional .koignore for ko-specific exclusions. It skips files larger than 1 MB and sniffs the first 4 KB for null bytes to filter binaries. Files matching common secret patterns (.env, *.pem, id_rsa*, secrets.*) are never embedded.

ko workspace init           # walk the repo, embed every kept file
ko workspace init --no-watch   # skip the background fs-watcher
ko workspace sync           # one-shot reconcile after offline edits
ko workspace status         # show indexed/pending/skipped counts
ko workspace drop           # delete the workspace store entirely

The differentiator vs Cursor or Claude Code is that retrieval is semantic, not lexical. Ask "where do we rate-limit incoming webhooks" and the agent pulls the right middleware even if the file never uses the word "webhook". Internally the agent calls a VectorSearch tool, so retrieval is paid only when used and the chunks come back as cite-able tool output.

Cross-session memory (ko memory)

Opt-in. When enabled, every completed session is summarized by google/gemini-2.5-flash and the summary is embedded into your personal episodic store. New sessions get the top 5 relevant past sessions prepended to the system prompt, and the agent can VectorSearch it mid-session if it wants more.

ko memory enable                    # turn on episodic indexing
ko memory enable --backfill 90      # also index the last N days: 0 | 30 | 90 | 365 | all
ko memory disable                   # stop indexing new sessions, keep what's already there
ko memory status                    # show enabled state, episode count, retention
ko memory search "<query>"          # forensic search across your own session history (--limit, --scope)
ko memory export --since=2026-01-01 > episodes.jsonl   # stream indexed episodes (--format, --scope)
ko memory wipe --yes                # drop the store and soft-delete the episodes

Episodes older than 365 days detach from the vector store but stay in your archive (so memory export still returns them). Exclude patterns on the user record skip sessions matching a regex, --no-episodic on any individual ko -p run opts that one out.

The store lives server-side, so the memory follows the account rather than the laptop. Switch machines, sign in, the agent still knows what you were doing.

Session scratchpad (always on)

Tool outputs above 8 KB get uploaded to a per-session vector store and replaced in the running context with a short stub: [scratchpad:<file_id>] preview: ... (47213 bytes offloaded). The agent gets two retrieval paths back:

On by default, and you rarely want it off. Long sessions stop paying input tokens on cold context, and quality stops sliding late in the session for the same reason. If a scope genuinely needs it disabled, ko scope settings <cat=val> --scratchpad-disabled=true turns it off there. The per-session store self-destructs 24 hours after the session ends.

Audit (ko audit)

Opt-in. When enabled, every tool call from every session indexes one chunk into your audit store: session_id, timestamp, tool name, redacted args, success/error, a 256-char preview of the output and the scope tags the session ran under. Not the full output (that lives in the session log), just the needle-in-haystack lookup row.

ko audit enable                            # provision the store, backfill 90 days
ko audit enable --backfill-days=365        # or pick your own window, 0-365
ko audit status                            # enabled state, store id, retention
ko audit search "<query>"                  # natural-language search across all your sessions (--limit)
ko audit search "<query>" --scope=release=production
ko audit export --since=2026-04-01 > audit.jsonl   # also --session, --format
ko audit disable                           # stop indexing; raw events still persist in ko_session_events

Default retention is 90 days, configurable up to several years per scope. Sessions tagged release=production can carry a 2555-day (7-year) retention while everything else expires fast. The admin dashboard exposes a cross-user view at /admin/ko/audit for abuse review and compliance evidence.

Concrete use: you finished a 4-hour session yesterday and want to confirm the agent never read prod_secrets.env. ko audit search "prod_secrets" returns every chunk that mentions it. Zero matches is a real answer, not a hope.

Scopes (ko scope)

A scope is an ordered set of (category, value) tags that classifies what a session is doing. project=fightclub, release=production, customer=rubin, severity=p0 or any custom category you want. Every indexed chunk carries the session's scope tags, retention is set per scope, and searches can filter by any subset.

Resolution at session start, later overrides earlier:

1. workspace default (project=<workspace.display_name>)
2. .ko/scope.yaml at the repo root (per-branch overrides allowed)
3. KO_SCOPE env var
4. --scope CLI flag on ko (coming soon). Not yet wired on the root command, so ko --scope=... "prompt" currently errors with an unknown flag. Use KO_SCOPE to set a session's scope from the shell today.

ko scope show                                            # show the effective scope for cwd
ko scope list --category=customer                        # every scope you've touched, with use counts
ko scope drop customer=rubin                             # remove a tag
ko scope settings release=production --audit-retention=2555   # 7-year retention for prod
ko scope settings customer=rubin --audit-enabled=true         # always audit Rubin work
ko scope settings project=secrets --scope-widening-locked=true # hard wall, see below

Scope as a privacy boundary. Default behavior treats scope as a convenience filter, the agent can widen beyond the session's scope on its own VectorSearch calls. Setting --scope-widening-locked=true flips that: when a session runs in that scope, the web tier rejects any scope_mode: global or scope_mode: override with a 403, and silently constrains scope_filter to the current scope. Enforced server-side at /api/ko/rag/search, not in the agent prompt, so a model that decides to try anyway gets blocked.

Retrieval is a tool, not an injection

Cursor and Continue.dev inject retrieved chunks into every model call. Linear cost in turns multiplied by context size, even when the agent didn't need RAG that turn, and the agent can't reason about why text appeared in its context. ko ships a VectorSearch tool the agent decides to call. You pay for retrieval only when it's used, and the chunks come back as tool output the agent can cite by source.

The system prompt lists which stores are available this session (workspace, episodic, session, audit) and when to prefer VectorSearch over Grep. Grep is faster and more precise for exact symbols, VectorSearch handles the synonym queries that grep misses.

Model Context Protocol (MCP) is how IDEs and other agents connect to external tools. Ko speaks MCP in both directions: it can expose itself as an MCP server for IDEs to consume, and it can consume other MCP servers as tools.

Ko as an MCP server. Any MCP-compatible client (Cursor, Windsurf, JetBrains with MCP plugin, VS Code with MCP extension, Claude Desktop) can use Knockout as a coding backend:

ko mcp show            # pick your IDE from the list
ko mcp show vscode     # or name it: vscode | cursor | windsurf | jetbrains | claude | generic

# What 'ko mcp show generic' prints:
{
  "knockout": {
    "command": "ko",
    "args": ["mcp-serve"]
  }
}

Each IDE alias prints the config in that editor's own shape, the exact file path it belongs in and the quirks worth knowing. The IDE setup page walks all six, plus the troubleshooting for when the IDE cannot find the binary.

ko mcp-serve reads JSON-RPC from stdin, writes to stdout; logs go to stderr so they don't interfere with the protocol channel. Your IDE spawns it as a subprocess.

Ko consuming other MCP servers. Configure external servers in ~/.ko/settings.json under mcpServers. They appear as extra tools the agent can call, alongside the built-in 19.

Ko sync moves work between machines without exposing your code to the server. Snapshots are encrypted locally before upload with a key only you hold; the server stores opaque blobs and cannot read your code.

ko sync push                # encrypt the working tree and upload
ko sync pull [snapshot-id]  # download and decrypt a snapshot (latest if omitted)
ko sync snapshots           # list available snapshots

# Also as slash commands inside the TUI:
/sync push
/sync pull
/sync list

The encryption key is derived from your vault password. Lose the vault password and there is no recovery, the snapshots are unreadable. Set a vault password at /dashboard/settings; it's never sent to the server.

Snapshots skip .git, node_modules, .next, __pycache__, vendor, .ko, .venv, dist, build, .cache, target, and binary artifacts (.exe, .dll, .so, .pyc, etc.).

Pipeline configs and session messages are also vault-encrypted on the server if you've set a vault password. When you open the dashboard, you unlock the vault once per browser session (1-hour rolling idle TTL, 12-hour absolute cap) to view or edit them.

Commands typed inside the TUI, starting with /.

106 project templates that aren't rigid starters. An interactive wizard at /dashboard/templates asks about your business, audience and style, then generates a bespoke project design. The result is a template ID (e.g. tp_abc123) you hand to the CLI:

ko build tp_abc123  # fetch the configured template and start a session

Twelve categories: business, e-commerce, SaaS, blogs, community, education, health, productivity, creative, food, real estate and nonprofit. Each template carries several variants, so the wizard's answers change what gets built rather than just which starter you cloned.

All ko config lives in ~/.ko/settings.json (global) and optionally .ko/settings.json (project-local, overrides global). Open in your $EDITOR:

ko config

Known keys:

Note: the older defaultModel key is no longer honored. Model picks are session-scoped and stale persisted values are wiped on startup. Pass -m or use /model instead.

{
  "trustedDirs": [
    "/home/me/work/project-a",
    "/home/me/work/project-b"
  ],
  "autoAllow": [
    "Read", "Glob", "Grep",
    "Bash(ls)", "Bash(cat)", "Bash(git)",
    "Bash(pwd)", "Bash(which)", "Bash(echo)"
  ]
}

Ko has multiple layers of defense to make sure you never pay for work you didn't authorize, or, conversely, that OpenRouter never bills us for requests whose cost we can't recover from you. Practical rundown of how they interact:

ESC cancellation

Hit ESC in the TUI at any time. The client POSTs to /api/ko/sessions/:id/abort without dropping the SSE socket. Server-side, the per-turn AbortController fires, the in-flight provider request is aborted, and you're charged only for the tokens that actually streamed before the abort, never the full budget of what the model would have generated.

A synthetic "[Turn cancelled by the user. Abandon any partial work above…]" marker is appended to the conversation so the next turn doesn't silently continue the cancelled task. If you then ask an unrelated question, the model treats it as fresh.

Live cost ticking

The Session $ counter in the status bar updates roughly every 750ms while a model is streaming rather than at end of turn, so you can watch spend accumulate on a long call and hit ESC while it still matters.

Hard per-call wallet cap

Before every fightclub-billed call we estimate the worst-case cost (input tokens plus the step's maxOutputTokens, or 32k default) and refuse to start the request if it could exceed your wallet balance. This prevents the bad case where OpenRouter bills us for tokens that atomic chargeUsage then refuses to charge you. Applied to both single-call and multi-model steps.

Idle watchdog

The CLI sends a heartbeat ping every 30 seconds while connected. If the server goes 90 seconds without any client activity (heartbeat, message, tool result, …) while a turn is in flight, it aborts the turn. Catches network drops, laptop sleep and browser refresh, anything that would otherwise leave the agent loop billing into the void.

--npa: no permissions asked

--npa turns off every permission prompt for the run. Each tool call and each shell command is auto-approved with no confirmation, so the agent can write files, run Bash and touch anything in the working directory without stopping to ask. It is the same auto-approve behavior -p / --print already uses for non-interactive runs, exposed as its own flag.

Use it only where you accept the blast radius, a scratch directory, a container, a CI job you already trust. On a real working tree it removes the one gate that stops a confused model from running a destructive command. The billing caps above still apply, but the human check-in does not. Leave it off for anything you would want to see a prompt for.

Inside the TUI (internal/ui2, the only shipped front-end):

Every command the binary answers to, alphabetically, with the section that explains it. Root flags live in Sessions and Cancellation & billing safety; slash commands have their own section.

Environment variables: KO_TOKEN_FILE (preferred token source for CI), KO_SCOPE (set the session scope from the shell), KO_QUIET (suppress the workspace nudge). KO_API_TOKEN still works and prints a deprecation warning; don't reach for it in new setups.