--- title: "What a Week of AI Coding Agents Actually Cost Me" url: https://pragmaticleader.io/ai-coding-agents-week-cost/ author: "Aaron Wise" published: 2026-10-31 description: "Real numbers from one week of Claude Code and Codex — cost, cache savings, CI minutes, what ran, and what broke." categories: ["Engineering", "Leadership & Management"] tags: ["engineering leadership", "human-AI collaboration", "cloud cost optimization", "DevOps", "AI security"] --- # What a Week of AI Coding Agents Actually Cost Me Last week I let AI coding agents do most of my typing. Claude Code and Codex built features, fixed bugs, ran deploys and wrote a fair amount of this site. At the end of the week I ran Actualis, a local tool I built that reads the agents' session logs, to see what that actually looked like. I expected a cost number. I got a much more useful picture. ## The week in numbers - **6,733** agent messages over 7 days, across two agents - **2,201** shell commands the agents ran on my machine - **About $861** in estimated API cost at list prices: $778 for Claude Code, $83 for Codex - **97%** of input tokens served from the prompt cache, which saved an estimated **$6,945** - **31** places where a secret showed up in a session log The four busy days cost between $180 and $220 each. One quiet Sunday cost $1. Spend tracked how much I let the agents run, not how hard the work was. ## What it shipped Cost only means something next to output. The same week, across my GitHub organisation: - **169** pull requests merged, **151** issues filed and **291** commits on main branches across 19 repositories - **2** production releases of CirqleSync, each behind two human approvals - **1,390** CI runs, about **146 hours** of build and test time That's roughly **$5 of agent cost per merged pull request**. The CI number surprised me more than the API bill. Agents open pull requests constantly, and every one triggers builds, tests and security scans. If that had all run on GitHub's hosted runners, it would have been a real line item. Almost all of it ran on a Mac mini in my office: only **462 minutes** used GitHub's hosted machines, about **$3.52** at list price. When agents multiply your pull requests, they multiply your CI bill too. Plan for it. For scale: an engineer who merges 10 to 20 pull requests in a good week would need two to three months for that output. Not every one of those pull requests is a feature, and some exist only because an agent fixed its own earlier mistake. But the week shipped real work across five products, and I didn't write most of the code. ## Caching did the heavy lifting The headline number is the one that didn't happen. Without prompt caching, the same week would have cost roughly nine times more. Agents re-read the same files, the same instructions and the same conversation over and over; caching turns that repetition into a discount instead of a bill. The lesson for a team is simple: if you run coding agents and don't know your cache hit rate, you don't know your cost. Long-running sessions on a stable codebase cache well. Constantly restarting agents in fresh contexts throws that saving away. ## What the agents actually ran The cost was the least surprising part. The interesting part was the list of what ran. Over two thousand shell commands is a lot of activity nobody reviewed line by line, me included. Most were exactly what you'd expect: tests, builds, git, package installs. But "most" is not a control. When I looked, I could see every command, which session ran it and why, and I could check whether anything was downloaded or installed that I hadn't asked for. The guardrails earned their keep. Across the week, my permission settings and I stopped the agents 74 times: 42 times I said no myself, and 32 times an automatic check or a rule blocked the action first. Those blocks were the system working, not failing. They are also invisible unless you look for them. ## One pull request, start to finish A small example from the week. My job-search tool was ignoring the "remote" flag on one job board's listings, so remote roles were scored as if they required an office. 1. I described the bug in one sentence. The agent found the parser, fixed it and added tests. 2. Before merging, it noticed something I hadn't asked about: the fix would make the next nightly run treat a couple of hundred existing listings as "changed" and pay to re-score all of them for nothing. 3. It opened a second, follow-up pull request so a flag-only correction updates the listing without triggering a re-score, and merged it before that night's run. 4. CI ran both on the Mac mini, and the agent merged each once it was green, which I'd allowed for that tool. My part was the one-sentence bug report and a read of the diffs afterwards. The interesting step is the second one. The agent caught its own side effect because it looked at what the change would do to real data, not just whether the tests passed. ## What broke Not everything went smoothly, and the failures were more instructive than the successes. - **A security fix that failed review three times.** A change to how my tools flag scam job postings went through an automated security review after each push. Each review found a new way a scammer could word a posting to slip past it. After the third round we stopped adding rules and changed the design: wording that looks like an anti-scam notice now lowers a warning instead of removing it. Agents are fast at writing rules and equally fast at writing rules with holes; an independent reviewer caught what the author didn't. - **A release that was cut too early.** The release tooling refused to tag a version because the commit hadn't finished deploying to staging. It was right; we re-ran it a few minutes later. The guardrail cost ten minutes and prevented an untested release. - **A fix that broke something else.** One agent added two events to an analytics allowlist; older stored data didn't have them, and a dashboard panel crashed. A second agent session working in the same codebase caught it and shipped the fix before anyone saw it. Two agents reviewing each other worked better than I expected. ## The part that should worry an engineering lead Thirty-one times, a secret appeared in a session log: an API key in a command, a token in tool output. Nothing leaked anywhere, and the report shows them redacted. But session logs sit on a laptop, get copied into bug reports and get pasted into chats. A secret that lands in a log is one careless share away from a problem. None of this showed up in the agents' own summaries of their work. It only showed up when I read what actually ran. ## What I'd tell an engineering lead 1. **Measure before you budget.** Cost scales with how long you let agents run, not with task difficulty. Know your daily spend per developer before you set limits. 2. **Watch the cache hit rate.** It is the single biggest lever on cost. Long, focused sessions on a stable codebase are cheap; constant fresh starts are expensive. 3. **Review what ran, not just what changed.** The diff shows the code. It doesn't show the 300 commands that produced it, the packages fetched along the way or the secret that ended up in a log. 4. **Treat refusals as data.** How often your guardrails fire tells you whether your agents are well scoped. Zero blocks probably means nobody is looking. 5. **Keep the audit local.** Session logs are sensitive. Whatever you use to review them should run on the developer's machine and send nothing anywhere. ## How I measured Actualis reads the session logs Claude Code and Codex already keep on disk and builds a local report: commands, downloads, estimated cost by project and model, cache savings and secret exposures. Costs are estimates at public list prices, not invoices. It's free, open source and runs entirely on your machine: [actualis.app](https://actualis.app). The agents did a week of real work for about what a senior contractor charges for a day. The bill wasn't the story. The visibility was.