Babylon: Proxy-Free Capture and Agent Runtime Traces in Rockxy

Rockxy captures traffic the classic way: it runs as a local HTTP/HTTPS proxy, and you point a device or app at it, then install and trust its root certificate to read HTTPS. That path is well understood and still the right tool for most third-party apps and devices.

But two situations break it. A request that uses certificate pinning refuses the proxy's certificate and never appears. And a proxy only ever sees bytes on the wire — it cannot tell you which step of an agent run issued a call, how long a tool invocation took, or why a workflow branched the way it did.

Babylon is the answer to both. It is a companion capture client that your app links directly. Instead of routing traffic through a proxy, the app streams its own captured requests — and its runtime execution trace — straight into Rockxy over an encrypted connection on your local network. Because the app is the source, pinning and proxy-ignoring stop mattering, and every captured request arrives already tied to the code path that made it.

This article explains what Babylon streams, how the pairing and encryption work, and where it fits alongside the proxy you already use.

Babylon is a client-side capture path, not a second app you launch. It ships as a companion package your app links in its debug configuration — the client is open source at github.com/RockxyApp/Babylon. At runtime it discovers Rockxy on the local network, opens an authenticated connection, and pushes three kinds of data: a one-time connection handshake, ongoing traffic, and structured runtime events.

Rockxy owns the receiving side of the contract. The client implements the documented protocol without importing any Rockxy source, so the two evolve independently and nothing about your app's build depends on Rockxy internals. On the Rockxy side, captured Babylon requests land in the same traffic list as everything else — the same inspector, the same request and response bodies, the same filtering and search you already use.

The proxy and Babylon solve different problems. Neither replaces the other; they run side by side and their captures merge into one list.

Rule of thumb: use the proxy for apps and devices you don't control; use Babylon for your own app, especially when it pins TLS, runs in the iOS Simulator, or executes multi-step work you want to trace.

Every session opens with a connection message so Rockxy can establish project and device identity, then sends traffic and runtime messages in any order after that.

HTTP and WebSocket packages flow into the same views you use for proxy captures. The runtime stream is where Babylon does something a proxy cannot.

A runtime event describes what your app was doing, not just what it sent. Babylon models execution as a small hierarchy:

• A session is one run — an app launch, an agent invocation, a test scenario.
• A trace groups the work of a single logical task inside that session.
• A step is one unit of that task. Steps nest through a parent reference, so a tool call inside a reasoning step keeps its place in the tree.
• Marks, events, and errors annotate the trace with points of interest and failures.

Each event carries a name, creation time, optional start and end times, a duration, an error message when it failed, and up to 100 metadata key/value pairs for whatever context you attach — a model name, a prompt token count, a feature flag, a retry number.

The reason this matters is correlation. A traffic package can carry a correlation context naming the session_id, trace_id, and step_id that produced it, so every request lines up with the exact step that issued it.

Take one checkout agent run — session checkout-agent-run-8f2a, trace resolve shipping quote. In the timeline its steps read cleanly, each tied to the call it made:

For an AI agent or any multi-step workflow, that is the view you actually need when something goes wrong. Instead of scrolling a flat list of requests and guessing which one belonged to which step, you see the steps, the network call each one made, and the point where the run failed — in the same window, correlated by id. This is what turns Rockxy from a request viewer into a place you can debug agent behaviour end to end.

Babylon carries request and response bodies off your app, so the channel is authenticated and encrypted from the first captured frame. There is no cleartext fallback.

When you open Rockxy's Babylon pairing window, Rockxy generates 32 cryptographically random bytes, shows them as a 64-character hex pairing token, and stores the token in the macOS Keychain. The token is never sent over the connection and never written to a log — it is a shared secret you copy into your app's debug configuration.

Keep the token in a debug-only configuration, never in a shipping build. Because the whole path stays on your Mac and the LAN, none of this traffic reaches an external server.

Babylon finds Rockxy over Bonjour and connects over TCP. The same port works for a physical device on your network and for the iOS Simulator over localhost.

On the Rockxy side, Babylon lives under its own Babylon menu with two windows.

When to reach for Babylon

Babylon is the right path in a few clear cases:

• Certificate-pinned APIs. The proxy can't read them; Babylon reports them from inside the app.
• iOS Simulator work. Connect over localhost:10909 with no device proxy setup at all.
• AI agents and multi-step workflows. The runtime timeline plus request correlation shows what each step did and which call it made.
• Fast onboarding. When installing and trusting a CA certificate is more friction than pasting a token into a debug build.

Stay with the proxy for third-party apps, for devices you can't modify, and when you need to intercept and edit requests at the proxy layer. The two paths are complementary, and their captures share one traffic list — you don't choose one at the expense of the other.

Frequently asked questions