What the agent does
The agent clones the repository into its own cloud sandbox and starts from the trace described in the prompt: checkout traces at 6 s p95, with the time in a span below the ad service, after the adHighCpu feature flag was turned on. In the OpenTelemetry Demo it reads src/flagd/demo.flagd.json and finds adHighCpu defined as "Triggers high cpu load in the ad service", state: ENABLED with defaultVariant: off, beside adManualGc and adFailure. A flag that is enabled but defaults to off only takes effect for the evaluation context that targets it, which the agent notes for the timeline.
Then it follows the flag into the code. In src/ad/src/main/java/oteldemo/AdService.java, getAds reads the session id from baggage, sets it as the targeting key, and calls CPULoad.getInstance().execute(ffClient.getBooleanValue(AD_HIGH_CPU_FEATURE_FLAG, false, evaluationContext)) on every request, before it looks up any ads. problempattern/CPULoad.java starts THREAD_COUNT = 4 worker threads when the flag is on. The agent records the lines, what the threads compete with (the gRPC handler threads that answer getAds), and which spans should show it: the server span for getAds, the getAdsByCategory span from @WithSpan, and the manual getRandomAds span.
It also checks the premise. The prompt says checkout traces, but src/checkout/main.go makes no call to the ad service; only its generated stubs mention it. The ad service is called by the frontend, through src/frontend/gateways/rpc/Ad.gateway.ts from pages/api/data.ts, and that gateway sets no deadline. So a slow ad span inside a checkout-page trace is the frontend waiting on ads while rendering, not the checkout service, and a missing deadline lets one slow dependency hold the whole page. The agent says so in the report and ranks that as its own suspect.
Last it reads the 30 most recent commits with git log and git show for changes to the ad service, the flag file, the frontend gateway and the collector config in src/otel-collector, and writes for each suspect the TraceQL or metrics query that would confirm it in Grafana Tempo. It changes no code.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Incident: Grafana Tempo shows checkout traces taking 6 s at p95, with the time spent in a span below the ad service, after the adHighCpu feature flag was enabled. Read the code, the flag definitions, the collector configuration and the last 30 commits. Follow the flag from src/flagd into the ad service and confirm which service actually calls the ad service. Find the most likely causes, and write incident.md with a timeline, each suspect with file and line evidence, the spans it should appear in, and the TraceQL query that would confirm or clear it. Change no code.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is incident.md as an artifact on the session, with a download link the session read returns. It opens with a timeline built from the flag change and the commits, then ranks the suspects. Each names the file and line, quotes the code, says which span names and attributes should carry the delay, such as the getAds server span and demo.ad.count, and gives the TraceQL query that would show it in Tempo.
It includes a short section on the call path as the code defines it, with the frontend calling the ad service and the checkout service not calling it, so the trace the alert came from is read correctly. The session's transcript keeps every file the agent read and every command it ran, so a reviewer can check each claim against its source.
Before acting on it, the engineer runs the TraceQL queries, compares getAds latency with the flag on and off for the targeted sessions, and decides whether to turn the flag off, add a deadline to the frontend's ad call, or both. A follow-up message to the same session can ask the agent to make the code change on a branch and open a pull request.
Run it on every latency alert from Tempo metrics
A Grafana alert on span-metrics latency, or on Tempo's derived RED metrics, can notify a webhook when p95 crosses a threshold. A handler on your server turns that into this request with the service, the span name and the window, so each alert gets a cited first pass.
Set a webhook URL on the API key and Rush POSTs run.completed when the turn finishes. The handler takes incident.md from the session's artifacts and attaches it to the alert or posts it to the incident channel.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
A polyglot system like this one has Go, Java, TypeScript and more in one repository, and a latency spike can start in a feature flag, a thread pool or a missing deadline in a different language from where it shows. Reading across them on a laptop during an incident is slow. In a Rush sandbox the agent reads the whole repository on its own disk and checks the call path against the code while the engineer watches traces.
Each suspect in the report has a line, a span and a query, and the transcript keeps everything the agent did, so the on-call engineer confirms instead of searching. Several alerts can be investigated at once, one run each, up to the key's concurrent run limit.
Frequently asked questions
Does the agent read my traces directly?
In this run it reads the code and writes the queries for you to run. If you want it to query Tempo itself, connect Grafana Cloud as an MCP server and name it on the run.
Why does it question the prompt?
Because the trace's shape has to match the code's call graph. In the OpenTelemetry Demo, the checkout service does not call the ad service, so the report says where that span really comes from rather than accepting the premise.
Can it handle services in different languages?
Yes. It reads Java, Go, TypeScript and the rest the same way, following gRPC definitions and generated clients between services to find who calls whom.
Will it turn the feature flag off?
No. The prompt says to change no code, and the agent has no access to your running flagd. The report says what turning the flag off should change, so you can confirm it before and after.