Skip to main content
Vexlo records how code actually ran: one execution graph per request, at function level, carrying the real inputs, outputs, and errors each call saw. That is ground truth about a production run rather than a reconstruction of one. People read it in a web UI, AI agents read it through an MCP server, and both read the same /v1 API underneath.

​
What runs where

The Python SDK runs inside your own process, where you mark the functions you want recorded. A marked call appends its records to the SDK’s in-process outbox and returns; the SDK’s writer thread writes them to a spool directory on that host. The relay daemon, one per host, tails that directory and posts batches to the Vexlo server, so a process running the SDK never blocks on network I/O to get a record captured. The server ingests those records, owns storage, and serves them over the /v1 API and the UI embedded in the same binary. Nothing reads execution data any other way: the UI and the MCP server are both clients of that API.

​
What it does not touch

Vexlo injects and modifies nothing on an outbound request, patches no HTTP client, and shares no global state with anything else running in the process. Nothing a team already runs has to be removed or reconfigured first. Nothing is recorded until you mark it, and what is kept from a marked call is subject to the service’s capture policy. The scope stops there: execution data for debugging code, reading it, and changing it. Dashboards, alerting, and metrics are out.

​
Where to go next