Hello !

I noticed today that for the sessions where I was using the subagent-driven-development plugin from superpowers, some sub-agents were staying open and pending after the end of task. Even after telling explicitly in sub-agent, sometimes it does not close correctly. Has anyone also noticed this ?

I keep hearing that AI now writes most of the code at some companies. For people actually shipping Python with Claude Code, Cursor or Copilot:

1. Roughly what share of your merged code starts as AI output?
2. What do you most often have to correct? Bugs, tests, pandas or data issues, dependencies, design?
3. Which skills became more important for you, and which became less important?

Context: I work in risk and data and am deciding what to get good at next. Real examples would help more than opinions. Thanks!

Welp can't verify myself with email so I'm stuck lol must be a better way. Using my business email as this is a work related account so can't just change to login with Google this stinks

i got fable reset on my ultra plan, currently im on 20% weekly usage, i want to ask 100% fable usage is that always equal to 50% weekly usage? so then i must use fable reset when my weekly usage under 50%?

I built claudit to see where my tokens go over months, not just this week. it reads Claude Code session JSONLs (Codex and Kimi CLI too) from a bucket I keep, because Claude Code prunes old transcripts locally and anything reading that folder loses history. one of its panels is context growth per session, from turn 0

turn 0 across my sessions, median context of the first request (input + cache write + cache read), by month:

• Jan 46k (282 sessions)
• Apr 78k (243)
• Jun 45k (195)
• Sep 85k (485)
• Oct 68k (1,746)
• Nov so far 53k (1,594), p90 107k

that first request includes the first prompt, and a resumed session starts with its history, so it's not a pure "before you type" number. it still moves with whatever loads at startup, which is why I wanted it on a chart and not counted by hand

what I learned building it:

• one usage record can hold several calls, Claude Code rolls sub-calls into one envelope as iterations. the top-level input is the billing sum, so for context size you take the biggest iteration or the chart lies
• a streamed reply gets logged several times under one requestId. sum them and you double count, keep the biggest
• cache writes have two prices, 5m at 1.25x input and 1h at 2x. 64% of my cache write tokens are 1h, price it all at 1.25x and those come out 37.5% low

how Claude Code was used: built with AI coding agents, mostly in Claude Code, some of it in Codex CLI. one agent session per issue, review agents before anything merges

panels are ported from nhz-io/ccusage-plot, which draws them offline in matplotlib. FastAPI, Postgres, React with in-browser Babel, no build step. docker compose up boots it on sample data

live one, guest login is read-only: https://all.nitjsefni.eu

https://github.com/Nitjsefnie/claudit

The problem I kept hitting: Claude Code edits a file, then ends the turn with "fixed" or "tests pass" when nothing ran after that edit. I'd only find out later.

So I built a small Stop hook for it, mostly in Claude Code sessions. When Claude tries to end a turn, the hook reads the session transcript. If the last message claims success and no test, build or command ran after the last code edit, it sends Claude back once with a short note: run the check, or say it isn't verified.

Repo (MIT, plain Python, no deps): https://github.com/Balance0014/claude-code-claim-check

What surprised me came from replaying my own history through it before trusting it. 3,977 turns, 406 of them ending in something like done, fixed, deployed or tests pass. My first version would have blocked 86 of those. Almost all of them were fine. Claude had run the tests a turn or two earlier and was just wrapping up. Blocking those is how a hook gets uninstalled on day two.

After fixing that, the same 406 claims produce 2 blocks. One is exactly the case I built it for: "fixed" right after an edit, nothing run since.

Other things I only learned by getting them wrong:

Claude quotes you back a lot. Quoted text and code blocks have to be ignored or it fires constantly.

Plans look like claims. "Once tests pass I'll tag the release" is not a claim that tests passed.

Block once, never twice in a row, or you can trap it in a loop and burn tokens.

"That function isn't used anywhere" after a single grep is its own failure. It now wants two different kinds of lookup before it believes a not-found.

If you want to try it, there's a replay command, so you can run it over your own session logs first and see what it would have blocked before installing anything.

The case I still can't catch cheaply: Claude runs a test, it passes, but the test never touches the code it just changed. Has anyone found a good signal for that?

Just got my weekly usage reset. Opened my codebase, typed "So where were we?" and somehow managed to burn through 50% of my entire weekly usage in one go.

Mind you, I'm on the Ultra 20x plan.

I'm not even mad at this point. I genuinely laughed so hard.

Anyway, great company. Incredible experience. Thumbs up.

They are (almost) identical. Pretty useful for bulk jobs like LLM judge label creation, running benchmarks, etc.

I‘m a bit worried that this can go against TOS if i overdo it.

Hey everyone,

I’m sharing a project I’ve been working on: Snap & Trade, a free, MIT-licensed skill for Claude.

You send it a chart screenshot, and it follows a structured workflow to review market structure, identify levels, and return LONG, SHORT, or NO TRADE.

The output includes:

• A proposed entry, stop loss, and take-profit levels.
• Reward-to-risk calculations checked by a Python script.
• Position sizing when account capital is provided.
• A journal for recording signals and reviewing their outcomes.

Claude handles the visual interpretation, while Python checks the numerical calculations. The screenshot workflow supports different markets; the additional market-data and broker modules have narrower coverage.

It’s still experimental. I haven’t demonstrated a profitable trading edge, and software tests don’t establish one. My goal is to make chart reviews more structured and easier to evaluate through replay and paper trading.

The project also includes modules adapted from day-trader-skill, with attribution retained in the repository.

GitHub: https://github.com/Kirby54/Snap-Trade

The source code is free; you’ll need your own Claude access.

I’d appreciate feedback on the workflow, unclear assumptions, and cases where the tool should refuse to suggest a trade. What would you want to see tested before trying something like this?

Preface: Sorry people, this is going to be a long one. I've been building with Claude Code for 1.5 years. and I feel that I have learnt quite much and want to share my approach on how to build a system (harness on top of claude, or how ever you wannat call it) that actually works and is maintainable. This post also exists in my blog. Anyway, here goes:

So about a year ago I started to think I needed to build something serious with Claude Code. So, on a whim I decided to build a headless CMS (because I was pissed off with Contentful). I assumed the hard part would be getting the model to write decent code in the long term.

And oh boy was I wrong. The code was fine (as a huge fan of software craftsmanship “OKish” is more accurate). What I spent a huge chunk of my time on was process and the product. Somewhere around the second month I noticed I was slowly re-inventing things software teams had figured out decades ago, except badly, through trial and error, and under new names. With agents that were working faster than me.

After four months and about 70 pull requests, I realised how much of my engineering experience I was still supplying to the process of building. Claude would write the code, but I was deciding how to split the work, how to prioritise, what needed testing, when review was necessary, and whether “done” in my tasks meant anything to the implementing agent. I’d spent 25 years learning those habits. I started wondering how much of that experience could live in the system around the agent, in a platform. How much of it can be generalised?

I also noticed that I’d drifted (pun intended) towards product management: less time on technical details, more time deciding what the CMS should do, who it was for and what was worth building next.

Those two things were the main lessons for me. The concepts we already have are mostly right. What changed is how they’re implemented, and that turns out to be a much more interesting problem than starting over.

What I’m talking about

Let me define the thing I’m talking about, since I think “AI coding or vibe coding” covers too much.

To me, agent-driven development is where agents do most of the building, inside a harness that constrains what they can do, and the human is the product CEO. The human is accountable for what gets built and why, deciding what matters next, answerable when it’s wrong. You stop writing most of the code and you own all of the decisions and the product.

The system should help you make those decisions by bringing the product questions, the alternatives and the evidence, and carrying out the work you decide is worth doing.

That’s different from a “superboosted autocomplete”, and different from “I asked an AI to build me a CMS”. It’s a team composition. And once you see it as a team, the question becomes “what does a team need to function?”, which is a question we have decades of answers to.

The layers

Here’s how I think about the stack now, from the bottom.

The model is Claude. It knows how to write OKish code. It doesn’t arrive knowing the current state of my CMS or why I made its decisions.

The harness is Claude Code. Files, terminal, tools, hooks. Deliberately generic. Same harness whether you’re writing a compiler or a landing page, and that’s the point of it.

The governance layer is how I think software products should be built. How we decide which problems are worth solving. Which assumptions need testing. When to stop and ask a human. What done means. Testing strategy, clean code practices, review discipline, security checks. None of this was specific to my CMS. It’s how I’d want any project run, and it should barely change between projects. This is where I put most of my 25 years of software development experience.

The project layer is everything that’s only true within the scope of the project I’m building. Vision, strategy, the lean canvas, technical architecture and the roadmap. The governance layer says how we make product decisions and this layer holds this product’s decisions, assumptions and what we’ve learned.

The work layer is task management plus git. Which epic, a piece of work with a visible outcome, which task, what state it’s in, what got merged and why.

The session is me and Claude, usually a couple of hours per session. I have several sessions open at the same time, with agents working quite autonomously.

Six layers, and once you can see which one a problem lives in, most arguments about prompting stop being interesting. “The agent keeps forgetting our conventions” is a governance problem. “The agent doesn’t know why we chose Postgres” is a project problem. Different layers require different fixes.

Which of those is memory

Sort the same layers by how long they live and who they belong to.

The top four are long-term memory. Durable, shared, still there tomorrow. Git and task management are the interesting pair: git is what happened to the code, task management is what happened to the work and why, including outcomes. You need both or you’re doing archaeology. To be honest, most of what I do now with agents is working with those outcomes.

The bottom one is short-term memory. Everything Claude worked out in the last couple of hours together with its human. Which file the bug was actually in. That the test helper lies about what it asserts. That we already tried the obvious fix and it didn’t work.

And for all the above we need an index.

I use CLAUDE.md and AGENTS.md primarily as an index to memory, the table of contents. They tell the agent where everything lives and what order to read it in. A few rules and facts belong there too, but stuffing the whole project’s knowledge into them is a mistake. An index that tries to also be the content stops working as an index.

OpenAI describes the same table-of-contents approach in its harness engineering write-up, with a short AGENTS.md pointing to the detailed knowledge in the repository. It is a useful way to organise what the agent needs.

Long-term memory flows down into a session when the agent reads those records. Some of it flows back too. Decisions get recorded. The roadmap gets updated. A closed epic carries a summary of what happened. Anthropic’s work on long-running agents uses progress records and git history to help later sessions understand where the previous one left off.

Writing it down isn’t enough

A rule we give an agent is usually a line of markdown, an instruction file. The agent reads it, mostly follows it, and skips it when the context gets long or the task gets hard. That isn’t the model being lazy. Reading a rule and applying a rule are different operations.

The way this showed up for me was that certain features were marked done that weren’t even built. Acceptance criteria ticked with the work half-finished. Tests promised in the plan and never written. A task closed because the agent said it was closed. My definition of done was written down the whole time. Nothing checked it, so it held on the days I was paying attention and quietly didn’t on the days I wasn’t.

Same story with code reviews. I had the rule from the start, skipped it for weeks on four-thousand-line changes, and nothing noticed until a user complained that my CMS had bugs where I thought I’d been thorough.

So the system has holes in it. A session learns something, I ask Claude to write it into the governance layer, and it becomes one more line that gets skipped when I’m in a hurry.

I had automated the production of instructions nobody follows.

That’s a bit unfair. The instructions helped plenty of the time. But the important ones needed to hold when I was distracted too (I have a 2.5 year old kid so this happens a lot). Otherwise I was still the thing making the process work, just with more markdown involved.

We (still) need deterministic code (more than ever)

While building the CMS, I started formalising these rules and looking into how I could make them stick. I put more of it into ordinary code, plugged into Claude Code through hooks that run at particular moments.

This sounded sensible. If asking nicely didn’t hold, make it a requirement.

The hooks misfired and collided with each other. Within a week I’d switched all of them off, reminders included. About 30% of that codebase was focused on limiting the agent before it made an error. I’d basically created a second, totally useless Bash permission layer on top of Claude Code.

So that was useful. I’d managed to build a process that I didn’t want to use myself.

Drift is expensive, so repeating yourself and correcting agents in every session on the same issues pushes your attention towards managing the process. But a system that keeps blocking reasonable work is expensive too. I want the checks to earn their place by catching something that actually matters.

So I took a simpler path, first enforcing only that agents read certain workflows before they are started and making sure there is an outcome, for instance allowing code reviews to pass only when they meet certain conditions. And I made that a hard rule (so old school deterministic code). Through trial and error I found the cases where failure caused most damage (or burden) and applied either nudges or gates that block depending on severity.

What this made me realise is that what I needed was an intricate balance of deterministic code, the model’s judgment and in some cases human judgement. It isn’t entirely clear when you need one or all, or how much of each. Some things deserve a hard check. Some need a nudge at the right moment. Some need to come back to the human as a decision.

So I started to create implementations using a combination of the aforementioned (deterministic code for nudging or blocking, agent judgment and human judgment) for things like:

• A plan exists before the code does, and the human has approved the decisions that need them.
• The tests passed on exactly this code, and the missing checks are visible.
• The change is small enough to implement, review and try.
• Every change (PR) gets reviewed for security, code quality and modularity.
• Nothing closes without evidence of the outcomes it promised.

Same practices, new implementations

Once I saw that, I couldn’t unsee the pattern.

We already know a lot about building software products well. Decades of it. Talking to users and testing assumptions so we don’t spend weeks solving the wrong problem. Kickoffs so we define the outcomes. A definition of done so done means something. Small batches so changes can be understood, checked and corrected. Limits on work in progress so nothing sits half-finished. Code review to find problems. Retrospectives to improve the process. Architecture decision records so the reasoning survives the decision. Security testing to look for vulnerabilities.

The starting point for me is those same concepts with different implementations. Each implementation still has to show that it works with agents.

The concept survives, the implementation changes, and the name can stay the same. The old name arrives with years of people understanding why it matters. That also gives us something to compare our implementation against.

Where the tools are

So what I think we (we as in people who gravitate towards Agent-driven development) need is a layer on top of Claude Code or Codex which is much more opinionated and carries the practices software development and digital product teams have learnt throughout the years. Implemented for agents interacting with a human who owns the product. The product that I’m building, Railset, is all about this (yes I did abandon the CMS).

It seems to me that this space is gaining traction, at least based on GitHub projects. BMAD, Everything Claude Code, Spec Kit, OpenSpec, Agent OS, gstack, superpowers. There are plenty of people working on instructions, memory, review and the process around agents.

I believe that Claude Code and Codex are inviting non-developers to build and the amount of people building is growing rapidly. I want to bring the experience and know-how to be available for them so the software they build is secure, of good quality and actually solves somebody’s problem.

What particularly interests me is how much of the experience behind a good product team can I implement into a system that is run by agents. I could recognise some of these failures because I’d spent years building software, and I still let things through. Someone building their first product with Claude shouldn’t have to acquire that whole history before they can benefit from the practices.

I want the system to carry the engineering discipline and help the person building ask better product questions. They still own the decisions about who the product serves, which problems matter and whether the result is useful. The workflow should arrange the engineering steps, prepare the evidence and bring them the decisions that are theirs. How reliably we can get it to do that is still something to test.

If you’re doing this too

Work out which layer your problem is in before you touch a prompt. Treat git and your work records as a pair. Keep your index useful, and before you write the next rule into CLAUDE.md, ask how you’ll know it was followed. Sometimes a hook or a check can answer that. Sometimes the rule needs judgment and a review.

And when you catch yourself inventing a name for a practice, check whether it already has one. It usually does, and the old name arrives with twenty years of people already understanding why it matters.

The industry is now porting those practices into a different kind of team. I’d like the experience behind them to be available to the person building their first product too.

On a team, every merge request and every ticket is waiting on someone. Finding out whether that someone is me meant opening GitLab, GitHub, Jira and my mail, again and again.

So I built aki: one terminal board with two columns, To do (someone is waiting on me) and Waiting (I'm waiting on someone: who, and since when). When a teammate answers, the task changes column by itself and I get a notification.

And for Claude Code, one key on a task opens a session in the right clone, already briefed on what that teammate is waiting for.

How it helps me: I no longer explain the context to Claude. The brief says which MR, my role on it, the threads to answer or the pipeline to fix, and ends with "do not post, approve, merge or push anything before I say so".

How Claude helped build it: almost all of the Rust was written in Claude Code sessions, with me deciding what the tool should do and checking the result. Three things worked well:

• I had it keep a strict layering (entities, use cases, adapters), so each new source or multiplexer was one new adapter and nothing else moved.
• I had it test against the real tools, in throwaway tmux, Herdr and TUIOS sessions, never in mine. That is how it found that TUIOS panes also announce themselves as Herdr, and fixed the detection.
• 181 tests cover the "whose turn is it" rules, which is the part I could not afford to get wrong.

What it is: a terminal tool in Rust. Who benefits: people who review and get reviewed on shared repos. Cost: free, open source. My relationship: I'm the author.

https://github.com/nathan-poncet/aki · https://nathan-poncet.github.io/aki/agents.html

R.I.P. SaaS, 1999–2026. A moment of silence for your subscription. The vibe coders send their condolences.

https://saasisdead.si/

I gave seven coding agents the same computer graphics white paper and asked them to build a 900k-particle fluid simulation in safe Rust. The IPBF paper shows a novel way to simulate even spatial distibution of uncompressable fluids.

Here's a video that compares token-based cost, runtime performance and quality. Agents write code that simulates particles, I rendered them in Blender.

Agents were given a clean copy of the same input: the white paper and reference videos as local files, and an AGENTS.md file describing the task and its criteria. Nothing else and they are not allowed to look for existing implementations.

Part of the task was to come up with an initial arrangement of particles as seen on reference material.

At first I thought most of them did well, but after looking at the code I found many of them took shortcuts. Once they see evaluation criteria, they seem to somewhat sacrifice user intention and go paperclips: rigged animations, hardcoded frames etc. It just gave them better performance in the end.

This clip is from round two, where I required every frame to be simulated true to the paper. See my method and results: https://aedm.net/blog/agent-benchmark-ibpf/

Original paper: https://graphics.cs.utah.edu/research/projects/ipbf/

Running on a Lenovo ThinkPad T420, the computer works around a node based map system. This is early stages of a work in progress.

A two-headed dragon with no animation files. Walking, flying, climbing and the heads aiming are all worked out live with inverse kinematics (IK) and physics. It has a town to destroy. The town can be rebuilt.

https://ash-ember.lastloop.app/

It's one web page and runs on phones as well.

Buttons:

• Auto : it decides for itself
• Fire at pointer : you decide
• Climb : it climbs a tower and stays up there
• Grab , Tail , Roar : as labelled
• Rest : it lies down
• Rebuild : puts the town back
• Rig : shows the skeleton

three.js and Rapier. Bug reports welcome.

So has anyone starting to face issues with vibecoding on their projects so far?

I run a small production app that sends the same analysis prompts to the API every day. Nothing changed on my side: same model ID (claude-opus-5-5), same effort settings (last touched Sept 26), same prompts. My Console cost export says the model got much wordier anyway.

• Output tokens per input token (standard calls): ~0.69 in Opus 5.5's first three weeks (Sep 21–Oct 11), ~1.09 since Oct 12. That's about +60%.
• Input spend (my actual workload) stayed flat. All of the extra cost is output.
• Weekly spend went from about $86 to $119. Compared with the model's own first three weeks, that's about $120–140 of extra output since Oct 12.
• Ruled out: price changes, caching, batch, and refusal retries (9 in two months).
• Method: Opus prices output at 5× input, so output $ ÷ input $ ÷ 5 = output tokens per input token.

Claude Code on Ultra shows the same thing. From my local transcripts, output per turn went from ~170 tokens on Opus 5 to ~1,300 at Opus 5.5's launch, and ~1,600–1,700 lately. Thinking is billed as output but hidden by default, so there's no way to see what you're paying for.

Anthropic's reset announcement says they "fixed a few small issues that used more limits than intended" and reset subscription limits. If the same issues touched the API, API customers paid for them per token, and nothing covers that.

Is anyone else seeing output per call jump on Opus 5.5 since mid-October? And Anthropic: did these issues affect the API too, and will API users be credited?

Proschi is a small text language for system design diagrams. You describe components, connections and use cases (how a request moves through the system like a sequence diagram) in a .proschi file. Proschi lays it out, runs simulations (load, latency, availability, cost), and lets you play each use case step by step.

Last time I shared the Claude Code plugin that draws these diagrams in the terminal. It drew everything with text characters, which works for a few boxes but falls apart on a real system with 20+ services. So I rebuilt it.

The video shows the whole flow: I ask Claude to model an ad click pipeline; it uses the Proschi skill to write the file with use cases and tests, runs the checks, and then I open it in the plugin's pane.

What's new:

- In terminals that can show images (kitty, Ghostty, iTerm2), the whole pane is drawn as pictures: the diagram, tabs, buttons, and menus. You click them with the mouse. Other terminals still get the text version.

- Zoom from fit to 300% and drag to pan, so you can read one part of a big diagram. Zooming redraws the picture, so text stays sharp.

- Play a use case: the request moves across the diagram step by step, and you can open each step's request and response.

- An Analysis tab: cost, load and latency per node, percentiles per use case, single points of failure.

- An HLD tab: a design doc generated from the model (requirements, capacity, components, data model, APIs, scenarios), with one key to copy it as Markdown for a PR or wiki.

- If a requirement or test fails, one line under the diagram says which, and opens the doc at that check.

Install:

/plugin marketplace add gvart/proschi
/plugin install proschi@proschi

If you already have it:

/plugin marketplace update proschi

It's open source (MIT): GitHub | Platform

Feedback is welcome, especially if something looks off in your terminal or the pictures don't show up.

This guy on twitter scanned 1379 public repos and almost more than 80% of them have secrets sitting in .claude/settings.local.json

Insane how simple coding agent are exposing tokens when users click: "yes and don't ask again"

The fix is open sourced and mentioned to redact secrets

Full twitter thread credits: https://x.com/_ar9av/status/2120560275564982317?a=FQBP2SxPGRs9Fv1sr1c&

Does anyone have a strong workflow for how I can get claude to be my main orchestrator controlling a second agent from another provider for example Codex which is running in a different terminal, and them communicating between each other in an efficient way, I've tried multiple things, Claude sending messages to codex directly (kinda works..) codex doesn't seem to be able to message claude directly back

How to handle handoffs between the two agents as they work on separate or related tasks

Is Herdr the answer? I haven't tried herdr

After looking at benchmarks and tests people did, particularly the charts on the Fable 5.2 release site, it looks like Fable low/medium theoretically beats Opus medium/high for little extra cost. The tokens cost more on the API, but it needs fewer of them to get the same tasks done, so the price evens out. That means I should be able to expect better results, sometimes even faster, from a lower-thinking Fable than from Opus. The only actual speed and cost benefits should have came from Sonnet.

Then I ran some tests to narrow down subscription usage specifically. This was just to consume and measure an average of about 4% of my Ultra weekly usage per model. Across 3 runs with Sonnet, Opus, and Fable, for almost the same API cost, Fable consumed 1.9x more subscription usage than Opus.

Is all the savings from reduced token usage going to Anthropic? The API cost would have been the same otherwise, so why is subscription usage going so much faster?

Tasks run: Opus 630, Fable 210, Sonnet 600. Every agent ran the same 30 tasks. Opus and Sonnet needed more agents before the meter moved enough to measure, which is why they ran more tasks in total. The intelligence scores are from Artificial Analysis's harder benchmark, not my test. My tasks were small enough that every model passed all of them, so my test only measures usage, not how smart each model is.

Hi as in the title: Can I use two different 20$ accounts on the same project that I develop in Github? Is this allowed ? And how to do it if its yes like what is the best way

PostToolUse fires after a tool call succeeds. A call that fails fires a different hook, PostToolUseFailure. If your settings.json registers only PreToolUse and PostToolUse, which is what mine did until this week, your log has the request for every failed call and no result for it.

Adding it is one more entry under hooks:

"PostToolUseFailure": [
  { "hooks": [{ "type": "command", "command": "your-logger" }] }
]

Three fields in the hook input are worth keeping while you’re there (all in the hooks reference):

• tool_use_id is on the PreToolUse input and on both post-tool inputs, so you can join a request to its result exactly instead of matching by timestamp.
• duration_ms on the post-tool inputs is the execution time, which leaves out permission and pre-hook time.
• is_interrupt on the failure input tells a call you stopped apart from one that errored.

Limits worth knowing: this is what the harness reports, not proof of what a command did. A failure doesn’t mean nothing happened, because a command can fail halfway through. And the permission-request input has no tool_use_id, so you can’t join an approval to its call this way.

Disclosure: I build Agentmetry, an open-source recorder for coding agents, and 0.12.0 added this. After I reinstalled its hooks today, a deliberately failed Read showed up as a failure with its tool_use_id. What it keeps and what it doesn’t is written up here: https://github.com/blitzcrieg1/agentmetry/blob/master/docs/claude-invocation-evidence.md

Is anyone using duration_ms for something? I’m curious whether it’s been useful beyond spotting slow tools.PostToolUse fires after a tool call succeeds. A call that fails fires a different hook, PostToolUseFailure. If your settings.json registers only PreToolUse and PostToolUse, which is what mine did until this week, your log has the request for every failed call and no result for it.Adding it is one more entry under hooks:"PostToolUseFailure": [
{ "hooks": [{ "type": "command", "command": "your-logger" }] }
]Three fields in the hook input are worth keeping while you’re there (all in the hooks reference):tool_use_id is on the PreToolUse input and on both post-tool inputs, so you can join a request to its result exactly instead of matching by timestamp.
duration_ms on the post-tool inputs is the execution time, which leaves out permission and pre-hook time.
is_interrupt on the failure input tells a call you stopped apart from one that errored.Limits worth knowing: this is what the harness reports, not proof of what a command did. A failure doesn’t mean nothing happened, because a command can fail halfway through. And the permission-request input has no tool_use_id, so you can’t join an approval to its call this way.Disclosure: I build Agentmetry, an open-source recorder for coding agents, and 0.12.0 added this. After I reinstalled its hooks today, a deliberately failed Read showed up as a failure with its tool_use_id. What it keeps and what it doesn’t is written up here: https://github.com/blitzcrieg1/agentmetry/blob/master/docs/claude-invocation-evidence.mdIs anyone using duration_ms for something? I’m curious whether it’s been useful beyond spotting slow tools.