The Vision

Kuno is not another cloud chatbot with a web interface. Kuno runs on hardware you own, listens to you, replies with a voice - and quietly coordinates a team of small, specialised AI models in the background. This chapter explains the idea before you plug in a single cable.

Before this chapter: You know you want to build something with local AI models, but the architecture is still unclear. By the end: You understand what Kuno is, why running locally is the right call, and how a mini-organisation of specialists beats a monolith.

What is Kuno?

Kuno is a voice-controlled home assistant - but not the kind you plug into a wall socket and forget about. It lives on four devices, each with its own role. You ask a question, it thinks, coordinates internally, and answers you through a small robot with a microphone array and speaker. Not a single request leaves your local network.

The name "Kuno" is intentional: not an acronym, not a product brand - just a name, because a system that speaks with you deserves one.

Technically, Kuno is a multi-agent system. At its core runs a large language model (Nemotron-3-Nano-30B) acting as a Concierge: it receives your input, decides which specialist to call, and synthesises the result. The specialists are smaller 4B models, each trained for exactly one task - research, code, classification, proactive notifications.

The most important difference from commercial solutions: Kuno has no subscription price, no privacy fallout, and no rate limits. It runs as long as you leave it on.

Why local?

Two years ago "local" was synonymous with "slow and unusable". That has fundamentally changed. Models like Nemotron-3-Nano-30B or Qwen-2.5-Coder-7B reach cloud-level performance on modern hardware - at a fraction of the ongoing cost.

Privacy is the obvious reason. Everything you tell a cloud model leaves your network. Conversations about health, finances, plans - the provider logs them, may train on them, and operates under a foreign jurisdiction. Local means the data stays on your hardware.

Latency is the second reason. An API round-trip to a US server costs 300-800 ms before the first token arrives. A local model on the DGX Spark responds in under 100 ms. For a voice system you use every day, the difference is noticeable.

Sovereignty is the third reason. Cloud APIs change their pricing, retire models, and update their policy frameworks. Your local model runs tomorrow exactly as it does today. You decide which model version to use - and when to upgrade.

The cost is lower than you think. The DGX Spark costs around $4,000 once. A single heavily-used cloud API licence can easily run $100-200 per month. Amortisation hits within two years of daily use.

The goal with Kuno is not to reject cloud services outright. Some tasks (web search, external APIs) inherently require network access. But inference - the actual thinking - happens locally.

The mini-organisation

Why not just use one big model? That is the natural question, and the answer is: because specialised teams are more robust than solo performers.

A generalist model has to be simultaneously good at understanding natural language, researching, writing code, summarising, and planning. That forces compromises. A model trained exclusively on code completion is simply better at that task than a same-size generalist.

Kuno therefore forms a mini-organisation - five roles, coordinated by the Concierge:

       ┌────────────────────┐
       │    You (voice)      │
       └──────────┬─────────┘
                  ↓
       ┌────────────────────┐
       │  Concierge (30B)   │  ← interprets intent, routes
       └──┬───┬───┬─────────┘
          ↓   ↓   ↓
     Auxiliary  Research  Code
       (4B)      (4B)     (4B)
          ↓        ↓        ↓
            Notifier (proactive)

Concierge is the brain. It understands your request, picks the right specialist, and synthesises the reply. It runs on the Nemotron-3-Nano-30B model, hosted on the DGX Spark, orchestrated from the Mac Mini.

Auxiliary quickly classifies inputs when the Concierge is uncertain. Small model, low latency.

Research can search documents, query local knowledge bases, or - when configured - consult external sources.

Code writes, explains, and debugs code. Runs on a specialised code model (e.g. Qwen-2.5-Coder).

Notifier is the only agent that acts proactively: it monitors events and speaks up when something relevant happens - without you asking first.

This structure makes the system maintainable. If you want to try a better code model, you swap out one specialist without touching the others. If the Research agent is slow, you can debug it in isolation.

In the next chapter you will see the hardware stack in detail: which four devices make up Kuno, what each one costs, and why the division of responsibilities looks the way it does.