Scroll horizontally for more columns.
Short answers to the questions people ask once a hive is running. Everything below describes what this hive actually does today β where behaviour is surprising, it is called out rather than smoothed over. Each answer links to the source doc, so this panel stays a map, not a second source of truth.
Need help from humans? Join our Discord; the Hive Commons community can help you pick the right next step. Want to see a hive at work? Watch the hive live on Twitch.
L1 is inception; L2 is calibration. At L1 the brainstorm agent can turn a raw idea or existing repo into structured facts and a scaffold through the Inception panel; it asks clarifying questions and stops when you approve. At L2 the hive watches your repo and records what it finds, but it does not open ordinary issues or PRs. See Inception and the ACMM policy matrix.
The job at L2 is not to fix everything in the ledger. It is to decide whether you believe the hive's judgement: point your own local agent β claude, bob, or copilot β at the π Hive Advisory Report and ask whether the findings hold up before you give Hive more authority.
The Advisory Digest is the work ledger. Agents record findings as beads (small tracked notes created with bd create); the digest rolls up every open advisory, bug, or feature bead, grouped by the agent that filed it. Internal items such as task and decision are left out so the ledger stays readable. See Beads CLI and Advisory Digest.
The same ledger is mirrored to GitHub: the hive opens one issue named π Hive Advisory Report in your default repo and keeps a digest comment current. That report is the whole of the normal L2 GitHub footprint.
The left bar and dot encode severity, derived directly from the bead priority set by the filing agent:
Only critical, high, and medium have dedicated bar colors, so the low row has a blue dot but a grey bar. Severity is a judgement call by the filing agent, not a measurement. See the L2 advisory mode in the ACMM policy matrix.
They are not ranked by severity. Findings are grouped by agent (agents sorted alphabetically) and within each agent they appear oldest first, so a critical finding filed this morning sits below a low finding filed last week. Selection is every open advisory/bug/feature bead; recently closed beads appear separately as recently resolved. See Beads CLI.
Yes. Open Settings β Appearance β Display timezone and pick browser local time, the hive server timezone, UTC, or an IANA timezone such as America/Los_Angeles. Absolute timestamps include the timezone abbreviation; relative ages like 1m ago stay relative. See Dashboard settings explained.
Some sections only appear at certain ACMM levels or when their feature is on (Experiment Lab, for example, needs L4 and dashboard.experiment_lab), and a browser that has never seen this hive starts non-critical cards collapsed. To reorder, drag the β Ώ grip in a section header, or focus it and press Space, Up/Down, then Space/Enter. To hide a section, hover its sidebar row and press the eye-off control; the row stays in the sidebar, muted, and clicking it brings the card back. Layout is browser-local; the avatar menu's Layout section saves presets and offers Reset layout to default. See Reorder sections and Dashboard sections explained.
Change to L3 when you trust the findings β there is no gate. The ACMM Eval page and recommendation API are read-only advice; they never change the level and do not license or block the move. The supported path is the level dialog behind the level chip in the top bar (or acmm_level through config ownership rules), which applies the level pack and reconciles agents. See ACMM advisor, changing ACMM level, and config layering.
At L3 the quality lane builds the safety net: hold-gated test and CI PRs, plus CI health measurement. It is about making later automation safe, not about handing the hive production-code autonomy.
requires_human / reject verdicts do not stop the App auto-merge sweep; use a hold label or a GitHub branch rule when merging must stop.Promotion adds agents and capability; demotion narrows them again. Hive removes only level-owned holds when the level no longer calls for them β a hold you applied is never removed automatically. See the ACMM policy matrix, Running at Level 6, and hive-open-pr.
The shipped advisor is advisory-only: it can say a hive appears ready for the next level, but a human applies the change. The separate autonomy controls are opt-in and default off, under autonomy.auto_promote and autonomy.auto_demote. See ACMM advisor and ACMM level changes.
hold label? What does "hold-gated" mean?Hold-gated means an agent may open a PR, but a literal hold label keeps it out of every merge lane until a human removes the label. At L3βL5 the PR watcher applies that hold to every agent PR from the level gate; a PR can also be held because its only rationale is an unacknowledged hive-filed issue (#5117), or because it traces to an issue from an untrusted reporter (#9665, held at every level); the same label also lands on kind/bug issues that lack a reproducing SHA. Hive releases only holds it applied itself β a hold a person added is never removed automatically. See Hive labels and control signals.
No β shadow never blocks a merge. review.shadow evaluates the review-approval gate, and intent.shadow the intent-verification gate, exactly as if enforcement were on, then only records the answer (would_have_held / would_have_blocked) on the PR's evidence bundle and in the log. A PR that is otherwise merge-eligible stays eligible, and shadow is ignored when real enforcement is already on. The review toggle is under Settings β Features β Review Gate; the intent toggle is under Settings β Security. See Review swarm configuration and Intent verification: shadow mode.
The Evidence card in the Throughput section summarises review evidence bundles: one JSON record per PR head commit of what Hive reviewed, what CI said, who acted and how it merged. Its panels (outcome by author kind, reviewer calibration, reviewer accuracy Γ model family, maintainability trend, boundary enforcement, claim vs verdict, work balance, and shadow gates) follow the 24h / 7d / 30d / custom window pills, and each panel shows a letter grade (A+ β¦ C-, or β when there is not enough data) next to its title, a one-sentence plain-English summary under it, and a β button that opens a popover with the full explainer, the details and "what this does not show", and the rubric behind the grade. The charts show what was recorded; they do not prove a merge was correct ("merged" is not "correct", an open PR counts as not merged, and evidence only exists since the feature shipped), and nothing in them is read by anything that decides a merge. See How to read the Evidence card.
The version badge compares the running commit with the newest build your deployment can actually reach: the hub-delivered target for the channel or branch tag this spoke tracks, else the tip of the build's own branch. A :stable spoke is not "behind" commits that only candidate carries, and a v5 spoke is never measured against v4. Hover the badge to see which target the count is against. See Channel-aware upgrade targeting.
A release channel is a moving image tag: candidate moves on every green merge to v5, stable is promoted from candidate by digest after a 24-hour soak, and edge follows the development branch v6. When a channel moves, the hub notices within a few minutes and, if your hive's upgrade policy allows, delivers the new target on the spoke's next heartbeat; the pod rolls and keeps the channel tag. Hosted hives switch channels from the version pill on the hub's My Hives list or the spoke's Follow channel selector (owner only); self-hosted Podman spokes change Image= by hand. See Release channels and Stable soak policy.
A run is staged work on one lease: spec β plan β implement. The Runs section and /api/runs show stage, generation, triage verdicts, receipts, checkpoints, and whether a person must intervene; run-stage work is only offered to relays that declare the run-stage capability. See Spektacular (Spek) stage runner, work sources, and relay capabilities.
Long-running pieces are default-off. Spek does nothing unless runs.spektacular.enabled is true; incoming issue triage does nothing unless runs.triage.enabled is true. The live worktree cap is runs.max_worktrees; the stage retry budget is runs.max_stage_retries.
Inception is the L1 human-and-brainstorm workflow for turning an idea into facts and a scaffold. Spek is the optional runner for staged speks and plans once you are using long-running runs. Both keep authority in Hive: Spek status can advance a lease, but implement still lands through the existing PR flow. See Inception and Spek.
External engines are report-only admission surfaces, not extra credentials: they receive bounded context and return receipts that Hive verifies, and they never receive target-repo write credentials or dashboard tokens. Flue and OMP are independent, default-off bindings (runs.external.flue.enabled, runs.external.omp.enabled), and dispatch additionally requires the relay to advertise ext-exec/flue or ext-exec/omp. See external workflow admission and contributor relay capability tokens.
The Experiment Lab ("Nous" in the API) runs small, approved experiments against your repositories' code β tests, CI config, automation scripts β measures each against a recorded baseline, and keeps a ledger of results. It is repo-only: experiments on the hive's own cadences, models or thresholds are out of scope since #12207. The section appears only at L4+ with dashboard.experiment_lab: true, and you approve or stop every experiment. See the Experiment Lab section guide, which links the full guide.
On the Experiment Lab section itself: press + New experiment and fill in the research question, an optional hypothesis and the scope (which repos it may touch; none selected = hive-wide) in the New experiment dialog. That dialog is the only place an experiment is defined. The β Experiment Lab Configuration dialog holds lab-wide guardrails only β the Trust Ladder, the Output Mode and safety labels, fast-fail bounds, timing, and Repos experiments may target, the allow-list the scope pills are drawn from (none selected = any repo). If the allow-list changes later, running experiments keep their scope and their card shows a muted note for any repo that is no longer allowed. See defining experiments.
Yes β the β Edit experiment icon on its card opens the same dialog pre-filled (titled Edit experiment #N; finish or cancel an open form before opening another). Changing only the hypothesis (or tags) is saved in place and keeps the baseline. Changing the research question or the scope invalidates the baseline and the hypotheses judged against it, so the lab asks first: "Changing the question or scope restarts this experiment: baseline resets to 0/672 (β7 days) and hypotheses/proposals so far are archived with the old version." Restart experiment archives the current card as version N (it stays readable under Previous experiments) and creates version N+1 with the edited fields and a fresh baseline β after running the same scope-conflict check as a new experiment; Keep as is changes nothing. The new card reads v2 Β· restarted from #1. Paused and concluded experiments follow the same rule. See editing an experiment.
Yes. The Experiment Lab lists each running experiment as its own card β research question, scope pills, status and a baseline bar reading N / 672 (β 7 days of observations, 4 per hour) β and + New experiment adds another beside them, the same way the Inception section lists its campaigns. The one rule is that two running experiments may not share a repo target (or both be hive-wide): concurrent interventions on the same scope would confound each other's outcomes, so the lab refuses the second one and offers to pause the first or narrow the scope. Archived experiments stay read-only under Previous experiments. See running several experiments at once.
Each card also says where it is: collecting baseline, ready β generate proposals (one button; the lab switches to Suggest for you), proposals awaiting your review, running or concluded. Entering a question is what creates the card β you never have to find a mode switch first.
ClankeR lets contributors lend their own local AI CLI subscription to a hive. They run just contribute-hive; the relay connects to /api/contribute/ws, accepts one task at a time, works locally, and reports PR metadata back. The contributor's credentials stay on their machine; Hive mints short-lived task-scoped GitHub tokens for accepted tasks. See the ClankeR contributor relay.
Trust is tiered. Newcomers start rate-limited; contributors auto-promote after completed PR tasks; trusted, merger, and advisor tiers are maintainer/operator grants. Delegated roles are bounded by tier, explicit grants, and the hive allow-list at hub.contribute_delegatable_roles. See contributor trust and roles.
Yes. Agents use one of two method families: subscription CLIs (claude, copilot, gemini, goose) that you log into once from the dashboard, and inference endpoints (vllm, llm-d, litellm, openrouter) that need only a base URL and a key reference. A Model Gateway is a named inference endpoint configured under Settings β Governor β Model Gateways; the OpenRouter gateway works with a key or the scan-to-fund flow and no CLI login, and the key value lives in /data/secrets/, never in YAML. See subscription CLIs vs self-hosted inference and inference backends.
Hive agents do not claim issues by assigning themselves as users. They use the App-bot path: hive-open-issue claim asks the issue-request watcher to apply visible hive/claimed-by-<agent> and stage/030-pr-in-progress labels (with a timestamped hive:claim start marker) and audit agent_issue_claimed. The watcher re-derives the requesting agent from file ownership, so an agent cannot forge another agent's claim. See hive-open-issue.
Claims are issue writes, so they require the same ACMM issue-writing permission as comments and issue creation. The optional claim-expiry feature is default-off under governor.claims.enabled; when off, ordinary work assignment still relies on the existing queue/lease rules.
At L2, expect only the π Hive Advisory Report issue and its digest comment. Higher levels add App-bot authored issues, comments, PRs, hold labels, review verdicts, claim labels, and β at L6 β auto-merge when checks pass for eligible App-authored PRs. See hive-open-issue, hive-open-pr, and GitHub write surface.
Two GitHub-adjacent toggles are intentionally default-off. Audit finding publication requires publication.enabled and still refuses sensitive findings unless publication.private_channel is configured. Plan-match reviews require review.plan_match.enabled. See audit campaign, publication level rules, and planning intelligence.
Every PR the hive opens ends with a β hive: line naming the agent and, when known, its backend, model, effort, tool versions, session and who requested the work, so a reader can tell at a glance which agent and model produced it. The trailer is controlled by governor.attribution_trailer (default on); turning it off hides the visible line but the matching agent_pr_created audit entry is written regardless, so attribution is never lost. See the attribution trailer.
The Audit Log section of this dashboard reads /data/audit.jsonl, one JSON line per action, newest first, with a search box (words are OR'd; /regex/ works) and a Sensitive only filter. Each entry's user is who performed it β a GitHub login, or a pseudo-user such as system for automated paths β and GitHub writes also carry repo and target. See audit log format and the Audit Log section.
Higher levels increase throughput and spend by design. The strongest lever is cadence: the Governor grid sets each agent's interval per mode (idle, quiet, busy, surge). Widening busy/surge from 1h to 6h roughly cuts that agent's kick count sixfold; 0 disables that agent in that mode. Cadences use Go durations, so write one day as 24h, not 1d. See cadences and the governor.
Budgets are token budgets, not dollar budgets. governor.budget.total_tokens set to 0 disables budget tracking; otherwise the governor warns near governor.budget.critical_pct and suppresses kicks at 100% until the governor.budget.period_days window resets. The mode thresholds that decide idle/quiet/busy/surge scale by repo count unless you pin them; see governor thresholds.
Move routine agents to cheaper backends or models when the work allows it. The agent card and Governor grid expose backend, model, and effort; model rotation is opt-in under governor.rotation.enabled. See agent configuration.
No. Cadence is the wait between runs, not a maximum run length. A busy agent facing a deep queue can run, finish, and be kicked again soon after; widening cadence spreads the same queue over more wall-clock time. A growing backlog can also push the governor from idle to quiet to busy to surge, selecting shorter cadence columns without any per-agent setting changing. See governor thresholds and cadences.
Yes. A first run against a mature repo is a backlog drain: old technical debt appears all at once, agents have enough queued work to stay busy, and the governor may choose busy/surge. Steady-state cost should fall as the queue drains. If you need to slow the spike, start lower, widen cadences before the first run, pause nonessential agents, or set a real token budget. See governor thresholds and agent configuration.
Use the π΅ Cost section for estimated spend by timeframe, then drill into agent cards and Prior Prompts to see what each kick was asked to do. Treat cost as attribution, not an invoice: token counts and list prices can diverge from subscriptions, discounts, and self-hosted inference. See telemetry and the Cost section.
Three stops, smallest to largest: the βΈ button on an agent's card in the Agents section pauses that agent; the βΈ pause button on a Projects card stops every agent working that one repository (owner only, asks for a reason); and the fleet breaker chip in the top bar pauses every running agent at once (owner only) and, when released, resumes only the agents it paused. None of these is a merge brake β PRs already open keep their own state β and the dashboard, heartbeats and polling keep running. See fleet breaker, per-repo pause, and stops, smallest to largest.
Because the guide agent documents your project, not Hive itself. It audits your README, getting-started, architecture, and contributing docs; it does not operate the hive or explain ACMM policy. For Hive operations, use these docs and the dashboard. See the ACMM policy matrix and agent configuration.
For operator setup and community-facing contributor flows, start with hosted hub, getting started, troubleshooting, and contributor relay.
No question matches that filter.