Switchboard

Frontier AI models are the most expensive part of how I build, and most of what I was sending them didn’t need them. Switchboard is a command-line tool (llmr) that decides which model handles each task.

Three tiers

Tier	Model	Runs on	Handles
T0	Claude	Cloud	Specs, architecture, code review, hard debugging
T1	Qwen 3.5, 9B	My laptop	Writing code against a spec and tests, refactors
T2	Qwen 2.5, 3B	My homelab	Commit messages, PR descriptions, devlogs, questions about my code

If the laptop model fails the same task three times, the work goes up to Claude.

How it decides

You describe the task in plain English. Switchboard turns that description into an embedding and compares it with example tasks for each tier, then picks the closest match. No extra AI call is needed to choose.

When the top two matches are too close to call, it says so instead of guessing.

A knowledge base of my own work

The homelab keeps a searchable index of my repos, my notes, and a log of past mistakes. Any tier can ask it questions, so “how is this already set up?” gets answered by a small local model instead of Claude.

The mistake log is the part that pays off most. When something costs real debugging time, it gets written down with the problem, the cause and the fix. New work checks the log first, so the same mistake isn’t paid for twice. The first entry: a newer 4B model that looked better on paper spent 45 to 90 seconds loading from the homelab’s spinning disk on every call, so the older 3B model stayed.

Choices I made

• No vector database. SQLite and brute-force search are fast enough at a few thousand entries, and a database server would compete for the homelab’s 8 GB of RAM.
• Reindex every 10 minutes, skipping unchanged files, so new notes and lessons show up without a manual step.
• Built into my editor workflow. A Claude Code skill tells Claude when to check the mistake log and when to hand work down a tier.

Built with Python, Ollama, semantic-router, nomic-embed-text and SQLite.