Skip to main content
Building an agent is a loop: run it, see what it did, change something, run it again. When your coding agent drives that loop, it needs to see what the agent did as clearly as you would, and it can’t afford to wait minutes for a full run on every change. The Laminar debugger is that loop, built for a coding agent to run. Claude Code, Cursor, or Codex runs your agent, reads the resulting trace in Laminar to understand what worked and what didn’t, changes your code, and runs again, with each rerun served from cache up to the point it’s testing so the turn is fast and cheap. Every run lands in one session you watch live.
Debugger session view showing a named investigation with a markdown note and expandable trace segments

​
The iteration loop

One turn of the loop has four steps. A coding agent with the Laminar skill runs all four on its own; you can run any of them by hand.
  1. Run. Start your agent with LMNR_DEBUG=true. The run is traced and recorded into the session.
  2. Read. Open the trace in Laminar and read the transcript: the agent’s inputs, every LLM turn, every tool call, sub-agents collapsed into cards. This is where what worked and what didn’t becomes obvious, for you and for the coding agent reading the same trace.
  3. Change. Edit the agent: the prompt, a tool, the control flow, whatever the trace pointed at.
  4. Run again. Rerun against the recorded trace. Everything before the call you’re testing comes back from cache instantly; only your change and what follows it run live. The new run is a fresh trace in the same session, next to the last one.
The point is the turnaround. A long-running agent can take minutes end to end, and the call you’re fixing is often three-quarters of the way through. Caching the prefix means the coding agent can take that turn dozens of times in the span it would take to run the agent live once. See how caching works for the mechanism.

​
Who drives the loop

The loop is the same whoever runs it, and you watch it from the same session view either way. Hand it to a coding agent and watch: with the Laminar skill it runs your agent, reads the trace, edits your code, and reruns on its own, writing a note before each turn so you can follow along without touching the terminal. Stay in the loop by reading each run as it lands and pointing the agent at the span that’s wrong, or drive it yourself: every step is a CLI command or an environment variable, no coding agent required.

​
Sessions and replay

Two primitives make the loop work:
  • Sessions group every run from one investigation so the turns sit together. The traces appear in order in the Laminar UI, so you (or your coding agent) can compare attempts and follow the notes on each one. The first LMNR_DEBUG=true run starts a session and writes .lmnr/debug-session.json; every later run in the same directory rejoins it automatically, so neither you nor the agent copies a session id between runs.
  • Replay is what makes a turn fast. Rerunning against a recorded trace serves cached LLM responses up to the boundary you pick and runs everything past it live, so you only pay for the calls your change actually touched. See how caching works for the mechanism.

​
What’s next

Setup

Install the CLI, run setup, and let your coding agent take it from there.

The debugger process

The full run, read, change, and rerun loop your coding agent runs, step by step.

How caching works

What gets cached, how the input hash works, and which integrations support it.

Browser Use debugger guide

End-to-end walkthrough debugging a Browser Use agent.