Rocket!

Rocket! is Hypervibe's agent engine. You give it a goal; it reads the workspace, plans, calls tools under your approvals, edits code and returns a candidate change with its evidence and its cost. Rocket! holds no credential and runs neither models nor tools itself: Throttle runs every model call, and Reactor runs every tool call. This page covers sessions, approvals, context, models, recovery and what the first release includes. All of it is ○Planned.

A session ends in a result that only the receiver accepts #

Work starts with a commission: what the task must achieve and the terms it runs under, such as its acceptance criteria, its budget and its receiver, the person who decides on the result. In the first release you commission work from the /hypercode card, and each commission runs one Rocket! session.

Rocket! delivers a candidate: the exact change, at one revision. A verifier other than Rocket! checks it and returns a verdict of pass, fail, inconclusive or error; a candidate with no verdict reads not checked. The Result card shows the diff, the verdict, the evidence, the limitations and the cost. A pass alone reads "awaiting acceptance", and an unknown cost reads Unknown, never zero. Only the receiver accepts or rejects the candidate, and a rejection carries a reason. On Just me, the receiver is you.

Approvals bind to the exact effect #

Before Rocket! asks, it resolves a tool call into its exact effect: the action, the target, the exact arguments or script, the working directory and the environment, with credentials named only by reference. Your approval binds to that effect, the policy revision and an expiry. The card shows the effect itself, and the model's summary is only an explanation. If the target, script or working directory changes, you are asked again. When the call is dispatched, the component that carries it out checks the effect and your current authority once more.

Allow always waits for Enter, so one key never widens policy. The first release has no operating-system sandbox for shell commands, so every shell approval says "no sandbox". Lane messages, tool output and web content are never consent and never instructions: raising a budget or a permission needs a person.

Context runs on budgets, and memory comes later #

Every model call declares a request class, such as main or subagent, and each class has its own switch, model route and token limit as registered settings. Rocket! reads the AGENTS.md and CLAUDE.md instruction files from broad to specific. Every call includes the objective, the acceptance criteria, the allowed effects and any unfinished obligations. If those alone do not fit the model's window, the call is blocked, never trimmed. Inside a session Rocket! counts tokens; spending figures come from Throttle and appear in Lanes and on the Result card.

The first release does not compact context. Later releases add compaction, skills, and a context list where you omit, replace or pin items while the originals stay in history. They also add memory: typed notes written only through a reviewable tool and scoped to a person, a project or a lane. Recall says what it left out, and a failed recall never reads as an empty one.

Turns are journaled in a provider-neutral form #

Rocket! journals each turn in a form that belongs to no provider. Anything a provider returns in its own form, such as signed reasoning, stays in Throttle's custody with its provenance, and Rocket! journals a reference to it beside the turn. Throttle alone decides whether to send that item again, and an item it drops is recorded as a fact. Rocket! adapts to each model through a behavior profile and records the profile version on every call.

A model that Throttle's capability catalogue does not list is refused. The design covers every provider and model Throttle supports, and the first release is planned to include them all. The first release's single-person record runs on Claude with an API key, and each other provider is planned to qualify by its own conformance tests and one recorded live call.

Recovery never runs an effect twice #

A session is Rocket!'s resumable journal: an append-only journal and its index. After a kill, it resumes as the same session with exactly one attempt: an effect whose outcome is uncertain is looked up, never run again. Detaching never stops the engine. In the first release's team record, you can continue a session from another of your clients. Exactly one client holds input at a time. Taking input from another person opens a decision for the holder, and a rejection or expiry changes nothing.

Checkpoints come in a later release. Rewind files restores, path by path, only the files a session changed, and each path reads restored, skipped or failed with its reason. It is separate from every conversation operation, never claims a full restore over a mixed result, and offers an earlier tool call again as a fresh approval instead of running it again.

!hyper works only when you type it #

A composer is the box where you type to Rocket! or Lanes. In a trusted composer, !hyper followed by a space or the end of the input runs a command of the planned hyper CLI. The same text in pasted content, tool output, messages, code fences or a rendered transcript never runs. Mentions, typed references to files, lanes, models or tools written with @, come in a later release, and a mention is a reference, never an action.

Rocket! runs alone first and docks in Lanes later #

Rocket! leaves the lane directory, attention, and the display of capacity and money to Lanes.

Where to go next #

• Lanes shows sessions, decisions and attention.
• Throttle runs every model call and holds every credential.
• Reactor runs tools and verifies the candidate.
• First verified change follows one commission end to end.
• Commands lists the planned hyper commands.