Weekly digest
Codex Rewrites Its Own Prompt Every Turn, Claude Code's Boost Runs to August, NVIDIA's Benchmark Swings Wildly
Week: August 16, 2026 — August 22, 2026
Codex Rewrites Its Own Prompt Every Turn, Claude Code's Boost Runs to August, NVIDIA's Benchmark Swings WildlyShow moreShow less
One GitHub issue this week put a number on a problem a lot of teams have felt but not measured: a Codex CLI session on AWS Bedrock logged 6.7 million cache-write tokens and zero cache hits, because the CLI rewrites its stable instruction prefix from scratch on nearly every turn. That's not a capability story — it's an invoice story, and it sets the tone for this edition. Anthropic, meanwhile, is still calling its 50% weekly usage boost for Claude Code 'limited-time,' even as it extends the deadline again, this time to August 31, 2026 — a reminder that weekly limits, not model quality, are what actually gate agentic coding work. And NVIDIA open-sourced SkillEvaluator to bring rigor to agent-skill claims, only to find its own verified skills ranging from a 77% token savings to a 120% token bloat. Three different stories, one shared lesson: the tooling around agentic coding is outrunning the accounting for it.
GitHub Issue: OpenAI's Codex CLI Burns Nearly 85% of Bedrock Spend Rewriting the Same Prompt
A GitHub issue against openai/codex reports that native Codex CLI sessions on Amazon Bedrock's GPT-5.6 Sol have no way to enable explicit prompt caching, pushing cache-write tokens to nearly 85% of model spend.

A developer running OpenAI's Codex CLI against Amazon Bedrock filed a GitHub issue this week with a number that's hard to ignore: over four days of production use, August 5 to 8, cache writes ate up roughly 85% of the model's estimated spend on GPT-5.6 Sol, per a Cost Explorer-derived estimate in the report. One session logged 76 requests, 6.709 million cache-write input tokens, and zero cached input tokens -- an average of about 88,000 cache-write tokens on every single call. CloudWatch showed no client errors in that window, so this wasn't a broken integration retrying failed requests. Everything succeeded. It just succeeded at full write price, every time.
That's not a subtle inefficiency. It's close to a total failure of caching, in a category of tool -- agentic coding assistants -- that depends on caching to be affordable at all.
Here's the mechanism. Tools like Codex CLI resend a long, largely unchanging prefix on every turn -- system instructions, tool definitions, prior context -- followed by whatever actually changed. Prompt caching exists so a provider doesn't reprocess that stable prefix from scratch each time; it stores it once and charges a fraction of the price on subsequent reads. AWS documents an explicit cache mode for GPT-5.6 on Bedrock built for exactly this kind of workload: long stable prefix, changing tail.
The catch: native Codex CLI requests to Bedrock's Mantle Responses API don't expose the fields needed to opt into that mode. Codex already generates a session-scoped prompt_cache_key, but neither its HTTP nor WebSocket request types include the prompt_cache_options or a cache-breakpoint field that would let it claim a cache read. Bedrock's built-in provider config only handles transport and authentication, not request-body structure, so there's no config-level workaround either. Codex ends up paying full write price for the same stable prefix, turn after turn, instead of the cheaper read price after the first request. The filer notes this builds on an earlier report, #35300, but adds independent production evidence from the native Bedrock provider specifically.
The filer is careful not to overclaim: cold starts, genuinely new prompts, session forks, and context compaction can all legitimately require fresh writes, and the numbers are usage-derived estimates, not finalized AWS invoices. But 85% of spend and an 88K-token average, both drawn from the filer's own Cost Explorer and CloudWatch data, look less like occasional cold starts and more like a missing plumbing feature. The proposed fix is narrow: serialize prompt_cache_options, add a typed cache-breakpoint field, gate it by provider and model capability, and surface cache reads versus writes in per-turn usage telemetry -- so the next person hitting this sees it in the numbers instead of finding out from a bill.
Why it matters
Agentic coding sessions repeat a large, stable instruction and tool-definition prefix on nearly every turn. Without a way to mark that prefix cacheable, Codex on Bedrock rewrites it as full-price cache-write tokens each request, according to the GitHub report, turning what should be a fixed cost into a recurring one.
Practical example
A team running Codex CLI against Bedrock's GPT-5.6 Sol for long agentic sessions should check per-turn token usage now, since the missing cache_write_input_tokens optimization the issue describes means costs scale with prefix size on every request, not just the first.
The takeaway
Until OpenAI or AWS ships explicit cache-control support for Codex's native Bedrock path, teams on GPT-5.6 Sol should assume their stable prompt prefix is being billed at full write price every turn, not cached.
Limitation: This comes from one filer's usage-derived Cost Explorer and CloudWatch estimates in a GitHub issue, not a finalized AWS invoice or an independent audit, so the 85% figure describes one workload's telemetry rather than a universal measure of Bedrock caching behavior.
Editor's view
Our read — not established by the sources above.
What strikes me is that this isn't a modeling bug, it's a missing request parameter, which is a much cheaper problem to fix than it is to diagnose. My guess: this pattern is quietly present across other Bedrock-fronted agentic tools that assume caching works the way it does on OpenAI's own API, and we'll see more of these issues surface as teams start reading their Cost Explorer bills line by line. The open question is whether AWS treats cache-plumbing gaps like this as a provider bug or leaves each client library to discover and patch it independently.
If explicit prompt caching isn't wired into a provider's client library, whose job is it to catch that before it shows up on an invoice: the model provider, the cloud host, or the tool builder?
Primary source
Anthropic Extends Claude Code's 'Limited-Time' 50% Weekly Usage Boost Through August 2026
Anthropic extended its promotional 50% weekly usage boost for Claude Code through August 31, 2026, automatically applying to Pro, Max, Team, and legacy Enterprise plans while leaving 5-hour session limits unchanged, according to Support.

Anthropic has extended its limited-time promotion boosting weekly usage limits in Claude Code by 50%. The support page says it plainly: "We've extended this promotion." The window now runs from May 13 through August 31, 2026 at 11:59 PM PT — roughly three and a half months of extra weekly capacity for developers who hit the ceiling before the week is over. That it needed extending at all is the first clue: a promotion Anthropic could have let quietly expire instead got a new end date, which suggests the original one was working well enough to keep running.
The mechanics are simple. Anyone on a Pro, Max, Team, or legacy seat-based Enterprise plan gets 50% more weekly usage in Claude Code, automatically, with no opt-in required. It applies everywhere the product lives — CLI, IDE extensions, desktop, and web — and developers can check their new ceiling by running /usage in the terminal. Free plans and consumption-based Enterprise seats are excluded, which draws a clean line between subscribers and the metered usage Anthropic already bills by the token. The offer has no cash value, is not transferable, and can't be combined with other promotions. After August 31, 2026, weekly limits return to standard levels, with no billing or plan changes on either end — so nobody needs to remember to cancel anything or adjust a seat.
One boundary is worth noting: the promotion is scoped to Claude Code only. Weekly limits for Claude on web, desktop, and mobile, and for Claude Cowork, are unchanged. That narrow focus is the tell — Anthropic isn't handing out broader usage relief across its product line; it's releasing pressure at the exact point where agentic coding runs get throttled mid-week.
What the boost doesn't touch is just as telling. The 5-hour session limit is untouched — only the weekly ceiling moves. A single coding session was never really the bottleneck for developers running Claude Code through multi-step refactors and repo-wide migrations across several days; the wall people actually hit is the weekly one, when earlier exploratory work in the same week has already spent the budget. Loosening that specific dial, and leaving the session-level one alone, says something precise about where the real friction has been: not in any single burst of work, but in the cumulative total across a week.
It also says something about internal accounting. Extending a 50% boost means absorbing extra inference cost for months across plans that, unlike consumption-based Enterprise, aren't metered per token. That is not a call a company makes lightly if usage were spiking toward margin-threatening territory. The more plausible read: demand from agentic coding workflows is still below whatever ceiling Anthropic modeled when it set standard weekly limits, and loosening the cap costs less than watching developers hit a wall mid-week and reach for a competitor's coding CLI instead.
Why it matters
Weekly limits, not model capability or session length, are the real cap on agentic coding work. A 50% weekly boost lets developers push multi-day refactors to completion instead of stalling mid-week — even though nothing about a single session has changed.
Practical example
A developer running Claude Code through a five-day migration across a monorepo can now burn through roughly 50% more weekly volume before hitting a hard stop — checkable anytime via /usage — without touching a paid Enterprise consumption plan.
The takeaway
Treat this as temporary and calendar it: the increase reverts automatically after August 31, 2026, with no announced plan yet to make the higher weekly ceiling permanent, according to Support.
Limitation: This is Anthropic's own promotional terms, not an independent usage study: the numbers describe the size of the boost, not how many developers were actually hitting the old ceiling or how much it cost Anthropic to grant it.
Editor's view
Our read — not established by the sources above.
My read: repeated extensions of a 'limited-time' promotion are usually a sign the promotional price has quietly become the real price, and the messaging just hasn't caught up. If Claude Code's standard weekly ceiling turns out to be too tight for how people actually use agentic coding tools — spread across days, not single sessions — I'd expect Anthropic to eventually rewrite the baseline limits rather than keep re-issuing time-boxed boosts. What I'd watch for: whether the next extension notice quietly drops the word 'promotion' altogether.
If Anthropic keeps extending a 'limited-time' promotion every few months, is it still a promotion — or has 1.5x weekly capacity become the real price of a Claude Code subscription that the marketing hasn't caught up to yet?
Primary source
NVIDIA Open-Sources SkillEvaluator, Finds Its Own Verified Skills Swing From 77% Token Savings to 120% Token Bloat
NVIDIA open-sourced SkillEvaluator, a tool that tests AI agent skills for Claude Code, Codex, and Cursor by running tasks with and without each skill, and its own benchmark shows a 31-point average gain alongside wide swings between individual skills.

NVIDIA just published the numbers behind its own "verified skills" program, and the honest answer is: it depends enormously on which skill you install. The company open-sourced SkillEvaluator, a tool that runs the same coding task twice — once with a skill loaded into Claude Code, Codex, or Cursor, once without — then scores the difference. Across a snapshot of 300-plus verified skills spanning 30-plus NVIDIA products, taken August 12, 2026, NVIDIA reports an average 31-point lift on a 100-point scale, or 39 points excluding Security, which already scored 97 out of 100 with no skill installed.
That average is the headline. The spread underneath it is the real story. NVIDIA's own token-tracking data shows one skill, jetson-optimize-memory, cutting token usage on a single run from 617,306 to 142,540 — a 76.9% reduction — while trimming execution time from 474.9 to 220.0 seconds, a 53.7% cut. A different skill, cuopt-install, did the opposite in NVIDIA's own single-attempt test: tokens rose from 25,227 to 55,582, a 120.3% increase, with execution time climbing from 34.0 to 41.1 seconds, up 20.8%. Same method, same "verified" label, opposite outcome — these are two single-attempt examples, not catalog-wide averages, but they sit in the same writeup as the headline number, which on its own implies uniform improvement.
The deeper finding: harness choice barely matters next to which product and task is being tested. Claude Code and Codex differed by only about 5 points on average, but per-product Skill Lift ranged from roughly +2 to +46 depending on the domain and how the evaluation dataset was written. Broken out by dimension, Correctness climbed from a 46 baseline to 87, and Effectiveness from 39 to 78 — gains of 41 and 39 points. NVIDIA also flagged something less flattering to the category: Discoverability and Efficiency, whether an agent even loads the right skill and avoids wasted steps, started at baselines of just 42 and 43 out of 100 with no skill installed, climbing by 40 and 35 points once a skill was in place. A skill that goes undiscovered, or loads for irrelevant tasks, doesn't just fail to help — every skill in an agent's context competes for its attention, so the wrong one can drag performance down.
That's a useful admission from a vendor shipping a marketplace of these things, and it means the "verified" badge does less work than it sounds like. NVIDIA's Tier 1 and Tier 2 checks only confirm a skill is safe and non-duplicative before it ships; only the live Tier 3 run, on real tasks inside an isolated sandbox, tells you whether the skill actually helps.
Why it matters
Builders adopting agent skills have mostly relied on vendor claims or gut feel; SkillEvaluator gives a repeatable before/after number instead. But NVIDIA's own catalog shows that number can mean a 77% token cut on one skill and 120% bloat on another — the measurement is only as trustworthy as the evaluation set behind it.
Practical example
A team maintaining a Claude Code or Codex skill library should run `skillevaluator tier3 evaluate` against each skill before publishing it, the way NVIDIA did with jetson-optimize-memory and cuopt-install — that single Tier 3 comparison is what surfaced cuopt-install's token increase instead of shipping it unnoticed.
The takeaway
"Verified" currently means safety-checked and non-duplicative, not performance-guaranteed — treat every skill's Tier 3 score as the real gate, not the badge.
Limitation: These are NVIDIA's own figures from its own verified-skills catalog, most single-attempt runs with no published confidence intervals, so they describe NVIDIA's specific skills and harnesses rather than agent skills generally.
Editor's view
Our read — not established by the sources above.
What I'd watch for next: NVIDIA's evaluation method is spreading faster than the skepticism around it. OpenClaw is already piloting SkillEvaluator scores inside ClawHub's public skill marketplace, and Nous Research is running a related security scanner in Hermes Agent's install flow. Once a Skill Lift score sits next to a 'buy' button, skill authors have every incentive to write evaluation sets that flatter their own skill rather than stress-test it — the same benchmark-gaming problem AI has run into everywhere else. Nobody's published a policy yet for who gets to write the eval tasks a skill is graded against.
If skill marketplaces start ranking listings by Skill Lift score, who should be trusted to write the evaluation tasks — the skill's own author, the platform, or an independent third party?
Primary source
Security Audit Finds 21,000+ Exposed MCP Servers, 91.8% With No Authentication
A security audit found more than 21,000 internet-facing MCP servers, and among a 640-server sample, 91.8% had no OAuth configured, leaving AI agent tool endpoints open to remote command execution.

A security audit found more than 21,000 Model Context Protocol servers sitting open on the public internet — the connective tissue that lets AI agents call tools, run shell commands, and touch credentials on a user's machine. Among a 640-server sample, 91.8% had no OAuth configured at all, leaving those tool endpoints exposed to remote command execution. That same report counted 687 individual instances showing the identical gap. MCP has shipped inside tooling tied to roughly 150 million downstream downloads, according to that report, so a missing-auth default here isn't a lab curiosity — it's sitting behind agents already wired into real developer workflows, each one a direct line to local shell commands and whatever credentials that agent already holds.
Why it matters
An unauthenticated MCP server hands attackers a direct line to local shell commands and the credentials an agent already holds.
Practical example
Teams self-hosting an MCP server for Claude, Cursor, or similar tools should verify OAuth is actually enforced before exposing the port.
The takeaway
Default-open MCP deployments are common enough that checking auth config now beats discovering it later.
Limitation: The 91.8% figure comes from a 640-server sample, not every server the audit counted online.
Primary source
Alibaba's 27B-Parameter Qwen 3.8 Ties GPT-5.6 Luna on Intelligence Index
Alibaba's 27-billion-parameter Qwen 3.8 tied GPT-5.6 Luna (max) at 52 on Artificial Analysis's Intelligence Index, trailing 753-billion- and 1.7-trillion-parameter models by just one point.

According to Artificial Analysis, Alibaba's 27-billion-parameter Qwen 3.8 posted a 52 on its Intelligence Index. That ties GPT-5.6 Luna (max), a system whose scale Alibaba doesn't need to match. Two much larger models edged past it on the same index: one with 753 billion parameters and one with 1.7 trillion, both scoring 53. The entire range, from a 27-billion-parameter model up to one more than sixty times larger, is one point wide. That's the kind of gap that used to separate a frontier model from last year's mid-tier release — now, on this index, it separates the smallest model on the board from the largest.
Why it matters
Parameter count has been the industry's proxy for capability and cost; this result weakens that shorthand considerably.
Practical example
Teams weighing a self-hosted model for coding or agent workloads can now test Qwen 3.8 27B before defaulting to a trillion-parameter API.
The takeaway
Watch whether Qwen 3.8's showing holds on task-specific evals, not just this single aggregate score.
Limitation: One composite index from one benchmark provider isn't proof of equivalence across every real coding or reasoning task.
Editor's view
Our read — not established by the sources above.
Our read: if a 27B model can sit one point behind a 1.7T one, the industry's whole cost structure for "frontier" access is shakier than the leaderboards suggest -- inference bills, not just training runs, are what parameter count has really been protecting. What we'd watch for: whether Alibaba or others can reproduce this gap at even smaller scales, because if 52 turns out to be closer to a floor than a fluke, the moat shifts from who has the biggest model to who has the best data and post-training recipe. The open question nobody's answered yet -- does Qwen 3.8 hold up outside benchmark conditions, on messy real-world tasks the Intelligence Index doesn't capture?
Primary source
OpenAI Says Codex Cleared Five Years of Asana's Technical Debt in Two Weeks
According to OpenAI, Asana used Codex's agentic coding workflows to close a backlog of legacy migrations and technical debt the company estimates would have taken five years of engineering work, compressed into two weeks.

According to OpenAI, Asana used its Codex agentic coding tool to close out a backlog of legacy code migrations and technical debt the company had been putting off, and OpenAI says the work — compressed into about two weeks — is what Asana estimates would have taken five years of engineer time. Both numbers come from OpenAI's own case study, not an independent audit, but the shape of the claim is telling: this isn't autocomplete finishing a function, it's agents grinding through the unglamorous, backlogged migration work that engineering teams typically deprioritize indefinitely because no one wants to spend a sprint on it. If the self-reported figures hold up under scrutiny, this is the clearest vendor proof yet that agentic coding can absorb bulk refactoring, not just autocomplete.
Why it matters
This is the clearest vendor proof yet that agentic coding can absorb bulk refactoring, not just autocomplete.
Practical example
Teams with stalled legacy migrations can point Codex-style agents at that backlog, the way Asana did, instead of new features.
The takeaway
If the pattern holds elsewhere, technical debt stops being managed forever and becomes a backlog agents clear on schedule.
Limitation: Both figures are self-reported by OpenAI, with no independent audit of the code or the debt baseline.
Editor's view
Our read — not established by the sources above.
Our read: the number that matters isn't the two weeks, it's what "five years compressed" implies about how OpenAI and Asana are measuring engineering work in the first place -- if backlog cleanup is now a benchmark vendors reach for, expect every agentic coding pitch this year to lean on a similar before/after estimate, whether or not the baseline was ever going to take that long. What we'd watch for: whether Asana or others publish what actually shipped, not just the time saved, since a cleared backlog and a *correctly* cleared backlog are very different claims.
Primary source
Bun's Zig-to-Rust Rewrite Drowns in More Than 5,000 Open Pull Requests From Autonomous Claude Agents
Bun's Zig-to-Rust rewrite relies on autonomous Claude agent loops that have opened thousands of pull requests, leaving over 5,000 unmerged and stalling stable releases, according to an analysis by Tipiirai.

According to an analysis by Tipiirai, Bun's maintainers are rewriting the JavaScript runtime's core from Zig to Rust using autonomous Claude agent loops running around the clock. Those agents have opened roughly 15,800 pull requests against the repo -- only 790 merged, about 1,600 closed without merging, and more than 5,000 still sitting open, with agent accounts hitting as many as 1,000 pull requests in a single day, far outpacing what any review team could triage. That gap points to something worth remembering about agentic coding: it scales output, not judgment, and without a merge gate the PR count just keeps climbing past anyone's ability to confirm the code is worth keeping.
Why it matters
Agentic coding scales output, not judgment -- without a merge gate, PR volume outpaces quality control.
Practical example
Bun maintainers now triage thousands of agent-authored PRs by hand, which Tipiirai says is delaying stable Rust-runtime releases.
The takeaway
Expect more projects to hit this same wall: agent throughput outpacing human review capacity for merging.
Limitation: These figures come from one outside analysis of Bun's public repo, not from Bun's own maintainers or Anthropic.
Editor's view
Our read — not established by the sources above.
What we'd watch for: Bun's backlog isn't really a Bun problem -- it's what happens when agent throughput outruns review capacity anywhere. If 5,000+ unmerged PRs is what one team accumulates while still writing careful merge criteria, the real risk sits with teams that turn agents loose without that discipline. My guess is the next version of this mistake isn't a stalled release -- it's a project that does merge the flood, and only discovers months later how much of it nobody actually read. The open question: does tooling catch up to gate quality before that happens, or do we just get better at measuring the wreckage?
Primary source
Watch the weekly briefing
This week in AI — video briefing
One concise briefing, with English audio and English or Ukrainian captions.
Start here
What to put to work this week
Concrete moves from this issue — the tool, the step, and what it costs you.
A team running Codex CLI against Bedrock's GPT-5.6 Sol for long agentic sessions should check per-turn token usage now, since the missing cache_write_input_tokens optimization the issue describes means costs scale with prefix size on every request, not just the first.
Read the storyA developer running Claude Code through a five-day migration across a monorepo can now burn through roughly 50% more weekly volume before hitting a hard stop — checkable anytime via /usage — without touching a paid Enterprise consumption plan.
Read the storyA team maintaining a Claude Code or Codex skill library should run `skillevaluator tier3 evaluate` against each skill before publishing it, the way NVIDIA did with jetson-optimize-memory and cuopt-install — that single Tier 3 comparison is what surfaced cuopt-install's token increase instead of shipping it unnoticed.
Read the storyTeams self-hosting an MCP server for Claude, Cursor, or similar tools should verify OAuth is actually enforced before exposing the port.
Read the storyTeams weighing a self-hosted model for coding or agent workloads can now test Qwen 3.8 27B before defaulting to a trillion-parameter API.
Read the story
Questions this issue answers
- If explicit prompt caching isn't wired into a provider's client library, whose job is it to catch that before it shows up on an invoice: the model provider, the cloud host, or the tool builder?
- Until OpenAI or AWS ships explicit cache-control support for Codex's native Bedrock path, teams on GPT-5.6 Sol should assume their stable prompt prefix is being billed at full write price every turn, not cached.
- If Anthropic keeps extending a 'limited-time' promotion every few months, is it still a promotion — or has 1.5x weekly capacity become the real price of a Claude Code subscription that the marketing hasn't caught up to yet?
- Treat this as temporary and calendar it: the increase reverts automatically after August 31, 2026, with no announced plan yet to make the higher weekly ceiling permanent, according to Support.
- If skill marketplaces start ranking listings by Skill Lift score, who should be trusted to write the evaluation tasks — the skill's own author, the platform, or an independent third party?
- "Verified" currently means safety-checked and non-duplicative, not performance-guaranteed — treat every skill's Tier 3 score as the real gate, not the badge.
Editor’s note
Editor’s note
This edition synthesizes reporting from a GitHub issue tracker, Anthropic's support documentation, and NVIDIA's own published benchmark data, alongside our editorial analysis. We did not conduct independent testing of these claims; where a figure is vendor-reported or self-reported, we've tried to flag that rather than launder it into settled fact.
What to remember this week
- Codex CLI on Bedrock rewrites its full instruction prefix on nearly every turn, so a fixed cost becomes a recurring one — one session logged 6.7 million cache-write tokens and zero cache hits, according to a GitHub issue report.
- Anthropic has extended Claude Code's 50% weekly usage boost for at least the second time, now running through August 31, 2026 per its own support documentation, with no stated plan to make it permanent.
- NVIDIA open-sourced SkillEvaluator to score agent skills objectively, but its own catalog shows results ranging from a 77% token-use reduction to a 120% token-use increase — 'verified' isn't yet the same as 'performs well.'
- Qwen 3.8 27B matched GPT-5.6 Luna on Artificial Analysis's Intelligence Index this week, narrowing the gap between a small open model and the largest frontier systems to a single point.
The next issue arrives Monday
Subscribe for the full week in context, without the information overload.
