Hyperset opened a private beta for coding agents that can inspect what happened inside a running application: the arguments passed into functions, the values returned and the exceptions thrown. Its October 26, 2026 announcement calls this capability runtime vision. The aim is to give an agent evidence for bugs that source inspection alone leaves ambiguous.
The distinction matters when an application produces the wrong result without crashing. A successful HTTP response can hide a broken business rule, and several explanations may fit the same source code. Hyperset attaches capture to a local application, records a reproduction and lets the agent cite individual observations alongside file-and-line references.
The beta includes Hyperset’s own coding agent and integrations for Claude Code, Codex, OpenCode and Pi. Access is limited to accepted private-beta testers. Cursor is not supported, despite appearing in the announcement’s opening description of the coding-agent market.
One qualification to keep in mind: runtime vision sees the execution you reproduce. It is not evidence about every possible input, and local capture does not mean every captured value necessarily stays off a model provider’s servers.
How Hyperset Captures Runtime Evidence
Hyperset’s capture daemon, lensd, connects to the application through runtime-specific mechanisms. Developers start their service from Hyperset, which runs it as a tracked service with capture attached. According to the company, there is no application SDK to install and no instrumentation change to commit.
The supported capture paths are:
| Application runtime | Capture mechanism | Application source changes |
|---|---|---|
| Node.js | V8 Inspector Protocol | None required, according to Hyperset |
| Python | Preload hook | None required, according to Hyperset |
| Go | Delve | None required, according to Hyperset |
Hyperset lists macOS, Windows and Linux as supported operating systems. Its published material does not specify a runtime-version compatibility matrix. Teams with a particular Python, Node.js or Go version requirement should confirm compatibility during beta access. Hyperset’s runtime-vision page describes the supported runtimes and attachment methods.
The Node.js mechanism has a documented foundation: V8’s Inspector documentation describes a protocol through which clients can exchange debugging messages with the engine. That supports the underlying approach of a separate tool communicating with the runtime. It does not independently verify Hyperset’s implementation or its capture coverage.
“No instrumentation commits” is useful, but it should not be confused with “nothing changes about execution.” Hyperset still introduces a capture mechanism into the development run. For Python, that includes a preload hook; for Go, it uses a debugger. The practical benefit is avoiding a cycle of editing application files to add temporary logging, then removing those edits afterward.
Ambient Lenses Capture Broadly; Watch Lenses Add Detail
Hyperset calls its function-level capture points lenses. A lens records a function’s arguments, return value and any exception it throws.
The company describes two levels of capture:
- Ambient lenses are placed automatically across functions in the workspace, using Hyperset’s map of the code.
- Watch lenses target a particular symbol when the agent needs more detail. The developer then triggers the request again to collect that evidence.
An exception sentinel also catches throws in code without a lens, according to the runtime-vision documentation.
This makes the first reproduction useful without requiring the developer to predict every relevant logging location. It does not eliminate reruns. If the initial capture lacks the detail needed to distinguish two explanations, the agent can place a more focused watch and ask for another reproduction.
I’d treat that as the practical attraction here: the agent can request a more precise observation without turning each hypothesis into a source-code edit. Whether that saves time on a particular project will depend on how reliably the bug reproduces and how much capture the affected functions need.
The Checkout Example Shows What Evidence Can Resolve
Hyperset’s announcement uses a checkout bug to illustrate the workflow. A request includes the promo code FALL25, but the endpoint returns HTTP 200 and charges the full $84. The intended behavior in the example is to reject the invalid code with HTTP 422.
The application’s individual functions look plausible in isolation. The promo lookup returns active rows, a helper returns null when it finds no matching promo, and the total calculator treats null as meaning no discount applies.
The problem is that null carries two meanings: the customer supplied no promo code, or the customer supplied a code that did not match an active promotion. The calculator handles the first case without distinguishing the second.
Hyperset presents this sequence of captured records:
| Capture record | Observation in the example | Why it matters |
|---|---|---|
#4809 | Checkout received FALL25 and an $84 cart subtotal | The request contained a code, and the subtotal was already $84 |
#4810 | The active-promo lookup returned zero rows | The lookup supplied no active promotion |
#4811 | The matching helper returned null | The entered code became an absent-promo value |
#4812 | The total calculation returned $84 with no discount | The calculation followed the no-promo behavior |
#4813 | The charge succeeded for $84 | The incorrect behavior reached the payment call |
This is the company’s worked example, not an independently measured debugging result. Its value is in showing the kind of ambiguity capture could remove. The recorded subtotal and live lookup let the agent reject the competing explanations presented in the example, then focus on the handoff from an empty lookup result to null. The announcement describes a fix that rejects an entered code when no matching promo is found.
The more consequential detail is what the records cannot prove. Zero active rows show that the lookup found no active promotion. They do not, by themselves, establish that the code expired. It could have never existed. Hyperset explicitly separates the inference that FALL25 expired from the observed lookup result.
That is an important boundary for a coding agent. Evidence supporting a fix for an invalid-code path is not automatically evidence for a specific explanation of the code’s history. If the distinction affects the error message, an audit record or a customer-support response, another observation is needed.
Observed, Read and Inferred Are Different Kinds of Claims
Hyperset labels the agent’s explanations using three categories:
- Observed: backed by a numbered runtime record.
- Read: backed by a source file and line.
- Inferred: a deduction made from the available evidence.
For example, a captured function returning null is observed. A source branch that assigns a zero discount is read. A conclusion about why a database record was absent may still be inferred. Hyperset says these labels are mandatory in its runtime-vision system. Its product page describes the record references as sequence numbers that can be opened alongside source references.
My view is that this separation is more useful than a general claim that an agent “understands” the application. It gives a developer something specific to inspect: whether the proposed cause is grounded in an actual run, a code path that could run, or the model’s reasoning.
A citation still needs to be read in context. One return value can support a narrow statement without proving an entire causal explanation. The benefit is traceability, not automatic correctness.
The Hard Edit Gate Applies to Hyperset’s Debug Agent
Hyperset’s own debug workflow adds a procedural constraint before the agent can change code. The announcement describes four steps:
- Reproduce the bug with capture attached.
- Test competing hypotheses against the captured records.
- Record the symptom, rejected alternatives and capture IDs supporting the cause to unlock editing.
- Rerun the original request after the edit and inspect a fresh capture.
In the checkout example, the post-edit behavior is an HTTP 422 response without a payment charge.
Only Hyperset’s own debug agent enforces this hard edit gate. Claude Code, Codex, OpenCode and Pi receive the runtime evidence and diagnosis tools when launched in a Hyperset terminal tab, but their editing remains governed by their own permissions. That distinction is explicit in the announcement.
For teams evaluating the integration, access to evidence and enforcement of a workflow are separate features. Keeping an existing CLI agent may be convenient, but it does not bring Hyperset’s pre-edit constraint with it.
What Stays Local, and What Goes to the Model
Frequently Asked Questions
3 questions
1Does Hyperset require an SDK or instrumentation commits?
Hyperset says no. It attaches capture when the service is started from Hyperset, using V8 Inspector for Node.js, a preload hook for Python or Delve for Go.
