Keel: Where the Local Decision Model Finally Gets a Job

By Prahlad Menon 5 min read

I’ve spent the last week writing about a strange little trend: open-source decision models — Kev, then Laya — models that don’t generate text but instead answer typed questions (choice / score / yes-no) with calibrated probabilities in a single forward pass. Interesting theory. The obvious question was: what do you actually DO with one?

Keel is the first answer I’ve seen that isn’t a demo. It puts a local decision model to work as the router inside a coding agent.

The idea in one line

Keel is a local-first macOS coding workspace (Rust + GPUI, Avid-derived UI) that bundles an editor, terminal, transcript, changes view, provider connections, and settings into one app. The twist: when you kick off a fresh task, a local Laya model decides which route/agent should handle it, and the host verifies that decision before acting on it.

That’s the whole thesis of the decision-model wave, finally wired into something real: use a small, fast, calibrated model to make a bounded choice — not to write your code, but to decide who writes your code.

Three modes, exactly one backend per decision

Keel makes the routing explicit, which I appreciate:

  • Laya (default) — runs locally through Core ML on Apple Silicon. Selects from host-prepared candidates, or abstains if it’s not confident. This is the System 1 model I wrote about: millisecond, non-autoregressive, calibrated.
  • Jev (opt-in) — the hosted closed decision model (TypeSafe). Sends a bounded decision request over the network using an existing protected credential.
  • Normal — no selector at all; just your ordinary coding harness route.

“Exactly one backend runs per decision” is the key line. And crucially: a local selector does not mean your coding worker runs locally. Keel cleanly separates who decides the route from who does the work — each coding provider keeps its own auth and model config.

The part that actually matters: host-owned permission checks

Here’s the design decision I think is genuinely smart. The selector doesn’t get to do anything. It proposes; the host checks.

  • jev_routing.rs defines the eligible route candidates and validates them.
  • The selector chooses from allowed options, and Keel checks the choice before applying it.
  • keel computer-use decide selects a prepared action ID — it does not click or type.

In other words, the model’s authority is bounded by construction. It can only pick from a menu the host prepared, and the host re-validates the pick. That’s exactly the posture you want when you let a model make decisions inside a dev environment — the same instinct behind not letting an agent run arbitrary shell just because it asked nicely. The decision model narrows choices; it doesn’t hold the keys.

How it’s built

  • Rust workspace, GPUI app. apps/keel is the entry point + local CLI.
  • crates/laya-local — the local Core ML worker integration.
  • crates/jev-core — typed decision requests + the direct TypeSafe client.
  • crates/harness — local ACP adapters and computer-use MCP discovery.
  • Connects external coding agents through the Agent Client Protocol (ACP) (external ACP agents keep their own internal tool loops — they don’t all pass through Laya/Jev).
  • There’s an embedded DeepSeek loop (agent.rs) with bounded, tool-focused selection and dispatch checks.

Build is a plain cargo build / cargo run; cargo test --workspace checks everything.

What it honestly is not (yet)

The repo is refreshingly candid, which builds trust:

  • Decision records support evaluation; automatic training is NOT implemented. It logs accepted choices, abstentions, and fallbacks so you can evaluate the selector — but there’s no self-improving loop yet.
  • “Build checks do not establish better coding outcomes.” They’re not claiming the decision model makes you a better coder — just that the plumbing works.
  • No published app releases; build from source only. Packages are ad hoc signed dev builds — public distribution still needs Developer ID signing + notarization.
  • Voice input is just macOS Dictation; no realtime voice, no cloud sync.

That restraint is the right call. The interesting claim here is architectural, not benchmark-y.

Why this is the post that ties the thread together

Kev proved you could build an open decision model. Laya proved you could make it fast and local. Keel is the first to show where it belongs in a real workflow: as a bounded, abstention-capable router sitting inside a coding agent, with a host that checks every choice.

That’s the pattern I keep coming back to — and it echoes the RF-SRC work on the clinical side: stop reaching for a giant generalist to make a small structured decision. A calibrated model that picks from a validated menu in milliseconds, and can say “I’m not sure,” is a better building block than a chat model improvising a route.

The naming saga marches on (Jev → Kev → Laya → now Keel, an app that runs two of them). But the engineering keeps maturing: from “here’s a decision model” to “here’s a decision model doing a real, permission-checked job.”

👉 github.com/codejunkie99/keel