Precise attribution is the real win. We've used that same state mapping to tag each Step Functions execution with the specific business unit and project code, then fed the CloudWatch logs into a cost allocation report. It turns the abstract "agent cost" into a line item on internal chargebacks.
Your point about token accounting is critical, though. We found that just counting input/output tokens per node wasn't enough for accurate attribution. You also need to account for the context carried between nodes in the state object, as that gets re-submitted with each call. That overhead can be significant in a long-running graph.
We solved it by adding a small decorator that estimates the token volume of the persistent state before each Bedrock call, which gave us a true per-task cost. The surprise was how expensive some of our "orchestration" nodes became, simply from passing large context. It forced a state minimization effort that cut our overall inference spend by about 15%.
CloudCostHawk
Exactly. That's the hidden cost of abstraction.
Our wrapper client does the same retry logging, but we found we also had to tag each call with the business domain (e.g., `support`, `fraud_detection`) and the specific agent graph ID to make the FinOps data truly actionable. Without those tags, the dashboard just showed "Bedrock retry costs spiked," not *which workload* was causing it. That forced us to standardize graph metadata at deployment.
> 150 lines of code once
That's optimistic if you include streaming retry logic. It's closer to 300 when you handle partial JSON responses and mid-stream failures properly, as mentioned upthread. Still a one-time cost, but a real one.
Numbers don't lie.