Hive at v5: The Swarm Grew Up, and It Is Learning to Leave the Dashboard

The Hive swarm intelligence platform for open source reached its v5 stable release on September 21, introducing three digest-verified release channels, four per-agent policy modes enforced by a proxy, and formal protocol verification using Promela and the Spin model checker. The system has run against its own repository for five months and now operates tens of hive spokes in production across hosted and self-hosted fleets. Formal verification of the platform's agent-to-hub protocols surfaced a real bug that would otherwise have left the system silently stuck.

In June I described Hive Hub and Spoke https://kubestellar.medium.com/hive-hub-and-spoke-a-swarm-intelligence-platform-for-open-source-7efa1465e2bf : a spoke is one Hive instance running a team of specialized agents against a repository, a hub is the registry and control surface above many spokes, and contributors lend their own AI coding CLI to any hive in the network. The pitch was that open source has more issues than bandwidth, and a single agent on a single repo is a flashlight in a warehouse. That post described a system that had just started running. This one describes a system that has been operating against its own repository for five months, has a stable release line, and has tens of hive spokes in production across the hosted hub and self-hosted fleets. Almost every mechanism from June still exists. Most of them got harder guarantees. A few got replaced by something more honest. What stayed the same The shape has not moved. A spoke is still a single Go binary in a single container. A governor still watches queue depth and moves the fleet between idle, quiet, busy, and surge. Agents still run in isolated tmux sessions with their own CLI, and every GitHub call still passes through a proxy that enforces what the agent’s level allows. The hub still holds the registry, the leaderboard, one-click hosted hives, and the contribute page. The six-level maturity model is still the governance backbone. If you read the earlier post you saw the mode names ADVISORY, ISSUES ONLY, and ISSUES PRS MERGE. Those have settled into four per-agent policy modes that map more cleanly onto what an agent may actually do: - Advisory - observe and report as dashboard beads. No GitHub writes. - Measured - file issues. - Hold-gated - open pull requests carrying a hold label that a human must remove. - Full - auto-merge on green CI. Every level from L1 Inception to L6 Fully Autonomous is a specific assignment of those modes to agents. The proxy enforces them before a request leaves the container. One detail says a lot about the philosophy: if Hive starts and finds the proxy cannot enforce, because the container lacks the network capability it needs, Hive refuses to start rather than run an unenforced capability model. What v5 changed v5 became the default branch and the supported stable line on September 21. Structural changes on this line were gated by public RFC issues, and the workstreams that landed are the ones that turned a promising system into one I would ask someone else to run. Three release channels, verified by digest. Every green merge to v5 retags candidate and latest . stable advances only after a soak gate that checks evidence, open blockers, and a smoke run, and it advances by digest, not by tag. v6 publishes edge . v4 publishes no channel at all. Channels are retags of an already built multi-arch image, never rebuilds, and moving tags only advance forward: a delayed workflow run cannot roll stable backwards over a newer build. An operator switches a hosted hive between channels from the version pill on the My Hives list, and rolls back by pinning all three images to a short-SHA tag and confirming the digest on the running spoke. Formal verification found a real bug. Parts of Hive are really protocols: several agents and a hub passing state back and forth, with rules about who may act next. Those are exactly the parts where a bug does not crash anything. It just leaves the system in a state nobody intended, and the dashboard looks fine while nothing moves. v5 started modeling those parts formally. Each protocol gets a small model written in Promela, and the Spin model checker walks every reachable state to prove that the properties we care about hold: work never gets stuck, ownership is never ambiguous, an escalated item always has a way out. It is an opt-in capability of the quality lane at L5 and above, switched on from Settings, Features in the dashboard. The first model paid for itself immediately. It proved that the escalation ledger could reach a state where a pull request was red, still open, and excluded from every lane at once. No agent would touch it, no human had been told, and from the dashboard it looked like the agents were slow. That is the kind of bug you find months later by accident, if at all. The model found it before it happened in production. After the fix, the same properties held across millions of explored states. The rule going forward is simple: if a change touches a modeled protocol, it updates the model in the same pull request. A reviewer lane with an owner. Escalated PRs, the ones marked needs-human , used to be a one-way door. v5 adds a dedicated reviewer agent with authority to adjudicate them, running multiple review perspectives and posting an aggregate verdict with a derived 0 to 5 mergeability confidence score. Where governance requires a human approval, the reviewer’s output is advisory. It never substitutes for the human. It does make sure the queue has someone watching it. Constellations. The largest external deployment I know of is tunaos.org, which runs a self-hosted hub coordinating two spokes at L5 and L6 across 43 repositories. That deployment showed that big adopters need fleet-level visibility without turning the hub into a hard control plane. The constellation RFC delivers repo-claim overlap warnings, spoke charters, fleet headroom, and GitHub App budget display. Two spokes that both think they own a repository is now something the hub tells you about before both of them open the same PR. Backend capacity, designed and accepted. Every hive runs on someone’s model subscription, and every subscription has a ceiling: a token budget, a rate limit, a set of models the provider will serve today. In June the hive found out about those ceilings by hitting them. An agent would kick, the provider would refuse, and the governor would see a lane that looked idle when it was actually starved. What v5 ships against that is the first layer: opt-in provider rotation with a threshold percentage, per-provider monthly allowances, and per-agent tiers, all editable from Settings, Features in the dashboard with a live headroom readout next to each provider, auth canaries that tell you a provider credential has died before an agent finds out, and a model pin per agent so a lane never quietly drifts to a different model. The accepted v5 RFC lays out where this goes next: normalized capacity readings so a Claude subscription, a Copilot seat, and a self-hosted vLLM cluster compare on one scale, an authoritative model inventory where the provider exposes one, per-lane tier floors so a budget squeeze never downgrades your reviewer, and pacing that slows a lane before it hits a limit rather than after. Backend choice becomes a placement decision you make with the numbers in front of you. The design is accepted; the phases are on the v5 roadmap, and I would rather say that plainly than let a config key imply more than it does. You can see what the fleet is doing. The June post described the registry as a live map. What v5 adds is the ability to tell whether a hive is healthy, not just present. Every hive on the hub gets a green, amber, or red verdict computed from whether it has produced real output back to its work source within a window appropriate to its level, and a non-green verdict carries a remediation hint that says what to do about it. Every agent action lands in an append-only audit ledger, so the answer to “what changed and why” never depends on a chat transcript. Operators who live in a terminal get hivectl tui , a full-screen fleet view with agents, governor state, token spend, and activity in one screen, driven by the same API as the web dashboard. And when a contributor’s relay is struggling, the dashboard can diagnose it without hub shell access, with an explanation of where that contributor sits in the queue and why. The contributor relay got a name and named profiles. The contribute system from the June post is now ClankeR, the contributor relay, and it supports 13 CLIs: Claude Code, GitHub Copilot, Codex, Goose, Pi, Oh My Pi, IBM Bob, Aider, LiteLLM, Antigravity, opencode, Kilo, and Muse Code. A relay can subscribe to several hives at once as named profiles, switch between them without a restart, and move a profile to another machine as a passphrase-encrypted bundle. The rule from June is unchanged and is still the reason the model is safe: your credentials never leave your machine, and your existing GitHub permissions are the ceiling on anything your agent can do. More than GitHub Issues, and more than GitHub. In June a hive read work from one place: open issues on a GitHub repository. v5 has four work sources behind one work source setting: GitHub Issues, GitHub Projects v2 boards, Linear, and Jira. Linear is a full two-way integration, with webhooks, session acknowledgement, and the agent writing back to the Linear issue, so a team that plans in Linear never has to look at GitHub to see what the hive is doing. Login to the hub is no longer GitHub-only either: the hub speaks OIDC, and GitHub, Google, IBMid, and Red Hat SSO are configured providers. On the forge side, GitHub.com and GitHub Enterprise are both fully supported through the Forge App, with the app, its install page, and the API host pinned to the same enterprise host. GitLab, Gitea, and Forgejo adapters have landed behind the forge abstraction and are tested, and a first production caller, governor escalation writes, now goes through that neutral seam instead of the GitHub client. Running a hive end to end against a non-GitHub forge is post-v5 work, and the docs say so plainly rather than letting a config key imply more than it does. Hub to spoke trust got signed. Heartbeat responses from hub to spoke are independently signed with persisted verifier state, so a spoke can tell a real hub instruction from a replayed or forged one. Hub-spoke channel authentication is Ed25519 only, with a master-key rotation program behind it. The hub moved. Hive now lives at github.com/hivecommons/hive https://github.com/hivecommons/hive under the Hive Commons organization, and the hosted hub is hive.hivecommons.dev https://hive.hivecommons.dev/ . The old kubestellar.io address redirects. Hosted hives sit behind one fleet wildcard certificate instead of one certificate each, which is a boring sentence that ended a very exciting outage. Login supports GitHub and Google. And a lot of hardening. Roughly ninety v4 releases landed in the ten days before the v5 cut, most of them merge-safety and trust work that v5 inherited: the merge watcher independently verifies CI and no longer treats an absent check run as passing, refuses merges into unprotected base branches unless allowlisted, and the release workflow refuses a dispatched SHA that is not an ancestor of the branch. Canary egress detection covers encoded and obfuscated exfiltration. Contributor-facing endpoints that used to leak plaintext registration tokens do not anymore. Some of that came from the hive filing defect reports against itself, which is a feature now: an opted-in hive can file calibrated reports upstream. The numbers Hive maintains its own repository, so the commit history is the demo. Since April: - Merged pull requests: 5,688 - Issues worked: 2,152 - Median issue time to close: 3 hours p90: 11 hours - Contributors: 23, across four organizations - Tagged releases: 211, of which 8 on the v5 line - Hive spokes in production: tens, hosted and self-hosted - Production adopters: KubeStellar Console, tunaos.org, Project Bluefin - Pre-production adopters: Frostyard, Open Horizon, Open Horizon Services, Danathar The production three are worth a sentence each. KubeStellar Console was the first consumer: the hive does autonomous triage, fixes, review, and merge on the Console codebase. tunaos.org runs its own self-hosted hub coordinating two L5 and L6 spokes across 43 repositories, and is the reason the constellation work exists. Project Bluefin is a reference implementation: a self-managed hive over its own repositories, documented publicly as the Bluefin factory. Behind them, Frostyard, Danathar, and the Open Horizon and Open Horizon Services projects from LF Edge are running hives in pre-production, the latter two focused on enforcing code consistency across community contributions. All of them are listed in ADOPTERS.md https://github.com/hivecommons/hive/blob/v5/ADOPTERS.md . The industry caught up to the thesis The strongest validation this quarter did not come from us. In August, Brendan Irvine-Broque at Cloudflare published the case for an Agent Development Lifecycle https://blog.cloudflare.com/agent-development-lifecycle/ to replace the SDLC, arguing that agents can write code faster than teams can review, deploy, and maintain it, and that the fix is a platform built for autonomous operation rather than human workflows with automation bolted on. Their framing is the one we have been using since the first hive went live: the SDLC is for software teams, the ADLC is for software factories. Read the seven properties they say a factory needs and it is hard not to see the roadmap above. Programmatic, so no click-ops: every Hive operation is an API and the dashboard is one client of it. Real-time and push-based: the governor and the v6 chat spine. Atomic, so each change is independently testable, releasable, and reversible: hold-gated PRs and digest-verified rollback. Permissioned, with graduated access and escalation: that is the six-level maturity model, and the escalation surfaces in v6. Self-improving: the hive that files defect reports against itself. The property Cloudflare names but does not define is the one Hive is built around. Their post says agents need graduated access. It does not say what the grades are, who decides, what enforces them, or what the audit record looks like. That gap is the maturity model, the proxy, and the ledger. Cloudflare is building the platform under the factory. Hive is the governance layer above it, and the two compose: a proposal is already open to admit a Cloudflare-style external workflow through Hive’s contributor protocol, with Hive keeping admission, scope, and the merge decision. The Astro team’s results https://blog.cloudflare.com/astro-issue-triage/ on that platform, written up by Astro core maintainer Matthew Phillips, are the other data point. Isolated AI subagents built on the Flue https://flueframework.com/ framework and shipped as triagebot-action https://github.com/withastro/triagebot-action took a repository from more than 200 open issues to about 30, and for the first time in five years the project is on course for zero. Their lessons match ours line for line: separate the phases so an agent cannot force a solution, post the full reasoning to the issue so it is auditable, let the original reporter test the patch before anything merges, and treat every agent failure as a signal about the codebase rather than the model. Two of those are already in Hive. Reporter-verified previews at L5 is one we intend to borrow. For comparison, here is the same curve on KubeStellar Console, the first production hive. A burst of filing in early September pushed the open issue count from single digits to a peak of 143 on September 9. Between September 14 and 17 the hive closed 166 issues, 145 of them by the hive’s own account, and merged 135 pull requests, and by the evening of the 17th the count was 9. It has sat between 7 and 10 since, with new issues arriving and being worked the same day. Astro took several months to go from 200 to about 30 with one workflow on one repository. A hive at L6 did the equivalent in four days, and the difference is not the model. It is that the pipeline runs unattended, the governor speeds up when the queue is deep, and nothing in the loop waits for a human unless the policy says it must. What v6 is about The v6 branch opened on September 18 and publishes the edge channel. Its theme is one sentence: every operator interaction the dashboard offers should be reachable from the places humans already are. A GitHub thread. A chat workspace. An inbox. A phone. The dashboard stays the richest surface. It stops being the only one. The idea that makes this a release line rather than a feature flag is the guard invariant. Every non-dashboard surface routes through the same authorization and safety machinery as the dashboard: the same role floor, the same mode ladder and capability checks at the proxy, the same reply path, the same inbound text scanning, the same outbound canary and secret scrubbing. No surface grows its own authorization. A surface is not considered shipped until it has passed conformance against that invariant, and every surface on v6 today has. In practice that means a hive on edge can already be driven from Discord, Slack, Microsoft Teams, Matrix, or Telegram through one shared chat spine, or by mentioning the Hive App on a GitHub issue or PR, which is what turns GitHub Mobile into a hive remote. Answering a hold-gated PR from a phone on a train is the point. When a verdict says a human is required, the hive pages one through email, ntfy, Pushover, or PagerDuty instead of leaving the item in a queue nobody is watching. You can also call the hive from a GitHub Actions workflow. A composite action, hivecommons/hive/.github/actions/hive@v6 , lets a workflow step ask the hive to review the PR it is running on, or run a nightly sweep, with two transports: a comment relay that goes through the same mention path as a human, or a direct dispatch to the hub authenticated by the workflow’s own OIDC token, verified against GitHub’s keys with a pinned audience. Either way the kick is recorded with its source and run id, deduplicated per run attempt, and pushed through the same identity, allowed-command, and text-scanning checks as everything else. If your CI is already the place decisions get made, the hive meets you there too. Contributor agents query the hive’s view of a task over a Model Context Protocol endpoint rather than having it pasted into a prompt. And when an owner runs out of tokens and a lane pauses, approved volunteers can pick up that lane’s queue on their own machines, behind a model floor that defaults to the top tier and is never lowered by a dashboard nudge. That last one arrived as a community RFC and landed in a week, which says as much about how the project runs now as the feature does. What I got wrong in June Two things. I wrote about the hub’s registry as if reachability was health. It is not. A spoke can heartbeat every minute and produce nothing for a week. The hub now computes a green, amber, or red verdict per hive from whether it has produced real output back to its work source within a window appropriate to its level, and the verdict carries a remediation hint. Reachability is a prerequisite, not a score. I also underestimated how much of the value would come from the deterministic parts. The agents get the attention, but the reason a hive can run at L6 is that filtering, classification, merge gating, and enforcement are all shell scripts and Go that run before any model sees the work. Agents only make the judgment calls. Determinism before judgment turned out to be the design principle, not a performance optimization. Getting started There are two ways in, and the faster one needs no infrastructure at all. Request a hosted hive. Log in at hive.hivecommons.dev https://hive.hivecommons.dev/ with GitHub, Google, IBMid, or Red Hat SSO and click Create Hive. Point it at a repository, pick a channel from the version pill, and the hub provisions an isolated hive with persistent storage, TLS, and health monitoring in about a minute. New accounts start without a hosted quota, so the first click sends a request to a hub admin rather than spinning up a spoke; once it is granted you own the hive and can add collaborators. Start at L2, Advisory. Install the Forge App on your GitHub or GitHub Enterprise organization, give the agents a model you are already entitled to, and watch what they would have done for a couple of weeks. Nothing touches your repository until you move the level up. This is the path most first-time operators should take: same code, same agents, same dashboard as a self-hosted hive, none of the setup. Run your own. If you want the hive on your own machine or cluster: git clone https://github.com/hivecommons/hive.git cd hive cp src/hive.yaml.example src/hive.yaml install -m 600 /dev/null src/.env echo "HIVE GITHUB TOKEN=ghp ..." src/.env printf 'HIVE DASHBOARD TOKEN=%s\n' "$ openssl rand -hex 32 " src/.env docker compose -f src/docker-compose.yaml up -d Podman Quadlet and Kubernetes via Kustomize are equally supported. Add hub url: https://hive.hivecommons.dev to hive.yaml and your hive appears in the registry within a minute, side by side with any hosted hives you own. Contribute compute to any hive: brew install just gh git clone https://github.com/hivecommons/hive && cd hive just contribute-setup claude just contribute-hive Or track v6 on edge and drive your hive from Slack. Why this still matters The argument from June has not changed. Open source does not need one assistant. It needs a system that triages thousands of issues across dozens of repos, assigns work to the right agent or contributor, enforces governance at every level, and earns the right to do more by showing its work. What changed is that the system now has a stable line, a formal model of the parts that can deadlock, an audit trail for every action, and a plan for meeting maintainers in the thread they are already reading instead of asking them to open one more dashboard. Hive is Apache-2.0 at github.com/hivecommons/hive https://github.com/hivecommons/hive . The hub is at hive.hivecommons.dev https://hive.hivecommons.dev/ and the docs at docs.hivecommons.dev https://docs.hivecommons.dev/ . Contributions welcome, including through the contribute system itself.