arthai-marketplace

Arth Router: org-level model routing (team/central)

arth-router is a control-plane decision service: it picks which model, harness, and platform each task should use, with budgets, capacity pools, and a full decision audit trail, and explains why. It never proxies your LLM traffic.

Do you need it?

You are	Verdict
Single user	No. The toolkit’s built-in triage routing already picks agents/skills per task, and the router’s learned routing needs outcome history you won’t have solo. Nothing else in the Arth stack depends on it.
Team lead who wants cost governance	Yes: budgets, tiers, and capacity pools per org/project, enforced at decision time.
Org tracking “which model actually works”	Yes: decisions + recorded outcomes make routing data-driven over time.

This is the same single-user guidance as Deployment Modes; it’s a deliberate design position, not a missing feature.

Prerequisites

• Hardware: any Mac/Linux box; single process, SQLite by default. No GPU, no external services, no API keys for a local trial.
• Software: Python 3.11+ with uv (or Docker). Postgres only for the multi-seat central deployment; Helm charts exist for k8s.

Trial it locally (10 minutes)

arth-router is a private repo, ask productive@getarth.ai for read access first (separate from the plugin-repo invite).

git clone https://github.com/ArthTech-AI/arth-router && cd arth-router
uv venv --python 3.11 .venv && uv pip install -e ".[dev]"
.venv/bin/arth-router                      # REST + console on :8600
curl -s localhost:8600/health              # {"status":"ok",...}

Then route a task and read the explanation:

curl -s -X POST localhost:8600/route -H 'Content-Type: application/json' \
  -d '{"task":{"description":"refactor the payment module"},"principal":{"org":"default"}}' | jq

Gotcha: the seed policy grants tiers only to org: default. Any other org drops to the cheapest tier (everything routes to haiku), that’s governance working, not a bug. Add a grants: entry for your org.

Wire it into the toolkit (central mode)

1. Deploy the router centrally (docker compose up -d in the repo, or the charts/arth-router Helm chart with Postgres + auth).
2. Per seat, run /router-setup, it wires the env vars and the triage fast-path patch for you. The toolkit’s triage hook then consults the router first and falls back to the static routing table on any failure or timeout (2s). No regression path: router down ⇒ toolkit behaves exactly as before.
3. Optional: run arth-router-outcomes-bridge to auto-report token usage per decision back to /outcome, closing the learning loop.

How it relates to the other layers

• arth-intelligence: optional history signal, the router can read tool-score data from your dashboard’s database to inform decisions (history_source=http|file; off by default).
• arth-memory: optional org-memory constraints via an OKF tree (ARTH_ROUTER_OKF_PATH); no runtime dependency.
• Both integrations are additive and disabled by default; the router runs fully standalone.

Related

• Deployment Modes, the full single-user vs central map
• Getting Started, toolkit install order
• Measure what AI costs you, the dashboard side of cost