The router is the product
OpenSquilla puts a small machine learning model in front of your large ones. Before each turn, a local classifier called SquillaRouter reads the request and sends it to the cheapest model that can handle it. That single decision, repeated every turn, is what the project means by "same budget, more capability, better results."
Most agent frameworks treat model choice as a config value you set once. OpenSquilla treats it as a live routing problem. The README calls the tool a "token-efficient, microkernel AI agent," and the microkernel framing is literal: routing, persistent memory, a layered sandbox, built-in web search, and on-device embeddings all hang off a single shared turn loop rather than a stack of independent services.
One loop, many front doors
The design choice that follows from the microkernel is that every entry point runs the same loop. Whether a request arrives from the Web UI, the CLI, or a chat channel, tool dispatch, retries, and decision logging behave identically. You are not maintaining three slightly different agents that drift apart over time. You are maintaining one, exposed through several doors.
Those doors are plentiful. Feishu, Telegram, DingTalk, QQ, WeCom, Slack, and Discord all work from the base install. Matrix needs an opt-in extra, and Matrix with end-to-end encryption needs another. The provider side is just as broad: a pluggable layer speaks to TokenRhythm, OpenRouter, OpenAI, Anthropic, Ollama, DeepSeek, Gemini, Qwen/DashScope, and more than twenty other LLM providers with no change to your code or config schema. The router can therefore choose across vendors, not just across one vendor's model tiers.
The router runs on your machine
SquillaRouter is not an API call to some routing service. It ships as on-device model assets, pulled through Git LFS from src/opensquilla/squilla_router/models/, and it runs on ONNX Runtime and LightGBM with NumPy and tokenizers alongside. That is why the install carries real system dependencies. On Windows the bundled ONNX runtime wants the Visual C++ redistributable, and on macOS LightGBM may want the system OpenMP library.
The README is honest about the failure modes. If those native libraries are missing, you see a DLL load failed message or a libomp.dylib load error, and OpenSquilla keeps running with direct single-model routing until you install them. That fallback matters: the router is a preference, not a hard dependency. The recommended install profile bundles it, a core profile omits it, and a separate --router disabled flag keeps the dependencies installed but turns routing off at runtime. You can adopt the token-efficiency story incrementally, or skip it and still have a working agent.
Traffic as training data
The most interesting claim is not in the feature list. It sits in the technical report shipped alongside 0.5.0 Preview 1, "Agentic Routing: The Harness-Native Data Flywheel." The argument there is that a harness-native router turns everyday agent traffic into a self-improving data flywheel. Every turn the agent handles is, in effect, a labeled example of which model was cheap enough and good enough for that request. A router that lives inside the harness can learn from that stream directly, instead of leaning on a fixed rule set someone hand-tunes.
Whether that flywheel actually compounds is the open question, and the version numbers are worth reading plainly. OpenSquilla is at 0.5.0 Preview 4. Windows desktop builds are unsigned, so SmartScreen will flag them. This is preview software with a specific, testable thesis: that a cheap local classifier choosing among twenty-plus providers, learning from its own traffic, beats paying premium-model prices on every turn. At roughly six thousand stars a couple of months after its first commit, the repo suggests the thesis is landing with the people best placed to check it.
GitHub: https://github.com/opensquilla/opensquilla
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)