What the agent does
The agent starts in Sentry, through the Sentry connection named in the request. It finds the latest release, lists the issues that first appeared in it or whose event count rose sharply after it, and reads each one's stack trace, the transaction it happened in, the request URL and the tags. Then it clones the repository into its own cloud sandbox and works out which commits that release contains, by tag, by the commit SHA Sentry recorded for the release, or by the deploy time.
In a site like django/djangoproject.com it first reads how errors reach Sentry: djangoproject/settings/prod.py initializes sentry_sdk at line 87 with DjangoIntegration(transaction_style="function_name") and RedisIntegration(), a traces_sample_rate of 0.1, and no explicit release, so the SDK takes the release from the environment at deploy time. Because transactions are named by view function, an issue's transaction maps straight to a function in one of the apps (blog, docs, releases, members, fundraising, dashboard and the rest). The agent notes the Django version, 6.1.1 in requirements/prod.txt, since a release that also bumped Django or sentry-sdk==2.66.1 changes what to suspect.
Then it diffs the two releases with git log and git diff between their tags or SHAs, and lines up each new or grown issue with the changed files its stack trace passes through. A TypeError in a view, a DoesNotExist from a changed queryset, a template variable that no longer exists, or a migration that renamed a column each leave a mark in both places. Where the stack trace is ambiguous, it reads the changed code path end to end and, when the bug can be shown without production data, runs the relevant tests with python -m manage test <app> against Postgres in the sandbox, as Makefile and .github/workflows/tests.yml do.
It writes a report naming the most likely change, the evidence from Sentry and from the diff side by side, and the fix it would make. It does not change code, push, open a pull request, or resolve or comment on Sentry issues.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Errors rose after the latest release. Through the Sentry connection, find the issues that are new or grew in that release, diff the release's commits against the previous release in this repository, and write a report naming the most likely change, the evidence for it and the fix. Do not change code.",
"connections": [
"sentry"
],
"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 a Markdown report attached to the session as an artifact. It opens with the two releases compared, their commits and when they went out, then a table of the issues that are new or grew, each with its Sentry issue link, event and user counts, first-seen time and the view function it happened in. The main section names the most likely commit: its SHA, author and message, the lines it changed, and the stack frame that lands on those lines. A second section lists other candidates and why the agent ranked them lower.
The fix section describes the change in words and, where it is short, as a diff the reader can apply, together with the test that would have caught it. The session's transcript keeps every Sentry query, every git command and every test run, so a reviewer can follow how the agent got from the error to the commit.
Before acting, a reviewer opens the linked Sentry issue, checks that the frame and the changed lines really match, and decides between a revert and a forward fix. A follow-up message to the same session can ask the agent to open the fix as a pull request.
Run it on every Sentry issue alert after a deploy
Sentry can call a webhook from an alert rule, for example when a new issue appears in the latest release or the error rate rises after a deploy. Point it at a small handler on your server that sends this request; one alert starts one run, so an investigation is under way before anyone has opened the dashboard.
Set a webhook URL on the API key and Rush POSTs run.completed with the session_url when the report is ready. Your handler can post the report's link in the deploy channel next to the release that caused it.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
Tying an error spike to a commit means reading Sentry, reading the diff and reading the code path in between, usually while the error is still happening. The agent does all three in its own sandbox with the repository, Python and a test database, and its access to Sentry is the connection you named on this run, not a token copied onto someone's laptop.
The report shows its working: Sentry issue links, commit SHAs, file and line, and the test output, with every step kept in the session's transcript. Two deploys that go wrong in the same afternoon get two runs, each with its own report.
Frequently asked questions
How does it get into Sentry?
Through a connection: connect Sentry's MCP server once, then name the connection in the request's connections, as in the example. The run gets only the connections it names.
We don't set release in sentry_sdk.init. Can it still compare releases?
Usually. The SDK can pick up the release from the environment, and Sentry records first-seen times for each issue, which the agent matches to deploy times and tags in the repository. The report says which method it used, and recommends setting release explicitly if the mapping was uncertain.
Will it resolve, assign or comment on Sentry issues?
No. The prompt asks for a report and no code change, and the agent only reads Sentry. Anything you want written back, ask for in a follow-up.
What if the spike comes from a dependency bump, not our code?
The diff includes requirements/*.txt, pyproject.toml and uv.lock, so a bumped package shows up as a candidate like any other change. The report then points at the package's changelog entry and the frame in its code.