Marble TorchMarble Torch / ClarityTrace
ClarityTrace records the full call tree, tells you plainly when a capture is partial, and exports a report an AI coding agent can read straight from the file. Built for .NET developers who work alongside tools like Claude Code, Codex and Cursor.
In development.
A profiler that starts after the interesting work, overruns its buffers, or only ever sees one thread will still hand you a report. Most give no sign that the capture underneath it is partial, so you optimise against numbers that describe a fraction of the run.
And the report itself is shaped for a human squinting at a GUI: a trace file you reload into a proprietary viewer, click through, and read one pane at a time. An agent working in your terminal cannot open it.
Every capture is sanity-checked. Too few events, a sample rate that points at an idle target, unresolved symbols, one thread holding nearly all the CPU while others sit idle — each is stated in plain words at the top of the report, before a single measurement.
When the trace session drops events because its buffer was too small, ClarityTrace runs it again at a larger buffer and tells you the numbers describe the second run. The right buffer size cannot be known until something has been captured, so it is measured, not guessed.
Hot methods by self time, the call tree caller to callee, thread and blocked-time breakdown, GC pauses, and allocation hotspots by the code that drove them. Built on .NET's own EventPipe tracing, so a capture is managed frames all the way down.
Plain text to stdout, written to be read once in order by a person or an assistant. No viewer, no export step. An agent that can run a shell command is already integrated, with nothing to set up.
One run, one plain-text report. It leads with the capture's own health, then your code first, because those are the rows you can go and edit.
CAPTURE QUALITY: suspect. Read these before the numbers below.
- Thread 8104 holds 98% of the CPU samples while 5 other
thread(s) were seen doing almost nothing.
Events: 230610 | Samples: 3053 | Threads: 7 | Duration: 8.0s | Backend: EventPipe
CPU samples: 3032 | Blocked (app waiting): 9 | Parked: 12
Your code (CPU self time, charged to the deepest frame in your solution):
1. Program.Crunch (self 2307, 76.1%) - Program.cs:15
Allocations: 17.5 GB sampled across 175219 GC allocation events
1. ByteReader.ReadBytes (208.2 MB, 37.0%) - ByteReader.cs:64
- allocated in System.IO.FileStream.Read (100.0%)The profiler detects which runtime a process was built against and picks the matching backend for you. You never choose one.
Linux, macOS and Windows. EventPipe is the same managed capture path on every operating system.
.NET Core 3.0 and .NET 5 or later, captured through EventPipe. Time spent waiting off the CPU is measured alongside time on it.
Framework targets on Windows are captured through ETW, with an option to measure time spent waiting on I/O and locks, not just CPU.
Ships with a profiling skill that teaches a coding assistant when to profile and how to read the report. Any agent that runs a shell command is integrated, with nothing to configure.
Attach to a process that is already running, so a slow service keeps the state that made it slow, or launch a target and stop the capture when it ends.
Compare two saved runs as rates and shares, never raw counts, so a fix shows as a fix. Vanished and new methods are marked.
Allocation hotspots charged to the code that drove them, and GC pauses measured suspend-to-restart, not collection duration.
The same trace renders identically every time, so two reports diff cleanly as text and nothing shifts under version control.
In development. For early access or questions, email hello@marbletorch.com. Product support is at support@marbletorch.com.