Your crash reports, read by somebody

Crashlytics tells you what broke. It does not tell you which of the forty is worth your morning, write it up, or open the ticket. This does, every hour, and never files the same crash twice.

Set up crash triageFree to try. Nothing to install.

How it works

Three steps, and none of them is “configure”.

01
Connect Firebase and GitHub
Your Google account for the crash reports, your GitHub for the issues. Then say which repository your app's crashes belong to — one line in a file it opens for you.
02
It picks one crash an hour
It reads the ranked report, skips everything already filed, and takes the worst thing left. One per run, done properly — an hour is not long to wait and half a bug report helps nobody.
03
You get an issue, and a note on the crash
A GitHub issue with the impact, the stack trace and its reading of what is happening. Then a note on the Crashlytics issue saying which one it opened, so anyone looking at the crash can see an agent was here.

What it can do

It knows which crash is the fire
Impacted users over raw event counts, a regression in the current version over something that has limped along for a year, and a stack trace pointing into your code over one entirely inside a framework. It says what it skipped and why, so you can disagree.
It will not file the same bug twice
Every crash it files is recorded against its Crashlytics id. An hourly job with no memory would open the same ticket twelve times before lunch, which is the fastest way to make somebody switch it off forever.
An interrupted run is picked up by the next one
It writes down what it is about to do before it does it. If a run stops halfway, the next one reads that note, checks whether the issue was actually filed, and carries on from there rather than starting over or double-filing.

How it is set up

The mechanics, so you know what you are getting before you sign in.

Environment: No sandbox and no shell — it reads one API and writes to another. Scheduled runs get a short-lived credential scoped to one schedule, not a copy of your session.
Tools: Firebase Crashlytics over MCP for the reports, issues, events and notes; GitHub over MCP for filing. readFile, writeFile, editFile, glob and grep for its own records, getCurrentTime, and scheduleRun, listSchedules and cancelSchedule.
Model: Pinned to Claude Sonnet 5, with Haiku 4.5 behind it. The judgement is the product here — deciding whether a crash is worth a person's attention, and writing a report they will act on rather than close.
Starting files: Seeded with a repository mapping and nothing else. The absence of a filed record is what tells the first run it is the first run.
What persists: What it has filed stays with the session, which is the whole reason it can run hourly without repeating itself. Nothing is deleted between runs.

Things people ask it

“What is crashing the most right now?”
“File the worst crash and check every hour from now on.”
“Which crashes have you already filed?”
“Stop the hourly run.”

What it will not do

Every one of these is a real constraint we have hit, not a roadmap item.

It reads crashes and files issues. It does not write the fix — that is a separate job, and it will hand the issue to GitHub Copilot if you have it rather than pretend otherwise.
Connecting Firebase asks for more access than it uses. Google publishes no read-only scope for Crashlytics, so the consent screen says “view and administer”. It reads reports and adds notes; the token never reaches the model.
One crash per run. There are far more crashes than steps in a run, and a whole bug report beats four partial ones.
Scheduled runs cannot ask you anything. Nobody is there to answer, so they act on the instruction as written — which is why it asks you to approve that instruction before booking it.

Which model does this best

Measured over real runs of this agent, per model. A run counts as finished when it produced the answer on its own — nothing failed, nobody was asked to approve anything, and it did not run out of steps. Read all three columns together: a model that finishes fast by giving up scores badly on the first, and one that completes everything by grinding scores badly on the second.

Model	Completion rate	Median cost	Median time	Runs
claude-sonnet-5anthropic	77%	$0.195	71s	22

Completion rate: Runs that finished the job without you having to step in.
Median cost: What a typical run costs, in credits.
Median time: Wall clock, from the first message to the answer.

Medians over the runs behind each row. A model appears once it has 3 runs on this agent, and the run count is shown so you can judge how much a figure rests on.