I’ve previously evaluated agent telemetry frameworks ranging from enterprise cloud-based LLM observability stacks (like Langfuse, Phoenix, or Arize) to manual text scraping scripts that grep raw local terminal files. Cloud observability platforms are incredibly powerful for tracking production traffic, but they introduce heavy external network piping, complex SDK instrumentation overhead, and data hosting liabilities that make them poorly suited for rapid local debugging. Conversely, custom local logging scripts are notoriously brittle, lack unified cost projections, and fail to calculate multi-turn token distribution models. I chose to leverage agentfdr because it isolates terminal diagnostics into a lightweight, zero-configuration canvas—delivering heavy-duty visibility into token burn profiles and recursive loop anomalies without forcing you to change a single line of your existing project setup.
Hi Product Hunt! 👋
A few weeks ago I left Claude Code running overnight. In the morning: 2M tokens gone, and the "fix" was editing the same file in a loop for 40 minutes. I had no idea *why* — the evidence had scrolled away.
Then I realized: Claude Code already writes a complete transcript of every session to disk. Nobody was reading it.
agentfdr is the crash investigator's toolkit for those recordings:
🛫 A per-turn timeline of every tool call, the context window's composition, and output tokens
🚨 Automatic anomaly flags: tool loops, error streaks, context bloat, cache thrash
🔍 A dissection panel for any turn — what it saw, what it did, what it cost
📊 Plan usage (5-hour window / weekly) with calibratable budgets
🚦 A CI gate: `agentfdr assert --no-loops --max-tokens 2M`
Zero instrumentation — `npx agentfdr` and you're looking at your own sessions. Nothing leaves your machine. MIT licensed.
Zooming out: working with coding agents is quickly becoming loop engineering — you design and operate the loop your harness runs: what enters the context, which tools fire, when it stops. You can't engineer a loop you can't see. agentfdr wants to be the instrument panel for that discipline.
Fun fact: every screenshot in the gallery is agentfdr dissecting *the session in which Claude Code built agentfdr itself* — flags and all. 🛬
I'd love your feedback — especially which agent CLIs to support next (Codex CLI? Gemini CLI? Aider?).
@kamihork This would've saved me a genuinely maddening debugging session. I run an AI copilot that drafts documents through a multi-provider fallback (Gemini → Groq), and the failure that actually got us wasn't a loop — it was a quota-exceeded error from the provider getting silently caught and re-labeled as a fake "monthly plan limit" message shown to users. Real cause invisible for way too long. Does agentfdr's anomaly detection reach that far upstream — provider-level errors/fallbacks getting swallowed or misrepresented — or is it scoped to session-level patterns like loops and token burn?
@medal411 That scenario is painfully relatable. Honest answer: the detectors today are session-level patterns (error streaks, refusal stop-reasons) — they don’t semantically classify provider errors. But the part that would have saved your debugging session is the dissection panel: agentfdr shows the raw recorded tool results and messages, so a “monthly limit” message that doesn’t match the actual API error would be sitting right next to the real failing calls, verbatim. A detector keyed on upstream error signatures is a great idea — custom/pluggable rules (YAML) are on the roadmap, and this is a strong use case for them. Filed it.
@marcus_mark
This is a really sharp observation — completely agree that the failure usually happens at interpretation time, and the execution is just faithfully carrying out a misreading. Thanks for putting it so clearly.
Honest answer: the transcripts don't record an explicit "intent" layer, so there's nothing to surface directly. But there are good proxies already on disk, and agentfdr shows two of them: the model's thinking/reasoning blocks right after your prompt (that's where the interpretation actually happens — it's in the turn dissection panel), and the first assistant message, which is usually the model restating its plan. When a session drifted on me, the misreading is almost always visible in one of those two places.
Where I want to take this: agentfdr already anchors every turn back to the prompt it serves, so it can compare what you asked for with what the agent touched — e.g. your prompt says "fix the login bug" and by turn 30 it's editing the router. A drift flag that fires when the tool/file footprint stops overlapping with the prompt's scope is very doable as a local heuristic, no cloud calls, and it would point at the turn where the divergence started — which is one click away from the reasoning that caused it.
I've added this to the roadmap. If you have a session where this happened, agentfdr blame output (redacted as needed) in a GitHub issue would be gold for getting the heuristic right: https://github.com/kamihork/agen...
the "assert --no-loops --max-tokens" gate is the part i'd actually want running unattended, not just the timeline after the fact. question on tuning it though: some loops are legitimate, retrying a failing test until it passes, polling a build, re-reading a file after an edit. how does it tell that apart from a genuinely pathological loop before it kills the run? is the anomaly detection just repetition-count based, or does it look at whether the tool calls are converging toward something (diffs shrinking, errors changing) vs just spinning in place
@galdayan Great question, and you’ve hit the honest limitation: today the loop detector counts consecutive repetition of tool-call signatures (n-grams of tool + target) — it doesn’t judge convergence. That’s deliberate: the flags answer “where should I look first,” not “this is bad,” and the timeline next to them is the evidence. Two mitigations in practice: legitimate retry loops usually interleave with other calls or end in a success after errors, which reads differently on the timeline; and assert lets you pick which checks gate an unattended run — e.g. skip --no-loops and gate on --max-tokens / --max-errors instead, which are convergence-agnostic. Convergence-aware detection (diminishing diffs, changing error messages vs. identical ones) is exactly where I want the detectors to go. Would you expect a “loop but converging” state, or just fewer false positives?
@kamihork leaning toward fewer false positives first - a "loop but converging" state is a nicer abstraction but it's a harder claim to get right, and a wrong convergence call that lets a bad run keep going unattended feels worse than an overly cautious flag you have to dismiss. cut the noise on legit retry patterns first, add the nuance once that's solid.
@galdayan That ordering argument is convincing — for a tool people run after walking away, a wrong "it's fine, it's converging" call is the expensive failure mode, and a dismissable flag is cheap. Noise first, nuance later. You've talked me into it.
What exists today: .agentfdr.json lets you suppress legit retry signatures explicitly ("suppressLoops": ["Bash:npm test", "Edit:*"], exact or prefix) — that came from launch-day feedback here. But that's manual noise-cutting; the detector itself can get smarter without making any convergence claims. Two cuts I'm looking at: treating interleaved edit→test→edit→test cycles as work rather than flagging them like identical-call spins (the current n-gram signature can conflate them), and shipping sane default suppressions for the obvious retry idioms (test runners, build polling, dep installs).
Once the false-positive rate on real sessions is boring, then a "converging?" annotation can sit on top as extra context — worded as a hint, never as an all-clear.
If you have sessions where the loop flag cried wolf, the signatures it printed (agentfdr blame ) would be really useful for getting the default suppression list right: https://github.com/kamihork/agen...
@kamihork The interleaved edit-test-edit-test cut makes sense as the first fix, that's probably the single most common false positive shape. I don't have a session saved where it cried wolf on me specifically, most of my loops have been the actually pathological kind, but I'll open an issue if I hit one. Good luck getting the false positive rate down, that's the unglamorous work that decides whether people trust the gate enough to actually run unattended.
How does it actually surface the anomaly flags in real time during a session, and is there any way to set custom thresholds for things like token burn before it pings you?
@akkocaseng49172 In live watch mode the whole model re-renders as the transcript grows (a cheap mtime probe every 2s), so anomaly chips appear in real time as detectors fire — you’ll see a loop flag show up while the loop is still running. Viewer thresholds are fixed heuristics today, but two things are configurable now: assert limits (--max-tokens 2M, --max-errors 10 — you can run it against a live session from a script), and plan-usage budgets with warning bars in the Usage tab. Desktop notifications on threshold-cross are a good idea I’d like to pair with pluggable rules.
does the anomaly detection work offline too, or does it need to ping anywhere to flag loops and token burns? curious how it stays 100% local with that kind of analysis.
@ayhankroglpz1m Fully offline, yes. Parsing, detection, the viewer server — all local, and the server binds to 127.0.0.1 only. There are zero runtime dependencies and zero network calls: no telemetry, no phone-home, and even cost estimation uses a baked-in price table rather than an API. The only network you’ll ever need is the one-time npx install; after that you can pull the cable.
How does this handle Claude Code sessions that span multiple branches or get interrupted mid-turn? Wondering if the timeline stays coherent or if the anomaly detection gets noisy when there's a context reset.
@uyanbal77090 The parser is built defensively for exactly those cases. Interrupted mid-turn: a tool call whose result never arrived shows as “(no result recorded)” instead of breaking the turn; malformed or unknown lines are counted and skipped, never fatal — the transcript format isn’t a published API, so surviving weirdness is the parser’s first job. Resumed sessions (which carry duplicate summary lines) are deduplicated. On branches: the branch is recorded and shown at the session level today; per-turn branch changes within one session aren’t visualized yet — fair catch, and it would slot nicely into the timeline’s marker lane.
finally something that surfaces loop patterns in long claude sessions without making me grep through jsonl files, the live watch mode is genuinely useful when a run starts drifting.
@veli342040 Thank you! The grep-through-jsonl phase is exactly where this started — I had a folder full of flight recordings and no way to read them.
Glad live watch is earning its keep. One tip for drifting runs: the anomaly chips update live too, so clicking the newest one jumps you straight to the turn where things went sideways. And if you want a hard stop for unattended runs, agentfdr assert --no-loops --max-tokens 2M exits 1 the moment a session crosses the line — works in a wrapper script or CI.
Curious — which agent CLIs would you want supported next? Adapters (Codex CLI / Gemini CLI / Aider) are the top item on the roadmap.
Love that you skipped the SDK and just read what Claude Code already writes to disk, zero instrumentation feels like the right call. The per-turn timeline plus automatic loop and token burn flags is exactly what I'd want when something goes sideways mid-session.
@znursemq Thanks — that realization was the whole project, honestly. I spent a while assuming I needed to instrument something before noticing the flight recorder was already running. The trade-off is that the transcript format isn’t a published API, so the parser is written to survive it: unknown line types become meta events instead of crashes, and schema changes are contained in one adapter module. That’s also what should make other agent CLIs (Codex, Gemini CLI) feasible as adapters.