One run.
Every angle.

01 / PROMPTS

What you asked

Use it when you want to find a task and understand the result before examining individual steps.

Prompts is the starting point for a recorded run. The activity calendar shows how many prompts were captured each day, and the recent list shows the request, date, model, tool-call count, and cost when available.

Open a prompt to read the original request, the agent’s answer, and a recap when available. Selecting a prompt gives Tool calls, Sandbox evidence, Context, Chain of thought, and Playground the same run to inspect.

02 / SANDBOXES

Where your agents ran

Use it to connect a run to the environment and project where it happened.

A sandbox is an isolated copy of your project running in RayTrace’s cloud, with Claude Code installed. Sandboxes lists the environments your agents used and whether each is running, stopped, or destroyed.

Open a sandbox to see its ID, host, creation time, upload size, recording status, initial scan, and prompt history. Copy its raytrace connect <sandbox-id> command to open the terminal from your machine.

Create one from your Git project with the CLI, or choose or drop a project folder in the dashboard. The browser shows an upload preview before sending the files.

How each sandbox is isolated →

03 / INITIAL SCAN

How risky each file is to change

Use it before a task to protect important files, and afterward to inspect alerts and activity.

Initial scan ranks project files from level 1 (minimal) to level 5 (critical). A file’s level is the higher of its import reach and its role, inferred from its path. The scan follows imports in JavaScript, TypeScript, and Python; other files are scored by path. Each row explains its score, and you can adjust the level.

Report watches a file for alerts. Restrict refuses Claude Code edits immediately; stopping and starting the sandbox makes restricted files read-only for every tool. The Alerts tab shows recorded events, with optional email notifications. Activity shows network destinations and connection outcomes.

These levels help you choose boundaries around a project. They are not a security audit or a guarantee that a change is safe. For the sandbox boundaries behind them, see Security & isolation →

04 / TOOL CALLS

How the agent got there

Use it to reconstruct the action sequence and compare what the agent was told with recorded evidence.

Tool calls shows the steps the agent took, grouped by model round trip. Each row includes the tool category and name, its command or file, the reported result, a sandbox evidence label, and observed duration when available.

Expand a row to inspect its input and output. Group similar steps to reduce repeated searches, switch to the graph to explore the sequence, or compare recorded runs. The summary includes model, elapsed time, tokens, and cost when available.

The Agent reported and Sandbox columns answer different questions. A reported success can appear beside a missing process or a differing exit code. Follow a sandbox label to its process or changed-file evidence.

05 / SANDBOX EVIDENCE

What actually ran

Use it to check whether a command ran and what it started beyond the agent’s transcript.

Sandbox evidence shows the commands observed by the sandbox’s kernel layer. It records process IDs, start times, outcomes, duration, severity, and links back to matching tool calls. Expand a command to see its child processes—including programs started inside a script.

The summary shows command outcomes and destinations reached on the network. Severity filters help you focus on commands to investigate, and raw events provide a closer look at the collected record.

A process can appear without a matching tool call. A proposed tool call can also have no observed process. Collector gaps and missing matches mean incomplete evidence; a successful exit does not by itself prove the task was solved correctly.

06 / CONTEXT

What the model was working from

Use it to see what information was available and choose an input to test in Playground.

Context breaks the input into three parts: You asked before (earlier requests in the conversation), The model brought (earlier answers and file contents), and Internals (system prompts, tool definitions, environment details, skills, and other harness instructions).

The context-window breakdown estimates how much space those inputs used by the final answer. Open a file entry to inspect what reached the model. For an eligible run, Rerun without this opens Playground with that earlier output removed.

File entries come from recorded tool outputs and commands, not kernel-level file-read observation. Token counts are estimates, and a “used” marker means words reappeared later; it is a clue to investigate, rather than proof that the file caused the decision.

07 / CHAIN OF THOUGHT

Why the agent did each step

Use it when you want a starting hypothesis about why a step followed from the available context.

This view infers likely reasons for each tool call from what the agent could see. Possible sources include your request, earlier tool results, the agent’s earlier plan, project instructions, routine behavior, and exploration.

Step cards show ranked influences when available, supporting quotes, links to earlier steps, and a separate summary of what the sandbox observed. Similar steps can be grouped, and uncertain explanations are marked as unsure or left unranked.

These are model-generated attributions, not the agent model’s private reasoning or established causes. No task is rerun to produce this explanation. Use it to form a hypothesis, then test a change in Playground. This view is available for recorded sandbox prompts with tool calls.

08 / PLAYGROUND

Rerun it from a step

Use it to test whether changing a particular input changes the agent’s next actions or final result.

Playground starts from a selected model round trip in an eligible recorded Claude Code sandbox session. It restores the project snapshot from before that step, then lets the model continue in its own sandbox.

Change the message at that step, exclude a project file and its earlier contents from the fork, or use the advanced controls to edit earlier tool results and project files. An optional check command gives the experiment a concrete pass or fail condition.

Run an unchanged fork as a baseline, or compare edited and unchanged runs across multiple attempts. Review the resulting steps, answers, check output, and file differences. Open a fork’s tool calls to inspect it like any other recorded run.

Forks require a usable snapshot and a supported sandbox session. The preview explains when a selected step cannot be forked. Repeated unchanged runs help you distinguish a change in input from ordinary model variation.