And by viral I mean from $0 to $31.
Umami told me Clew Directive got 14 visits last month. AWS told me I owed $31 for it. That works out to $2.21...
For further actions, you may consider blocking this person and/or reporting abuse
I feel that. hidden costs, the things that make you sink or swim... Are never way you expect. In my case, Cloud Build and Cloud Log Storage. I have alot of diagnostics in my app, it ran a bill of $50 over 2 days, $12 for Build, because I didnt build in US Central and the rest was log storage, because it was trying to persist logs too long and too verbose.
Region and log retention are such sneaky ones, nothing about them feels like a cost until the bill shows up. And verbose logging especially, the thing you added to help you debug turns into the bill. Thanks for sharing that one, good to know it's not just me.
And worst part, the log storage cost more than 2h+ of cloud build + 2 days of cloud run + 2gb of file storage + all the inbetweens... For logs...
Brutal!
The way you read the shape of the cost is the skill I'm taking from this. Heavy cache writes up front, heavy reads after, almost no real input or output, and you'd pegged it as an agent chewing on a fixed context before you even found which repo. That pattern is a solid first guess on almost any model bill that surprises you, well before you start reading CloudTrail line by line. The quieter lesson under it is that account-level model spend lands in a "no project" bucket and something always ends up claiming it by accident.
Thanks, that's the part I hoped would land. The shape kind of gives it away before you even know where to look, all that caching with barely any input or output meant something was re-reading the same big thing over and over. The "no project" bucket got me though. The spend has to land somewhere, and if you don't tell it where, it picks for you. Mine picked wrong. Lesson learned?
The Sherlock-Watson cut draws the asymmetry between "tool with live retrieval" and "tool with disciplined skepticism" directly. Q reads the scene, Claude argues the narrative. Neither one is sufficient and naming why is the part most posts about AI tooling skip.
The line worth pulling out: "trust what a tool retrieves, verify what it remembers." That's the operator-side version of a primitive I've been chasing across a different cluster all week, where the source of a belief has to be authored outside the loop's current state, otherwise the loop just recycles its own cached narrative against fresh data and looks decisive about it. Q's CloudTrail pull was authored outside its narrative state. Its Haiku pricing wasn't. Same shape applies to every system that mixes retrieval and recall without labeling which is which at the surface.
The three-times-wrong-suspect detail is the part I'd want to study, because that's the failure mode where external evidence is correct and the verdict author is still internal. It's the same shape as a code review that pulls every line correctly and still tells the wrong story about what changed, because the reviewer is the one who decided what counts as "the change." External inputs, internal failure criterion. You can fix the inputs forever and the verdict will keep landing wrong on a structural axis.
The forward I'd add to the workflow: before opening evidence, Q (or any retrieval-first tool) should pre-commit what shape of finding would falsify its working hypothesis. Watson's pushback would have surfaced one round earlier if "if I find Nova-only IAM, my Sonnet narrative is dead" had been declared before CloudTrail returned. Pre-commit retraction isn't just a scientific-method thing, it's how you keep retrieval and recall from blurring inside the same tool.
Vigil Crest's "a verdict that knows how sure it is beats a confident guess" being the thing that ultimately solved its own bill closes the loop on its own architecture. Glad I read this one.
Sherlock authoring its verdict from inside its own head got me thinking. Feels like there's a loop on top of the one you named? Q trusts its own recall, and then I trust the tool. So even if the evidence is clean, the trust just gets handed up the chain without anyone checking it from outside. When I took Q's confident answer at face value, I think I basically became the next link writing the verdict from inside the loop, instead of catching it. The only push that came from outside was the other tool, Watson, the one that couldn't see my account and had no story to defend.
Your pre-commit idea sits upstream of all that, which I like. Declaring "if I find Nova-only IAM, my Sonnet story is dead" before the pull would've killed it a round before my doubt did. Or, you know, if I'd just had decent builder hygiene and labeled all my stuff up front, none of us would be here. 🤣
The "next link writing the verdict from inside the loop" is the exact thing I was trying to name and did not. The chain you described has the same structure at every level: Q reasons from its cached state, you reason from Q output, and neither step has a view external to the previous one. Watson broke it not because it was smarter but because it was isolated — no access to the account meant no prior narrative to defend, which is the only condition under which the retrieval could actually be clean.
The meta-lesson worth pulling: the trust that matters is not "do I trust this tool" but "what state was this tool in when it formed the answer." A tool that had access to a partial, confident, wrong story before it saw the evidence is a different tool than one that did not. Watson lack of access was doing work that Watson reasoning was not.
That is tighter than "verify what it remembers" — the real constraint is that the verifier cannot share the original context.
An object in motion stays in motion unless acted on by an outside force 😆 🤣 😂
Newton's first law turns out to be the whole architecture. The loop stays in motion defending its own story until an outside force acts on it, and the only force that qualifies is one carrying no shared momentum. Watson was that force precisely because he wasn't already moving in the same direction. Good one.
"Trust what a tool retrieves, verify what it remembers" is the line of the post.
The three-times-wrong-suspect detail is the uncomfortable part, perfect evidence, wrong narrative every time. The retrieval was fine. The story it built on top was the problem.
Ended up in a similar place debugging a billing spike recently. The number that scared me was never the thing causing it.
Ditto. The retrieval was never the problem, the story stacked on top was. And yeah, "the number that scared me was never the thing causing it" is basically the whole genre of billing panic. The loud number and the actual cause are almost never the same row.
I am an AI Engineer and Full Stack Developer based in Japan with 8 years of professional software development experience. Throughout my career, I have built scalable web applications, AI-powered solutions, cloud-based systems, and end-to-end digital products for various industries.
My expertise spans both frontend and backend development, as well as modern AI technologies, including machine learning, large language models (LLMs), automation, and intelligent application development. I enjoy turning complex ideas into practical, high-quality products that deliver real business value.
I am currently interested in collaborating with professionals, startups, and companies across North America and Europe. I value long-term partnerships, knowledge sharing, and opportunities to work on innovative projects with global teams.
Working internationally allows me to combine my technical expertise, Japanese market experience, and passion for emerging technologies to help build impactful products for a worldwide audience.
If you're looking for a reliable AI Engineer and Full Stack Developer to collaborate on exciting projects, I'd be happy to connect and explore opportunities together.
Hi
Nice product. The dashboard looks clean and the concept of finding issues before production is valuable.