Objectives become sprints
Define the outcome and acceptance checks; HiveRunner turns the goal into a scoped sprint of owned tasks before agent work begins.
Product
The command center for goal-to-sprint agent work.
HiveRunner turns a goal into a sprint, splits it into tasks, and routes them to your agents — with visible runs, runtime lanes, and review gates so the work moves fast without disappearing into a black box.
Features
The operator surface for practical agent work.
HiveRunner focuses on the parts of agent coordination that need clear state: goals, sprints, ownership, progress, review, and context for the next run.
Workers have ownership
Assign builders, reviewers, operators, and specialists without losing track of who owns each next move.
Execution is inspectable
Follow task status, heartbeats, run transcripts, artifacts, comments, and validation from one operator surface.
Memory carries forward
Preserve decisions, transcripts, memory, and run history so the next session starts with useful context.
Local files stay central
Keep the work close to your repo, terminal, local database, and generated artifacts instead of a remote black box.
Humans keep closure control
Review plans, approve risky handoffs, and decide when work is actually done.
Real operator surface
Hives make runtime choices visible before work starts.
The command center shows profiles, lanes, verification checks, fallback posture, and model/runtime readiness where operators can inspect them. It is built to make automation understandable, not mysterious.
Profiles
balanced, cost, local, quality
Lanes
mini, fast, default, review
Control
supervised autonomy
Posture
local-first by default
execution hives
profile selections update lane posture
Balanced Builder
HiveRunner Native · balanced
Default posture for shipping, reviewing, and keeping automation moving without runaway cost.
verification
5/6
checks passed
Cost Saver
HiveRunner Native · cost
Starts with lighter local lanes, then escalates only when the work needs more review.
verification
4/6
checks passed
Local / Private
HiveRunner Native · privacy
Keeps sensitive work on local or operator-controlled sources unless an escalation is approved.
verification
2/6
checks passed
Max Quality
HiveRunner Native · review
Biases toward stronger reasoning and manual review gates for higher-stakes work.
verification
6/6
checks passed
previewingBalanced Builderactiveautonomy: supervised
Mini lanequick first passverified
Fast laneoperator-visible routingverified
Review lanehuman gate requiredwarning
Quality lanereview-ready fallbackverified
First run
Start with a real team instead of an empty shell.
HiveRunner can launch a workspace with starter agents, public-safe role files, bundled portraits, and saved voice choices. Operators can review the team before anything starts running.
- Choose a starter team during workspace setup.
- Bundled avatars render immediately across the app.
- Saved voice choices are attached without blocking setup.
- Provider keys remain optional until the operator connects them.
Starter identities
The team arrives with faces, voices, and working style.
These are bundled agent identities, not placeholders. A new operator can start with a team that already feels distinct, then edit or regenerate anything later.
Vega
Brand / visual systems director
creative voice ready
Toby
UX / product analyst
product critique
Gator
QA / verification lead
review cadence
Prism
Frontend designer
interface craft
Overseer mode
Overseer mode turns agent work into something you can supervise.
An overseer is an AI operator, usually Codex or Claude, that can sit above the board with you. It watches goals, stale runs, blocked cards, review handoffs, and agent ownership, then reports the next decision instead of burying progress in chat history.
This is the workflow direction OpenAI’s Symphony project points toward: coordinate agents around shared work state, plans, tasks, and review checkpoints. HiveRunner gives that pattern a local-first operator surface.
Watch
active runs, stale cards, blockers
Coordinate
workers, reviewers, handoffs
Control
human approval stays explicit
Local-first boundary
Built so the workspace remains the center of gravity.
HiveRunner presents the local path first. The operator loop, workspace context, and review trail are designed to remain close to the machine and repository doing the work.
Boundary checks
- Designed around local workspace files and a local execution loop.
- Default setup does not require a hosted HiveRunner account.
- Operator choices stay inspectable before risky work proceeds.
- External services are integrations you choose, not a hidden dependency.
Compatibility
Fits the tools already doing the work.
HiveRunner is intentionally close to the repository, shell, local app, and review trail rather than a separate black box.
Overseer agents
Use Codex or Claude as an operator-overseer that can watch the board, move work forward, and report blockers while humans stay in control.
Symphony-shaped work
HiveRunner follows the same higher-level pattern OpenAI describes with Symphony: manage work on a board, not one coding-agent prompt at a time.
Codex, Claude Code, and Gemini
Coordinate first-class coding runners while keeping task ownership, transcripts, and final review visible.
Hermes and OpenCode
Bring command-line workers into the same goal, task, artifact, and review flow.
Cursor and browser agents
Use HiveRunner as the operating layer around agents that work in editors, browsers, or local shells.
Bring-your-own runtime
The local-first boundary is designed for adapters and scripts you can inspect, replace, or disable.
FAQ
Straight answers for the local-first path.
Is HiveRunner a hosted product?
Not yet. The public path is local-first: local app, local auth, local workspace files, and a local execution loop you can inspect.
Is it open source?
Yes. The website points to the public HiveRunner repository so developers can inspect the code, clone it, and run it locally.
Which agents are supported?
Codex, Claude Code, and Gemini are first-class runners; Hermes, OpenClaw, and external CLIs round out the set. OpenCode, Cursor, and other CLI or browser agents are compatible when you expose them through a command or another reviewable runner path.
Do I need API keys?
Core local setup can boot without optional provider keys. Keys and local CLI tools matter when you choose to run specific agent or model integrations.
Can I run it on a Mac mini?
That is a natural fit for the current local-first model: one operator machine, a local workspace, and explicit runtime configuration.
Is it production-ready?
It is ready to evaluate as a serious local-first operator tool. Hosted multi-user deployment, horizontal scaling, and polished experimental surfaces are still separate work.