The harness that grows itself,
under authority it cannot rewrite.

Open Max is a self-extending Rust agent harness for coding in the terminal. One static binary. Seven tools. About 1,200 frozen prompt tokens. The agent builds its own bench; you stay on approvals and judgment.

$git clone https://github.com/Max17190/open-max && cd open-max && cargo build --release -p open-max-tui
View source ↗ Quickstart ↓
openmax · my-project
❯ add a tool that searches our docs index

⚙ write_file .openmax/tools/docsearch.toml · ok · 12ms
▲ new tool source needs approval: .openmax/tools/docsearch.toml
  [y] Allow once   [a] Allow for run   [n] Deny
• toolbox changed: re-frozen with 8 tools, 3 skills - docsearch
⚙ docsearch "approval walls" · ok · 31ms

The docs index covers approvals in governance.md; wiring the
new tool into the review skill now.
enter queue · esc cancelmodel: local · ctx 12% · ask
01

Small by default.

Seven built-in tools and a short frozen prompt. Token cost is design: /context itemizes every token you spend, and anything that would bill every request for capability the turn never uses stays out of the core.

02

Capability is a file.

The agent drops a TOML tool, a SKILL.md, a hook, or a prompt template as a plain file. The harness verifies it, explains any problem with reasons, and re-freezes the toolbox the moment a change lands. A tool the agent writes is a tool it uses on its very next step, with no restart.

03

Authority is not.

Projects are trusted before any turn runs. Mutating tools wait for approval; hooks and permission grants wait for a human's openmax --approve; a hash-chained ledger records who blessed what. No tool and no in-session path can loosen the rules.

Every harness feature is a fossil of a model limitation. The models improved. The features remained.

Open Max makes the opposite bet: delete the fossils, shrink the core to what must stay fixed, and let every capability live in plain files the agent writes, under rules it cannot rewrite. Growth is only safe when the thing that grows is separate from the authority that judges it.

Need something the core does not ship?

External service or specialized capability A CLI-backed TOML tool plus an on-demand skill
Reusable workflow or command A SKILL.md package or a prompt template
Guardrails and policy Hooks and permission rules, human-approved, failing closed
Another frontend entirely The versioned --stdio JSONL protocol

Quickstart

# build git clone https://github.com/Max17190/open-max cd open-max && cargo build --release -p open-max-tui # point it at any OpenAI-compatible endpoint · ~/.openmax/settings.json { "base_url": "http://localhost:8080/v1", "model": "your-model", "context_tokens": 128000 } # run ./target/release/openmax

Then let the harness explain itself: openmax --check validates every extension file with reasons, and openmax --spec prints the authoring contract for tools, skills, hooks, permissions, settings, and the stdio wire.