Brick: The LLM Router That Skips the Cascade and Still Cuts Your Bill

Most teams solve "which model should answer this prompt" one of two ways.

Pick one strong model and pay frontier prices for every request, including the ones a 9B open-weight model could handle blind. Or build a cascade: try the cheap model first, escalate on a low-confidence signal, and pay for every miss in tokens and latency.

Brick, from Italian inference provider Regolo.ai, is a third option. It reads a prompt once, scores it against a pool of models across six capability dimensions, and picks a single backend in one shot: no retries, no escalation ladder. Just model: "brick" dropped into an OpenAI-compatible call.

It's a young project with a real, published paper behind it: single digits on GitHub stars as of this writing, one CLI release tag, and a couple of distribution channels still marked "pending" in its own README. Here's what's actually going on under the hood, plus a benchmark nuance worth understanding before you cite the headline number.

What Brick Actually Routes To

Brick sits in front of a pool of models you define, then dispatches each incoming query to whichever one is the cheapest that can still get the answer right. The project frames three situations where that's worth doing:

• You already run several models and want each query landing on the right one instead of a manual pick.

• You're paying for Claude Code or Codex at frontier rates and want easy turns to land on a cheaper model automatically.

• You want one endpoint in front of a mixed pool of OpenAI, GLM, DeepSeek, Kimi, and Qwen models instead of wiring each one up separately.

The default shipped config points every backend at Regolo's own API, but the pool is swappable. Anything that speaks the OpenAI chat-completions format can join.

How the Routing Decision Actually Gets Made

This is the part worth reading the source for, because the README summary undersells how mechanical it is. Every text query goes through two classifiers before a single token gets forwarded anywhere.

Capability vector. A ModernBERT classifier scores the query across six dimensions: coding, creative synthesis, instruction following, math reasoning, planning/agentic behavior, and world knowledge. The output is a soft probability distribution over those six, not a hard label.

Complexity score. A separate Qwen3.5-0.8B model with a LoRA adapter buckets the query into easy, medium, or hard. In the shipped config this runs as a remote call against Regolo's brick-complexity-pro endpoint rather than a local model.

The objective. Every model in the pool also has a fixed six-dimensional skill vector plus a cost weight. Brick computes J_m = D_m + β·a_m for each candidate, where D_m is the distance between the query's capability vector and that model's skill vector, and a_m is a normalized cost penalty.

It picks the model with the smallest J_m. That's the whole decision: one geometric comparison, argmin over the pool.

A separate r knob, ranging from -1 to 1, slides the whole pool between these two poles. Toward -1 favors the cheapest capable model; toward 1 favors the strongest one.

The paper's routing math behind that knob has more moving parts than a single weight, with separate calibration branches for the cost and quality directions. At the API level, though, it's just one number you set at deploy time. The router's own config file, pulled straight from the repo, shows what the pool actually looks like:

models:
  - model: "qwen3.5-9b"
    skill_vector: [0.714788, 0.511538, 0.810109, 0.912146, 0.577072, 0.179876]
    use_reasoning: false
    cost_weight: 0.10
  - model: "deepseek-v4-flash"
    skill_vector: [0.820939, 0.657845, 0.863112, 0.934963, 0.62055, 0.488518]
    use_reasoning: false
    cost_weight: 0.40
  - model: "kimi2.6"
    skill_vector: [0.904272, 0.751595, 0.87018, 0.943892, 0.641863, 0.344074]
    use_reasoning: true
    reasoning_effort: "medium"
    cost_weight: 0.60

Two more blocks sit on top of the math for manual overrides, both documented in apps/router/README.md. keyword_rules in override mode hard-forces specific queries to a named model regardless of what the classifiers say.

The shipped default sends anything containing "debug," "refactor," or "write a function" straight to kimi2.6. A bias mode nudges one capability dimension up without forcing a decision, useful for tilting language-specific queries toward the coding axis.

Multimodal input skips the whole pipeline. Images and audio get preprocessed through OCR or Whisper-compatible speech-to-text first, then either routed as extracted text or forwarded straight to a vision model.

Claude Code and Codex Get a Dedicated Integration

This is where Brick is clearly aiming most of its early adoption. Running brick claude on wires an ANTHROPIC_BASE_URL override into ~/.claude/settings.json and starts a local router.

A new brick-claude option shows up in Claude Code's /model picker, sitting next to the built-in opus/sonnet/haiku aliases rather than replacing them. Five modes control the cost/quality trade-off, and they map directly onto Claude Code's existing thinking-effort slider:

The README confirms the two end tiers precisely: eco always picks haiku, max always picks opus. It doesn't spell out the exact easy/medium/hard-to-model mapping for the three tiers in between, only that they sit on a cost/quality gradient.

Selecting a native model name in the picker bypasses Brick entirely and forwards the request unchanged. That gives you an easy escape hatch if the router ever picks wrong.

A brick claude status command opens a live dashboard showing routed-by-model counts, per-model reasoning-effort distribution, the classifier's easy/medium/hard mix, and an estimated savings percentage against an all-opus baseline.

Codex support exists too, gated as beta, sharing the same five modes and status view. The two share host port 8000, though, so only one can serve at a time.

The Numbers, and What They're Actually Measuring

The project has a real published paper behind it: Brick: Spatial Capability Routing for the Mixture-of-Models (MoM) Paradigm, by Francesco Massa (Regolo.ai) and Marco Cristofanilli (Seeweb, where Regolo.ai is built), posted to arXiv in June 2026.

It reports results on a 5,504-query benchmark called Dataset A, spanning six capability dimensions. Each query is graded by protocol-specific checkers, an LLM judge, or both depending on the task type.

*Accuracy and per-call dollar cost are from the paper's own cost audit, priced off OpenRouter listings at evaluation time.

Latency figures marked with an asterisk are from the project's README summary table rather than the paper itself. The paper's own headline latency claim: median end-to-end latency drops from 51.2s (always-Kimi) to 22.8s (Brick at max-quality).

†The max-quality profile's cost multiple sits further down the same results table in the paper, past the section I could extract. Treat that cell as unverified rather than a claim either way.

Note also that the project's README reports its own, different, more rounded cost multiples for these same rows (1.0× / 4.0× / 6.0× / 1.5×). This table uses the paper's precise per-call dollar figures instead, since they're traceable to an actual pricing snapshot rather than a rounded illustration.

Against external baselines: Brick's low-cost profile beats FrugalGPT's 69.42% by 2.2 points at comparable cost, and its neutral profile beats Cascade Routing's 73.40% by 0.71 points.

That's the deployment-facing number: did the model Brick picked actually answer correctly. The paper is explicit that this isn't the only question worth asking.

It also defines a second metric, route-exact accuracy: does the router's pick match the literal cheapest model that could have solved the query. Queries none of the three models can solve still count against every router here, oracle included.

That makes it a stricter, cost-efficiency-facing bar than the headline number. Credit where it's due: the paper reports both metrics side by side in its main results table, not buried somewhere else.

On that stricter metric, a trivial "always pick the cheapest model" baseline scores 63.17% by definition, since the cheapest model is the correct pick on 63% of the queries. The interesting comparison is the other routers against that same bar.

Always-Kimi and RouteLLM both dispatch nearly everything to Kimi, and score only 21.28% and 21.31% route-exact accuracy despite matching Kimi's headline number. That's the paper's own evidence that neither is doing real query-level judgment.

FrugalGPT and Cascade Routing land at 31.03% and 28.96%. Brick clears 40.35% at a neutral setting and 63.17% at its cheapest profile, beating every external baseline on the metric that's supposed to be hardest on it.

One loose end worth flagging for anyone who goes digging in the repo themselves: a separate, Italian-language working file in packages/evals/baselines/RESULTS.md reports a route-exact figure for Brick of 46.37%. That number doesn't line up exactly with any of the r-settings in the paper's published table (63.17% / 48.66% / 40.35% at min/low/neutral).

That file reads like an earlier or differently-configured pipeline run than what shipped in the final paper, not a contradiction of it. If you're citing Brick's numbers for something that matters, pull them from the arXiv table rather than that file.

Trying It

The fastest path is the CLI, which self-hosts the router and wires it into Claude Code in two commands. It needs Node 18+ and Docker:

git clone https://github.com/regolo-ai/brick-SR1.git
cd brick-SR1/apps/cli && npm install && npm run build && npm link

brick claude on

For a raw OpenAI-compatible gateway without the CLI, the project's Docker image is documented but, as of this writing, still pending its first push to GHCR under the v2.1.0 tag. Once published, the documented usage looks like this:

docker run --rm -p 18000:18000 \
  -e REGOLO_API_KEY=$REGOLO_API_KEY \
  ghcr.io/regolo-ai/brick:latest

curl http://localhost:18000/v1/chat/completions \
  -H "Authorization: Bearer $REGOLO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"brick","messages":[{"role":"user","content":"Prove that sqrt(2) is irrational"}]}'

The response carries an x-selected-model header telling you which backend actually answered. A math-proof prompt should land on a reasoning-capable model; a bare "hello" should land on the cheapest one in the pool.

I'm quoting these commands straight from the project's own quickstart rather than claiming to have run them myself. With the Docker image and npm package both still pending publication, and no Regolo API key available in a sandboxed environment, there was nothing live to hit.

Where This Project Actually Sits Right Now

A few things worth knowing before you build on this. The router itself descends from vllm-project/spatial-router, an Apache-2.0 project.

Regolo's team added the six-dimension capability classifier, the complexity-score integration, the skill-distance objective, multimodal preprocessing, and the Claude Code passthrough on top. That lineage is disclosed plainly in the repo's NOTICE file, which is exactly how attribution should work on a fork.

As of this writing the repo has zero forks and a GitHub star count still in the single digits. That's normal for a project a few weeks old and not itself a signal of quality either way.

The codebase is a genuine multi-language build. Go and Rust make up the router (Rust handles ML embeddings via candle and classical ML via Linfa, compiled to shared libraries and linked through CGO), Python runs the training and eval pipelines, and TypeScript powers the CLI.

License is Apache-2.0 throughout. Whether it earns a permanent spot in your stack comes down to which problem you actually have.

If you're routing across a real multi-model pool, the paper's numbers are worth your own re-run before you trust them at production scale. If you just want Claude Code to stop burning Opus on "fix this typo" requests, the Claude-specific integration is the more immediately useful half of the project — and it works whether or not you buy the Dataset A accuracy claims at all.