<aside> 🌏 한국어 (대한민국 기준) 원문 / Korean (South Korea) original — 판단을 LLM에서 떼어내다 — CLI 에이전트에 System One 모델을 앉힌 기록

</aside>

<aside> 📚 Part 2 is out — Running Actors Inside an AOT Binary — How agent-one's Bot/Loop Pair Actually Behaves · the same agent rebuilt on an actor pair, and where these Jev decision points ended up.

</aside>

<aside> 🎯 In three lines — ① Ask an LLM to make the decisions inside an agent loop (web or files? run this command or not? is this draft good enough?) and you get something slow and wobbly. ② I put a classifier that returns typed judgments plus calibrated confidence — TypeSafe's Jev — in that seat instead. ③ Smart-mode overhead went from 15 seconds to 0.9. But the real gain isn't speed: it's that code can now decide whether it's allowed to act on its own.

</aside>

Written for developers who have built an agent loop themselves. Every measurement here comes from session logs on one low-power mini PC running models on-device. It is not a benchmark.

<aside> 📌 This article describes the state of things on 2026-09-22 (written 2026-09-23). The subject is agent-one v0.3.27 (AgentZeroLite repository, branch feat/agent-one, still under development), and every measurement below comes from session logs of 2026-09-22. TypeSafe's Jev went into early access that same day — so this is a record of wiring something up on its launch day, and the API shape, pricing and model behaviour may all change. Read the numbers as a snapshot. All external sources were checked on 2026-09-22.

</aside>

1. Why I ran this experiment — two models on one mini PC

Let me concede something first. If you only work with frontier models, half of this article has no reason to exist. When the answer itself lands in a couple of seconds, bolting on a second service to save 0.3 seconds of routing is over-engineering. That time is noise.

My setup is not that.

I run two models on-device on a single low-power mini PC (roughly Apple M4 Mini class). The fast one is gemma-4-e4b; the strong one is qwen3.8-27b. The ceiling is my own memory and power budget, not a cloud quota. Thirty seconds is not noise here.

I started out trying to do it all with gemma

If one small model can carry the whole thing, that's the cleanest answer. It didn't work — and what stopped it was the hardware, not the quality.

One thing I learned along the way: running several instances of the same model on one box does not make the work finish sooner. Run them in parallel and they split a memory budget that was already tight, which pushes every instance off its optimal configuration. Instead of getting faster, it gets unstable. The smaller the machine, the more it pays to optimize one model properly and use them in sequence.

So I changed direction. Instead of multiplying one model, I kept two models with different temperaments and woke exactly one at a time.

Which left one empty seat: who decides when to wake it

Splitting the roles just moved the problem one square over. Who judges when the strong model should be woken?

Hand that judgment to gemma and the judgment alone costs another dozen-plus seconds — the decision eats the saving it was meant to produce. Ask the human every time and it isn't an agent any more. Hard-code it as rules and it can't read the shape of the request.

In an agent where two LLMs collaborate, the seat that was actually empty was the referee's. I was chewing on exactly that when Jev appeared (2026-09-22): a model that generates no text and returns a judgment in 0.3 seconds. It was the precise shape of the hole I had. So I wired it in — partly to get a taste of the technology.

<aside> 🧪 What this article is really testing — can two small on-device LLMs plus one classifier add up to an agent that's actually usable on modest hardware? This is a deeply personal test: one machine, one model pairing, one observer. Do not read it as a generalizable benchmark.

</aside>