The friction
I run coding agents all day. Not as a curiosity — as how I actually work. At any given moment I've got two or three of them going: Claude Code on the refactor, Codex taking a swing at a stubborn test, OpenCode or GLM on something exploratory. Each one in its own terminal. Each one, constantly, asking me a question.
Every one of those questions is the same gesture: stop typing, grab the mouse, find the right window among the pile, click into it, and hit a single key — y to approve, n to reject, or a few words of redirection. Then go back to what I was doing. A hundred times a day. Sometimes more.
It's not hard. Any single instance of it is trivial. But the aggregate is a kind of tax I was paying in attention and posture, and the tax went up the more agents I ran. The better the tools got, the more windows I had, the more I was mousing.
The $230 device
Then a company shipped a beautiful piece of hardware for exactly this. A macropad with per-key RGB that lit up to show whether your agent was thinking, running, waiting on you, or done. A joystick to trigger skills. A dial to set reasoning effort. Push-to-talk to dictate a prompt. It was gorgeous. It was exactly the thing I wanted.
It cost $230. And it worked with exactly one agent — theirs.
One vendor's remote, or every agent's remote.
I didn't want a great remote for one tool. I have four tools, and whichever one is "best" reshuffles every few months. I wanted one layer that followed me across all of them — neutral, local, mine. That's the whole idea, stated plainly:
So I built the cheap version first
The expensive device's real magic isn't the metal — it's a tiny local program that sits between a button and whatever agent is on screen. Approve becomes a keystroke. Status becomes a light. Dictate becomes audio in and text out. None of that requires custom hardware. A $20 macropad, or the keyboard you already have, plus a small local daemon, gets you almost all of it today.
So that's what Fleetkey is, today: a small piece of software. It runs a local daemon that speaks a dead-simple contract over a local WebSocket, and a browser page that gives you the controls. Nothing leaves your machine.
{
"action": "approve | reject | skill | talk | dial", // five things you do all day
"harness": "claude-code | codex | opencode | zcode", // all four, one surface
"payload": { "value": "optional" } // e.g. dial position
}
// status comes back the same shape:
{ "state": "idle | running | waiting | done" } // this lights the keys
That's it. Five actions. Four harnesses. Four states. Over ws://127.0.0.1:8787 — loopback, not the network. Everything else is implementation detail behind that block. I locked the contract first, on purpose, so the daemon and the UI could be built in parallel without anyone waiting on anyone.
The four things I refused to compromise on
While I was building it, four principles kept the scope honest. They're the reason the page looks the way it does and the roadmap reads the way it reads.
Vendor-agnostic, or it's worthless.
A control surface locked to one agent is just that vendor's accessory. The moment you switch tools — and you will — you're back on the trackpad. Fleetkey drives whichever window is active and doesn't care what's running underneath.
Local only. No telemetry. Ever.
The daemon binds to loopback, never a public interface. No account, no cloud, no analytics. Your code and your prompts touch your machine and nowhere else. This is a feature, not an omission, and it's the cheapest trust signal an unknown tool can offer — so I'm stating it loudly.
Software works today. Hardware is a maybe.
You can use Fleetkey right now with any keyboard or macropad you already own. A ~$20–40 DIY kit is the next step, for people who want the physical thing. A finished unit is a "maybe," funded entirely by the DIY tier — and I will not put a ship date on it until backers justify the tooling. Missed indie-hardware dates are the most common way presales blow up their own credibility, and I'm not doing that to you.
Open adapters, not a walled garden.
I'll seed the first adapter — the harness I know best — and ship a tiny, documented interface for the rest. The OpenCode and GLM communities can write their own. "Multi-harness" should be an ecosystem that grows without me, not a maintenance liability I own forever.
How it actually got built
I'm one person, so I parallelized myself. I locked the contract first (the one block above), then ran the tracks at the same time: the daemon with one real action wired end-to-end, the browser UI consuming the contract, the landing page, the comparisons. Then a single convergence step — press a key in the browser, watch it actually approve something in a real agent window — before anything shipped. No launch post until there was a working thing behind it. A landing page with nothing behind it dies fast, especially on the forums I care about.
Lock the contract.
Five actions, four harnesses, four states, over a local WebSocket. Thirty minutes of work that everything else depends on. Done first, on purpose.
Daemon, UI, landing, content — all at once.
The daemon wires one real action (approve/reject via the OS) and stubs the rest. The UI renders four agent keys with live status LEDs. The landing page tells the story. No track blocks another.
One end-to-end action, proven.
Open the UI, start the daemon, focus a real agent window, press Approve — watch the keystroke land. That's the ship bar. Not all four harnesses; one, working, for real.
Post only after there's a working thing to show.
Page up, checkout live, download behind it. Then — and only then — the launch posts. Receipts over promises.
What I want it to be
I don't think Fleetkey is going to put the $230 device out of business. That thing is lovely, and if you live inside one agent all day and you want the metal, it's a fine choice. I'm building for the rest of us: the people running three agents at once, who keep switching, who don't want to buy new hardware every time the "best" tool reshuffles, and who'd rather their control layer not phone home.
If that's you — if your wrist hurts from the same hundred mouse-trips a day — it's free to try, it runs locally, and it works with the keyboard you already have. That's the whole pitch.
Try it, or keep reading.
The software layer works today on any machine. The full product page has the controls spec, the roadmap, and early-access pricing; the Show HN post has the short version. Both one click from here.