Context
Project-aware startup
A compact brief carries repository rules, current branch/worktree facts and relevant knowledge without asking the model to rediscover them.
hive-pi
A coding-agent harness built to finish the work.
hive-pi turns Pi into an operating environment for real repositories: project context, reviewed tools, visible plans, delegated research, quality gates and native Hive telemetry around every session.
Private-beta surface: delegation and cross-lane parity are still evolving. Interactive workstation Pi and the Factory’s pinned Pi runtime share integration contracts, not an unrestricted extension bundle.
plan · 3/5 · executetext
✓ done Read the failing test and the fixture generator✓ done Regenerate order fixtures with shipping lines▸ in progress Re-run pytest orders/ -q· pending Commit and push to feature/checkout-v2· pending Report the root cause on the pull request- Context
- Repository-aware from turn one
- Control
- Plan, tasks, gates and budgets
- Visibility
- Session state inside Hive
The session loop
Frame, plan, execute, verify—without hiding the transitions.
A conductor advances the lifecycle from signals the session already emits. It does not make a second model guess what the first one is doing.
- 01 · Frame
Load the right world
Repository rules, current worktrees, project context and prior knowledge arrive before the first implementation choice.
- 02 · Plan
Make intent inspectable
Complex work produces a reviewable plan and a verifiable finish condition before mutating the repository.
- 03 · Execute
Use the cheapest useful worker
In the private-beta interactive harness, read-heavy searches and reviews can fan out to bounded subagents while one parent keeps synthesis and delivery ownership.
- 04 · Verify
Close against evidence
Repository gates, held-out checks and PR status—not a confident final sentence—decide whether the work is complete.
Run it on a leased credential
The key never lands on disk, and there is no fallback to one that did.
hive pi is the workstation entry point, and it decides one thing before the model runs: whose credential.
The command materialises your assigned account into a tmpfs directory that is private to you and gone at logout, runs pi against it, and pushes rotations back for the life of the session.
If nothing can be leased it refuses. It does not fall back to a local key, because a session that silently ran on the wrong account is the kind of surprise a spend report cannot undo.
hive pishell
$ hive pi --provider anthropicleased anthropic credential → $XDG_RUNTIME_DIR (tmpfs, 0700, gone on logout)starting pi … $ hive pi --provider anthropic # nothing leasablehive pi: no credential could be leased — refusing to fall back to a local keyHarness capabilities
The mechanics around the model are the product.
Each capability makes a real session easier to understand or harder to fake.
Tools
Typed calls with visible results
Local tools, MCP integrations and project-specific skills show up as explicit capabilities rather than undocumented shell folklore.
Workflow
Plans and execution stay separate
A stable plan records intent; a live workflow records what actually happened, including delegated workers and CI delivery state.
Delegation · beta
Read wide, write through one owner
Bounded interactive workers can explore independent questions cheaply. The primary session reconciles claims and owns edits, verification and delivery.
Guardrails
Policy outside the model
Worktree protection, sandbox paths, credential requests, spend limits and gate checks do not depend on the model remembering a sentence.
Hive native
Telemetry and steering built in
Phase, transcript, plan, workflow, usage and commands flow into the Agents workspace under the session owner’s identity.
One vocabulary, separate runtimes
Parity where it helps. Separation where trust demands it.
The workstation and Factory use Pi for different jobs, so Hive shares the integration contract while keeping execution authority narrow.
Workstation
The full interactive harness
The public hive-pi foundation and tenant overlay provide the daily-driver extensions, agents, skills, themes and workstation setup around Pi.
Cloud session
Interactive Pi in an ephemeral lane
A headless RPC session reports through the same Hive remote and telemetry surfaces, with cloud-specific lifecycle and delivery.
Factory runtime
Pinned, reviewed and intentionally smaller
The Factory image loads only its reviewed extensions. Checkout skills and prompt templates are disabled; the wrapper owns policy and delivery.
Native integration
Hive is the system of record around the session.
The harness does not need to invent a second build, ticket or agent platform. It publishes into the one already operating the repository.
- Plan + workflow
- Intent and live progress render beside the transcript.
- Tasks + teams
- Work can split, report, reconcile and surface overlap.
- CI + delivery
- Branch, pull request and Hive checks remain visible to the session.
- Knowledge + tools
- Searches and product APIs are called through bounded interfaces.
- Usage + budgets
- Tokens, cost and context pressure stay measurable per session.
What hive-pi is not
A harness around Pi, not a model and not a second Pi.
- Not a model
- hive-pi brings no weights and no endpoint. It runs whichever provider your leased credential names — Anthropic, Codex, OpenRouter, Cursor.
- Not a replacement for Pi
- Pi is the agent. hive-pi is the context, tools, plan, gates and telemetry around it — a foundation plus a tenant overlay, not a fork.
- Not the same bundle everywhere
- The Factory image loads only its reviewed extensions and leaves the interactive checkout skills out. Deliberately smaller, so what runs unattended is what was reviewed.
The surrounding system
hive-pi connects human-directed work to the same platform that runs CI.
Private beta
Bring one repository. See the whole system work.
Start on your own runner, keep your existing CI beside it, and watch Hive turn the next eligible red check into a reviewable fix.