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 a visitor, which would make it the most expensive free learning-path tool in California.
Spoiler alert: 14 visitors, $31, and not a single one of them was the reason.
Something was off. Here is how Amazon Q, Claude, and a few hours of reading my own code untangled it. The app turned out to be innocent.
What Clew Directive is, quickly
A free, stateless tool that builds you a personalized AI learning-path PDF. You take a 60-second Vibe Check, four questions about your goals and how you learn, and it maps you to free, verified resources and hands you a briefing. No accounts, no database, no paywall, nothing stored about you. It runs on Amazon Nova, which is why it costs close to nothing to operate, which is also why a $31 bill made no sense.
The name is the Theseus kind of clew. A ball of thread to find your way out of the maze. Less hype, more direction. Live at clewdirective.com.
The number that didn't add up
Twelve visitors, 14 visits, 93% bounce, average session about a minute. Referrers from Bing, Google, Yahoo, GitHub. Visitors from the US, India, Netherlands, Egypt, Ethiopia, Singapore. Mostly crawlers stopping by to say hello.
A few curious humans and a parade of bots is not a $31 month. So either every visit was doing something enormous, or the bill was never about visits at all.
The dashboard lied, politely. An Amazon Q Story
My cost tracker said Clew Directive was running on Claude Sonnet. Sonnet is the expensive one. Case closed, right?
I opened the repo. Clew Directive does not run Sonnet. The Navigator agent runs Amazon Nova 2 Lite. Scout and Curator run Nova Micro. The IAM policy is scoped to Nova ARNs only, so a Sonnet call from these functions would come back AccessDenied. The app physically cannot bill Sonnet.
The math agreed. A full learning-path generation on Nova costs about two-tenths of a cent. Fourteen visits, even with the agents fanning out to a few calls each, rounds to lunch money. Nothing here gets you to $31.
One detail I want to flag, because it set the tone for the whole hunt. The same assistant, Q, that mislabeled the model also quoted me Haiku pricing at a quarter of the real rate. So here is the rule I kept coming back to: trust what a tool retrieves, verify what it remembers. Those are two different things.
Asking a better question
The question stopped being "why is my app so expensive" and became "what is actually spending, and why is it wearing my app's name."
Q pulled the breakdown. The month was 28 million tokens across only 8 active days, and two of those days did 70% of the work. May 24 and 25. Memorial Day weekend.
The shape of the cost was the real tell (Sonnet only):
- Cache writes: 4.1M tokens, $15.33 (55%)
- Cache reads: 23.8M tokens, $7.14 (26%)
- Output: 346K tokens, $5.20
- Input: 120K tokens, $0.36
The fingerprint
A web app serving 14 visitors does not look like that. Heavy cache write up front, heavy cache read after, almost no real input or output, is the signature of an agent reasoning over a big fixed context. It loads that context once, caches it, then re-reads it on every turn.
Clew Directive does no prompt caching at all. So whatever ran up the bill, it was an agent chewing on a large cached context, not an app answering users. Which pointed me at a very different project.
It was me, over a long weekend sprint
Clew Directive had zero commits on May 24 or 25. Last time I touched it was May 9.
A different repo lit up. vigil-crest. Created May 23, four commits on May 24. And I know exactly what it is, because I wrote a whole article about it and published it on, of course, May 24.
Vigil Crest is a challenge-triage agent I talk to on Telegram. It browses the live DEV challenge feed and tells me which hackathons are worth my time. Its stack, in my own published words: AWS Bedrock running Claude Sonnet 4.6, reached through an EC2 instance role so no credentials sit on the box, hosted on an always-on t3.micro. Read that back against what CloudTrail handed me: an assumed role, vigil-crest-bedrock-role, on an EC2 instance, calling claude-sonnet through the streaming API. (I am not pasting the full ARN. Account IDs stay home.)
Same project. Same box. Same model. The weekend I shipped it.
So the $28 was vigil-crest, on Sonnet, while I spent two days hammering on it before submission. Each triage run caches a fat context, the agent persona, the stack file, the rendered challenge feed, then re-reads it across turns. That is the cache-heavy shape, exactly. Whether it was the agent's own test runs or the tooling I built it with, both ran on that one EC2 box under that one role. Real work, priced correctly, just filed under the wrong project.
Q was Sherlock. Claude was the Watson who argued back.
I want to shine a light on how this got solved, because neither tool did it alone and neither did I.
Amazon Q in the console has one thing Claude does not: keys to the building. It reads my live account. CloudTrail, Cost Explorer, the actual deployed config, the IAM principal behind a single call. That is the force multiplier. I do not have CloudTrail memorized and I am not going to hand-read every IAM policy at 9pm. Q walked the crime scene and came back with the role name, the instance, the timestamp, the model, in minutes. That is the legwork no amount of reasoning replaces.
But access is not the same as the right conclusion. Q pulled clean evidence and attached the wrong story to it three times. It was a runaway process. It was your app. Check your application logs. Every pass, perfect data, wrong suspect. The evidence was never the problem. The narrative on top of it was.
Claude could not see my account at all. What it could do was refuse the easy story and push the evidence back through the actual code and the math. The repo says Nova. The IAM says AccessDenied for Sonnet. The token shape says agent, not app. It also said, out loud, that it could only see my commits and not my deployments, so part of this was inference and I should confirm it. A tool telling me where its own knowledge stops is worth more than one that sounds certain.
So Q was the detective with the magnifying glass on the real scene, and Claude was the Watson who kept asking does that actually follow. The twist is that in this case Watson is the one who pushed back on the detective. Sherlock had the keys. Watson had the doubt. I had to point them at each other and refuse to take the first confident sentence either one offered.
There is a tidy irony in here. Vigil Crest, the agent that ran up the bill, is built on exactly this idea: a verdict that knows how sure it is beats a confident guess. It hedges its calls on purpose. Solving its own bill came down to making my tools do the same thing, separate what they pulled from what they assumed. The agent's whole design philosophy is what cracked the case it caused.
What I learned, hopefully
The bill was never about traffic. Umami is client-side JavaScript. It counts browsers that run my script. It cannot see bots, it cannot see API calls, and it has nothing to do with Bedrock spend. I had tied two unrelated numbers together and scared myself.
The project label was a guess, not a fact. Bedrock charges are account-level. They do not inherit the tags of whatever called them. Unless you set up Application Inference Profiles and call those, every model dollar lands in a bucket marked "no project," and something has to claim it. Mine claimed Clew Directive by assumption.
The cost that bites you is the quiet one. The $31 sprint is over. June reads $0. The token burst was loud and self-limiting, it ended when I closed the laptop. The thing that does not end is the EC2 box under Vigil Crest, billing by the hour because it is meant to stay on. A small always-on t3.micro is cheap, but cheap and forgotten is how standing costs sneak up. Know what you keep running, and why.
The AI tools were useful and wrong in the same breath. Q read CloudTrail and Cost Explorer cleanly and narrated the wrong story three times, blaming my app on every pass. Claude caught the bad pricing and read the repos, and still had to admit it could see commits, not deployments. The actual work was pinning each claim to a source instead of to a confident sentence. Trust retrieval. Verify recall.
So no, Clew Directive did not go viral. It served 14 people and a crowd of crawlers and cost me almost nothing, which is exactly what it was built to do.
The bill was me, in a trench coat made of EC2, building the next thing.
Tell AWS. I want them to know it was me.
Clew Directive is free and open source. Find your way out of the AI-course maze at clewdirective.com.
AI Assisted. Human Approved. Powered by NLP.
Top comments (16)
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.