Olondunge: Model Self-Allocation Across Claude Code, Codex, and Grok

What ships

Several MCP servers already call agent CLIs, use the Grok CLI as a worker, and let the calling model pick the model and effort. Olondunge does those things too. This guide focuses on how it allocates when those fields are blank, and on its verifier, which sits on a different lane by default and is refused the producer's conclusion.

Type tri: <idea> and the prompt is compiled into a full execution contract in the same turn: requirements, work graph, allocation, blind verification, and a release verdict. On Grok, use tri-grok, because Grok discards hook output. Text that does not open with a trigger reaches grok unchanged.

Requirements are Python 3.11 or newer and uv; at least one of Claude Code, Codex CLI, or the Grok CLI, installed and logged in; and Linux or macOS. Each lane uses that CLI's own login and subscription. Olondunge never sees or stores credentials. Version 0.1.0 is the first public release. Development status is Alpha. The license is Apache License 2.0. The public repository is github.com/mdalexandre/olondunge.

Self-allocation against what is actually up

Ask in plain language, or be explicit:

Plan this refactor with alloc_plan, run the implementation on codex at high effort, then have claude verify it blind against the acceptance criteria.

A packet is a JSON object. Only objective is required. lane, model, effort, and verifier_lane are the self-allocation fields. Leave them out and Olondunge picks the cheapest capable lane that is up, and a verifier on a different lane.

{
  "objective": "Find why tests/test_parser.py::test_unicode fails and propose a patch.",
  "lane": "codex",
  "model": "gpt-5.5",
  "effort": "high",
  "verifier_lane": "claude"
}

effort takes the lane's own values, which alloc_status lists, or the portable values top (strongest) and max (the lane's max, else its strongest). tri_models lists Codex efforts per model. An effort a lane cannot take is refused with the valid values. alloc_plan explains every lane it did not choose in dropped.

Workers are read only unless the packet permits a write tool. They write in their own scratch directory, or in workdir when authority_ceiling carries write-workdir. Deny rules the packet cannot lift block sudo, recursive deletes, pushes, hard resets, docker, and systemctl.

Default home is ~/.olondunge. Job records live in ~/.olondunge/jobs/<job_id>/. One ledger row per finished job is written to ~/.olondunge/ledger.jsonl. Background jobs survive a server restart.

Blind verification that refuses the producer's conclusion

alloc_verify(packet, candidate) refuses a candidate carrying a verdict, conclusion, score, confidence, or reasoning. It keeps the original inputs, inlines the artifact, and demands a final VERDICT: PASS | FAIL | BLOCKED line that alloc_collect turns into verdict. When only one lane can verify, it runs in a fresh session on the producer lane and says so in warnings.

That refusal is the rule this server implements. It is not a claim that no other project ever asks a second model to look at work.

Each lane isolates its worker as far as that CLI allows, and no further. Claude workers run with --setting-sources project, no MCP servers, only the tools the packet permits, and no subagent tools. Codex workers run with a scratch CODEX_HOME (the user's auth.json is linked, never read), so the user's Codex MCP servers and hooks do not load.

Because a worker may load Olondunge itself, every worker carries OLONDUNGE_DEPTH, and a server started inside a worker refuses alloc_dispatch, alloc_verify, and alloc_call instead of recursing. alloc_plan still answers.

Install

Install from git, then preview the files setup will write:

uv tool install git+https://github.com/mdalexandre/olondunge
olondunge setup all --dry-run   # see exactly what will change
olondunge setup all             # or: setup claude | setup codex | setup grok
olondunge doctor

setup registers the server with each installed host through its own mcp add command, copies both skills into the host's skills directory, and adds the tri: hook for Claude Code and Codex. The files setup writes itself (the Claude Code settings.json, the Codex hooks.json, and any skill it replaces) are backed up first under ~/.olondunge/backups/<timestamp>/, and a file that does not parse is left alone. Restart the host afterwards.

The repository is also a plugin for all three hosts. The plugin launches the server with uvx from the release tag matching the plugin version, so uv and network access are needed the first time it starts. Its tri: hook runs whatever python3 is on PATH, which must be 3.9 or newer. Use either the plugin or olondunge setup for a host, not both, or the tri: contract is injected twice.

# Claude Code
claude plugin marketplace add mdalexandre/olondunge
claude plugin install olondunge@olondunge

# Grok
grok plugin install mdalexandre/olondunge

# Codex (plugins carry skills and MCP servers; run olondunge setup codex for the tri: hook)
codex plugin marketplace add mdalexandre/olondunge
codex plugin add olondunge@olondunge

With both skills installed, every tested host ran the contract: Claude Code (Sonnet at low effort and Opus), Codex (GPT-5.5 at low effort), and Grok. Not every run put the routing line first. Without the skills, Sonnet refused the contract as injected text.

Limitations

These limits are in the README.

• Codex runs a new hook only after you trust it once. Start codex interactively: it opens “Hooks need review”, where you can review the Olondunge UserPromptSubmit hook and trust it. Later, /hooks shows the same list. Until then codex exec skips the hook without saying so, and a tri: line reaches the model as plain text.
• Grok workers use your Grok login and configuration. The Grok CLI has no switch to skip user MCP servers or its Claude compatible instruction files, so a Grok worker can see the same servers and instructions your own Grok sessions do. Write, edit, and shell tools are denied unless the packet permits them.
• Use either the plugin or olondunge setup for a host, not both, or the tri: contract is injected twice.
• Requirements name Linux or macOS, Python 3.11 or newer, uv, and at least one logged-in agent CLI.
• Each lane isolates its worker as far as that CLI allows, and no further.
• Because a worker may load Olondunge itself, every worker carries OLONDUNGE_DEPTH, and a server started inside a worker refuses alloc_dispatch, alloc_verify, and alloc_call instead of recursing.

The name

Olondunge is an Umbundu word, from the Ovimbundu people of central Angola. An 1885 vocabulary of the language (W. M. Sanders) glosses the root olundunge as “sense, wits”, and the Umbundu translation of Article 1 of the Universal Declaration of Human Rights uses olondunge for “reason and conscience”.