TotallyHot / Arc Router

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:

shell
$ 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.

shell
$ 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

shell
$ 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
# 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.

Where to go next