Bootstrap
From nothing to a routed request.
Install it, pull the benchmark tables, point a client at it, and read what the router decided. Half an hour if you build from source, ten minutes if you don’t.
1. Prerequisites
Arc Router is a .NET application with a desktop GUI built on Microsoft platform components. Have the following in place before you start.
- Windows
- Windows 10 version 1809 or later, x64. The GUI links against WebView2 and the Windows App SDK, which are Microsoft platform prerequisites obtained from Microsoft.
- .NET SDK
- Only if you are building from source. The installer ships self-contained builds, so no runtime is needed to just run it. The pinned target lives in
src/Directory.Build.props. - Git
- To clone the repository and to send patches back later.
- Provider credentials
- Keys for whichever backend models you intend to route to. They are stored through the router's secrets-at-rest path, not in plain configuration files.
2. Install, or build
The quickest path is the 1.0.0 installer. It is a pre-release and it is not code-signed yet, so Windows will warn on first run — the download page explains what you will see and how to verify the file first.
Building from source instead:
$ git clone https://github.com/davidpizon/TotallyHot-ArcRouter.git
$ cd TotallyHot-ArcRouter/src
$ dotnet restore TotallyHotArcRouter.slnx
$ dotnet build TotallyHotArcRouter.slnx -c Release
# optional: run the suites before you trust the build
$ dotnet test TotallyHotArcRouter.slnx
The solution splits into the router itself, the GUI and its admin, charts, console and telemetry modules, the sandbox, and a test project alongside each. If a project name has moved since this page was written, src/README.md is the current map.
3. First run
If you used the installer, the router is already running — it is registered as a
LocalSystem service that starts automatically, so it is up before you open
the GUI. If you built from source, launch it yourself. Either way, first start creates
the local application data directory where the benchmark database will live.
$ TotallyHotArcRouter
local data ... %LOCALAPPDATA%\TotallyHot.ArcRouter\
database ..... coderouterbench.db
benchmark .... empty, sync required
4. Sync the benchmark data
Arc Router evaluates against CodeRouterBench, the task-by-model benchmark published by Zhou et al. on Hugging Face under the MIT license. It is their dataset, consumed here as an external dependency. Pull it locally in whichever of the three ways suits you.
From the GUI
Open Governance, then Benchmark Data, and start the sync.
From the command line
$ TotallyHotArcRouter --sync-benchmark-data
From an MCP client
With the MCP endpoint enabled, call the sync_benchmark_data tool. This is the
route to take if you want an agent to keep the data current without a human in the loop.
5. Verify the database
After a successful sync the local SQLite file holds the following tables.
- benchmark_id_results
- 9,999 in-distribution tasks across 8 models, being the probing and id_test splits combined.
- benchmark_ood_results
- 176 out-of-distribution tasks across the same 8 models.
- benchmark_id_tasks, benchmark_ood_tasks
- Task metadata for each split.
- benchmark_models
- Canonical backend model identities and their USD pricing.
The sync verifies what it writes. If the counts you see differ, read data/README.md and the SQLite migration plan before you go digging in the database by hand.
6. Route a request
Add at least one backend provider and its credentials, then point a client at the router. The system proxy is the quickest path: existing coding agents keep their configuration and their traffic starts flowing through the router. The MCP endpoint is the alternative when you want tool-level rather than transport-level integration.
Send "model": "auto" to opt a request into routing. A request naming a real,
servable model is always served exactly that model — the router never substitutes a model
you explicitly named. An unrecognised name, an administratively stopped model, or an
unhealthy provider fall back to the same decision as auto.
7. Read the decision
Every response carries three headers reporting what actually happened, so the routing decision is inspectable without opening the GUI.
# response headers on every request, streaming or buffered
X-ArcRouter-Requested-Model ...... auto
X-ArcRouter-Routed-Model ......... backend-3
X-ArcRouter-Substitution-Reason .. AutoSelect
Substitution-Reason is one of None, AutoSelect,
UnresolvedName, ModelStopped, CircuitOpen, or
Failover. In the GUI, the full vote breakdown for each decision — every
voter's pick and weighted score, and the argmax — is logged alongside it.