Install — auto-model-router

Installing

No separate Bun install is needed for the embedded path. The standalone serve binary bundles Bun.

Via npm (recommended)

npm install -g auto-model-router

Then add the shipped extensions to omp's ~/.omp/agent/config.yml ($PI_CODING_AGENT_DIR/config.yml when that env var relocates the agent dir):

# ~/.omp/agent/config.yml
extensions:
  - auto-model-router/omp-extension/router-embed.ts
  - auto-model-router/omp-extension/router-toast.ts      # optional: chosen-model toasts
  - auto-model-router/omp-extension/router-configure.ts  # optional: /router command

From the repo (cross-platform installer)

bun tools/install.ts

It wires the extensions into omp's ~/.omp/agent/config.yml, backing up the previous file first. It is idempotent. Use --no-toast --no-configure for only the required embed extension.

From the marketplace

This repo doubles as its own marketplace. Add it as a source, then install:

omp plugin marketplace add drewappling/auto-model-router
omp plugin install auto-model-router@auto-model-router

Or in the TUI: /marketplace add drewappling/auto-model-router then /marketplace install auto-model-router@auto-model-router.

As a Pi package

pi install npm:auto-model-router
# or from git:
pi install git:github.com/drewappling/auto-model-router

Setup — the OpenRouter key

There is exactly one OpenRouter key on the machine, owned by omp. Once you have run /login openrouter inside omp, auto-model-router borrows that key with no config and no second copy to rotate or leak. Alternatively set OPENROUTER_API_KEY in the environment, or openrouter.apiKey in config.yml.

The catalog and the config command work keyless; only dispatch needs a key.

Available models & guardrails

The router never ships a hand-curated model list. When an OpenRouter key is configured it fetches the key-scoped catalog (GET /models/user) — the exact set of models that key is entitled to under your account's active guardrails, provider preferences, and data policies — and routes only within it. Keyless, it falls back to the public catalog for pricing and capability discovery, but dispatch still needs a key.

This means your OpenRouter guardrails — model and provider allowlists, budget limits, Zero-Data-Retention and privacy rules — are the router's outer boundary: a model your key cannot reach is never a routing candidate. The catalog is refetched in the background every few minutes, so tightening or relaxing a guardrail is picked up without a restart.

Narrow guardrails still route. If a guardrail shrinks the eligible set so far that a complexity tier's quality floor admits nothing, adaptiveTierFloors (on by default) relaxes that tier's economic envelope to the best available models rather than leaving it empty — so the router keeps working on a tightly restricted key instead of stalling on the cheapest tier.

Activating it

After installing, restart the omp session (extensions load at session start), then run /model and pick auto-model-router/auto.

Note on updates. The embedded router is long-lived per omp session and reads its config and code at boot. Config changes to hot-reloadable knobs apply live; changes to the listening socket, the OpenRouter client, or the agentdox bridge require a session restart.

Standalone (Hermes / any OpenAI-compatible client)

auto-model-router serve --port 8788

Register it as a plain OpenAI-compatible provider pointing at http://127.0.0.1:8788/v1. No API key is enforced unless you set server.apiKey.

Configuring behaviour

Every routing lever lives in $AUTO_MODEL_ROUTER_HOME/config.yml. See the configuration reference for the knobs and their shipped defaults.