Almost every launch this week aimed at the same target, and it was not the model. The frontier labs keep moving the ceiling, so the interesting work has slid to the floor: who else can see the session, who checks the commit, which model actually does the work, and how an agent reaches the tools it needs. These five launches each take one of those problems and ship a working answer today.
One session, several people
Kolo starts from an observation that is obvious once stated: a coding agent runs on one machine, in one terminal, and everybody who wants to help has to crowd around a screen share. Kolo makes that session multiplayer instead. You run the agents on one machine, run `kolo up` in your project, and send your team the invitation link printed in the terminal. They open it in a browser, pick a name, and they are in the same terminal. Only the host installs anything.
The design decisions are the interesting part. Built-in adapters cover Claude Code, Codex CLI and opencode, with custom agent descriptions for anything else. The host decides who can control the session, so read-only observers can follow along without being able to type a prompt or approve a step. It ships as one Go binary that runs both the hub your team opens and the host that starts the agents, and hosts connect out to the hub, which means the hub has to be reachable from your team's browsers but the host does not have to be exposed.
It is also honest about what it is: an experimental alpha for trusted teams. Agents run with the host user's permissions, so the README tells you to start in a dedicated VM with only the projects and credentials you intend to share, and links an isolation setup for exactly that. Hosts support Linux and macOS on amd64 and arm64, with WSL2 on Windows. AGPL-3.0.
A leaner terminal agent
Keen Code is a terminal coding agent in the shape of Claude Code or Codex CLI, written in Go, with a stated goal of being simpler and lighter. It is opinionated in a way that reads as a feature: it avoids what a regular software engineer does not need and keeps the harness small.
What it does have is a serious feature list. Anthropic, OpenAI, Codex over OAuth, Gemini, DeepSeek, Kimi, GLM, MiniMax, OpenCode Go, Yolo-Auto and Amazon Bedrock are all selectable with `/model`. Ten built-in tools cover the core loop and nothing more. MCP servers connect over streamable HTTP or stdio from a config file, and each connected server generates an ordinary skill with a tool table and JSON schemas, so tool discovery stays prompt-efficient and detailed schemas load on demand rather than being dumped into the prompt up front.
Two details are worth stealing even if you never install it. The first is hashline editing: `read_file` prefixes every line with an `N:HASH|` anchor made of the line number and a short hash of the line, and `edit_file` applies a multi-op array validated against one file snapshot, atomically, so stale anchors are rejected instead of silently editing drifted content. The second is subagents defined as plain markdown files in `.agents/agents/`, each with its own provider, model, thinking effort and permissions, with the main agent delegating up to ten bounded tasks in parallel.
A review gate in front of every commit
ReviewerAgent is the most opinionated thing in this batch, and the numbers behind it are the reason. The premise: a model that does not do the coding but only reviews the plan or the code finds problems the coding agent missed, and different models have different strengths, so letting one review another produces better plans with fewer bugs.
So it installs a commit gate. A review agent you choose completes a plan or code review, and if it specifies issues, the coding agent has to fix them before the commit is allowed to proceed. Codex, Pi with any model, or Claude Code itself can be the reviewer, running in its own session. The second feature, Stop Continue, attacks a different failure: agents stop. Sometimes they declare a good stopping point, sometimes they ask a question that was already answered in an established plan. Stop Continue examines the project plan, the task list and any background tasks the agent is waiting on, then either allows the stop or tells the agent what to do next.
The author published their own usage log, which is rarer than it should be. Over four months of daily use, reviewerAgent gated 3,877 commits made through Claude Code across roughly 7,600 reviews, so about half of those commits were rejected at least once. Each rejection listed an average of two required fixes, and most rejected commits were accepted after a second round. Rejection scaled with size: 23% of code commits under 50 lines were sent back, against 72% of those over 1,000 lines. The coding agent pushed back on just 3 of 693 rejections in the last month of that window. Treat all of it as one person's log from one project rather than a benchmark, but it is the kind of evidence almost nobody publishes.
Sending the cheap work to a cheap model
Token Beggar is a Claude Code plugin built on a narrower version of the same instinct. Before the big model does a job, it checks whether a cheaper model can do it just as well. Small tasks stay in the chat. A large task, such as fixing a bug in a repository you have not read yet, goes to one cheaper worker, and the chat then checks the whole diff and runs the tests. Design, root causes and the final answer stay with the model you picked.
It runs on your machine, in your own Claude Code session, using the login you already have, sending nothing anywhere and writing only to its own folder. Python 3.10 or newer, standard library only, zero dependencies, MIT licensed. There is a `token-beggar doctor` command that lists what can quietly stop routing and exits 1 when something is broken, which is the kind of unglamorous tool that tells you the author has been bitten by it.
The published result is 18 real bug fixes costing 1.42x less quota and money than working alone, with the same share of hidden tests passing, 69% against 70%. Eighteen fixes is a small sample and it is the author's own, but the shape of the claim is right: not cheaper at any cost, but cheaper with the quality held flat.
One governed endpoint for every tool
Zilla is the oldest project here and the least like a toy. It is a stateless, multi-protocol gateway that now carries two surfaces through one engine: an Event Gateway that exposes Kafka and MQTT to applications over HTTP, SSE, gRPC, MQTT or WebSocket, and an MCP Gateway that gives AI agents one governed MCP endpoint for existing MCP servers, HTTP APIs, OpenAPI-described services and Kafka. Both are configured in a single `zilla.yaml` and share routing, identity, authorization, schema, telemetry and deployment.
The MCP half is what matters for agents. Capabilities are namespaced as `toolkit__capability`, so `github__create_pr`, `payments__refund` and `kafka__produce_message` coexist without collisions, and the toolkit selects the route. Zilla authenticates the agent once, filters capability listings by authorization, and can forward or exchange credentials for upstream services. Large catalogs can be divided into eager and cold tools so agents load only the capabilities they need, and it can relay MCP elicitation, apply schema guardrails on JSON, Avro and Protobuf payloads, and export metrics without changes to agents or upstream providers.
It runs from Docker or Helm, exposes metrics on port 7190, and has been around long enough to have a real user base. The licence is the catch: the Aklivity Community License lets you deploy, run and modify it for your own workloads including production, but does not permit offering Zilla as a standalone commercial Zilla-as-a-service product. Advanced OAuth grants and shared Redis or Hazelcast stores for multi-replica deployments sit in the paid Plus edition. It is source-available, not OSI open source, and the site says so plainly.
What this batch says
Read together, these five describe where coding agents actually are. The model is a commodity you swap with `/model`. The scarce things are a session other people can join, a second opinion that blocks a bad commit, a router that keeps the bill down, and one governed endpoint in front of a pile of tools with different credentials and schemas. None of the five is a research project, and all five run today.
