The AI Engineering Brief

Issue #011 — 2026-09-14

What changed in AI engineering, September 7 – 13, 2026. Curated for senior engineers going AI-native. Every item sourced.

1. Two vendors made prompt-cache accounting measurable in one week — and Claude Code logged twelve cache-behaviour entries in four days

A cache miss returns 200, so nobody notices one. Read the Claude Code changelog between September 8 and 11 and you find twelve entries about prompt-cache behaviour across 2.1.265, 2.1.267, 2.1.268 and 2.1.269: eleven fixes and one stability improvement (two more in 2.1.269 only change how VS Code displays the cache clock). The situations they touch are ordinary ones — switching models mid-session, tools appearing mid-session, connector tools that differ once a session is resumed, resuming after an interruption or an output-limit stop — though most applied only in specific setups. If your cost baseline came from one of those setups, it may have come from a cache that missed more than you thought.

The instruments arrived the same week. OpenAI made Prompt Cache Diagnostics generally available on September 8 — per-response miss explanations. Cloudflare's AI Gateway (September 9) now accepts per_cache_read_token and per_cache_write_token in the cf-aig-custom-cost header, and Cloudflare says the change "prevents double-counting" across providers' different cache-token reporting.

Why it matters: cache economics stopped being a rounding error when Fable 5.1 and Mythos 5.1 started reading cache at 0.025x input ($0.25 per MTok on Fable 5.1) against 0.1x for the rest of Anthropic's line. At that ratio your hit rate can move the bill more than your model choice. Upgrade past 2.1.269, re-measure, and do not trust a baseline taken from a resumed, model-switched or connector-changed session. If you route through AI Gateway on negotiated rates, set both cache fields. Cloudflare's docs are explicit about the default: "If you omit both cache rates, AI Gateway ignores cache-token counts and uses the existing input and output calculation." Setting just one is its own trap, because the missing rate is then priced at your input rate. And if you have never established where your cache boundary actually falls, that is the prerequisite, not the follow-up — our cache-aware prompt layout pattern exists because three vendors report the saving in three incompatible shapes and every way it breaks looks like success.

Source: developers.openai.com API changelog, Sep 8 entry · Cloudflare changelog — AI Gateway custom costs support cache tokens, 2026-09-09 · Claude Code changelog, 2.1.265 (Sep 8) through 2.1.269 (Sep 11).

2. OpenAI put the Codex harness behind an API — and Cloudflare shipped a self-hosted sandbox for it the same day

The orchestration most teams hand-build around an agent — durable sessions, context compaction, recovery — became something you can rent on September 10. OpenAI's Agents API (public beta) wraps the Codex harness: bring your own tools and MCP servers, and choose whether the sandbox is OpenAI's or yours. Cloudflare answered the "yours" half the same day with an open-source Workers template: one Container per Codex session, managed by a Worker.

The voice leg got a meter too. gpt-live-1 reached general availability the same day at $0.05 a minute, billed per second. The meter keeps running until your application closes the session, muted or not, and the model and tools behind the voice are a second bill.

Why it matters: build-versus-buy for the harness is now a real call, and two questions settle it before you prototype: whose sandbox executes your code, and what happens to your agent's state when you leave. Renting the harness while running the execution environment yourself is the shape that keeps the exit cheap, which is why the Cloudflare template is worth reading even if you never deploy it. On voice, the per-minute charge runs for as long as a session is open, before any model work, so model your concurrency and hang-up logic before your invoice does it for you.

Source: developers.openai.com API changelog, Sep 10 entries (Agents API, GPT-Live 1) · Cloudflare changelog — Use Cloudflare Containers with Codex via the OpenAI Agents API, 2026-09-10.

3. Anthropic added server-side tool approval for agents — and gave you a terminal to watch it from

In seven days the Anthropic agent platform picked up the three pieces most teams build by hand for a production agent fleet: declarative deploys, a policy engine, and an operator console. The first landed September 3 as ant apply (v1.30.0) — declarative, plan-then-apply, tracked in a committed claude-lock.json. September 10 added the other two. Claude Managed Agents gained an opt-in auto permission policy that hands the run/deny/pause call on each agent or MCP tool call to Anthropic's own server instead of your application code. For audit, the new evaluation field on most tool-call events says which policy decided it, and under auto why the server held or blocked it. The ant CLI's new ant beta:sessions connect puts a terminal — or, with --web, the Console's own session viewer — directly on a live session, so a human can watch it run and clear whatever is sitting in the approval queue.

Why it matters: in seven days the Anthropic agent platform acquired Terraform-shaped deploys, a server-side policy engine and an operator console. That is the vocabulary of an ops product, and it changes what you should be building: a bespoke per-tool approval layer in your application code is now duplicated infrastructure, and a per-agent config maintained by hand is drift waiting to happen. The evaluation field is the piece to wire first — a record of which policy decided each call is where the audit trail your security review will ask for starts. Keep one thing honest, though: auto is a server deciding what your agent may touch, which means your blast radius is now defined by someone else's evaluator plus whatever you scoped. Pair it with the approval boundary you control rather than replacing that boundary with it — the human-in-the-loop approval pattern is about which actions must stop for a person regardless of what any evaluator thinks.

Source: platform.claude.com release notes, September 10, 2026 (and September 3, 2026 for ant apply).

4. Claude Code's week in permissions: deny rules that did not apply, secrets printed to the terminal, and a regression the next day

Two Claude Code releases this week, 2.1.268 and 2.1.269, fix four permission-rule bugs. In three, a rule that was configured, that an operator would call enforced, silently did not apply; the fourth is the mirror image. Symlinks: typing the real target instead of the link could get past a deny or ask rule set on the link — system directories on macOS and Linux among them. Unparseable neighbours: with eval or env -C on the same command line, a Read or Edit deny rule could be switched off. Tool detours: tee was a way around both Edit() deny rules and the working-directory boundary. And the mirror image: a ! rule written in one settings layer could take effect in others. A second, unrelated cluster was about leakage rather than enforcement: plugin, marketplace and MCP-login errors, and the /mcp and /plugin detail screens, printed tokens, passwords and ${VAR}-resolved secrets straight to the terminal, and plugin files were exposed to other local users (2.1.268–2.1.269). Then a coda: 2.1.270 (September 12) fixed a regression the changelog attributes to 2.1.269, in which read-only git commands began asking for permission again once a session had been open for a while. The same week added claude plugin eval, which puts a plugin under a repeatable, scored test.

Why it matters: a rule that was configured, that an operator would have described as enforced, and that silently did something else is the failure mode to design against, and it is not Anthropic-specific. If your own agent harness matches permission rules against untrusted strings, each of these is a test case you can steal: real path versus symlink spelling, a Read/Edit deny rule sharing a line with eval, a write redirected through a tool rather than the file API, a negation rule crossing a config boundary. The Monday action is to stop reading your permission config and start testing it: every deny rule you depend on gets a test that proves it fires, run against the version you actually ship. A check that would have quietly never fired is a failure we nearly shipped ourselves, which is why the practice has a page: validating the validator.

Source: Claude Code changelog, 2.1.268 (Sep 10), 2.1.269 (Sep 11), 2.1.270 (Sep 12).

5. A Windows update stopped Claude Cowork running local commands — and the fix belongs to Microsoft

Since September 8, a desktop agent's ability to act on your machine has depended on a patch neither you nor its vendor controls. Anthropic's status page, September 10, 15:54 UTC: "A Windows update released September 8 has left Claude Cowork on Windows unable to run local commands, because its workspace can no longer reach your computer's drive." Chat and file editing kept working for most users; the fix is Microsoft's to ship, and at the end of this window the incident was still marked "Identified." Two smaller incidents landed the same week: elevated US Midwest API latency, identified 21:43 UTC and mitigated by 23:24 UTC on September 10, and elevated errors on Claude Mythos 5.1 and Fable 5.1 between 13:57 and 14:20 UTC on September 11.

Why it matters: two questions follow from that shape of dependency. First, does anything you have automated assume an agent can run commands locally, and does it fail loudly or silently when that assumption breaks? A scheduled job that quietly produces less because a tool vanished is worse than one that errors. Second, when you inventory the dependencies of your AI tooling, does that inventory include the operating system and its patch channel? For Cowork on Windows this week, that was the single point of failure, not the model. For incident windows, read the vendor's own feed: it states the September 11 window to the minute.

Source: status.claude.com incident history, entries dated 2026-09-10 and 2026-09-11 (Cowork on Windows · API latency · Mythos/Fable 5.1 errors).

6. OpenAI added key-lifetime caps and Cloudflare cut Workflow retention — both land on what you create next

September 10, 2026 brought two lifecycle changes, one per end of the stack, and both are stated for newly created things.

• OpenAI project API keys: an expiry you can set at creation, plus an org- or project-level maximum key lifetime that newly created keys must fit.
• Cloudflare Workflows on Workers Paid: new Workflows default to 7-day instance retention, down from 30. Existing Workflows: no change. Free plan: 3 days, as before. Per-instance override: successRetention, errorRetention.

Why it matters: both changes are stated for the thing you build next, so nothing visibly breaks today and nothing tells you a rule changed. The break arrives later: a key created under a newly set lifetime that expires mid-incident, or a debugging session in October that finds the failed run from three weeks ago was swept at day seven because its Workflow was created on or after the tenth. Decide the org-level key lifetime yourself this week rather than inheriting whatever an admin picks under audit pressure later, and find your longest-lived key first and give it an owner. If you run Workflows and debug from retained instance state, set errorRetention explicitly in code, so the value is a decision in your repository instead of a default in someone else's release note.

Source: developers.openai.com API changelog, Sep 10 entry · Cloudflare changelog — Default instance retention for new Workflows on Workers Paid is seven days, 2026-09-10.

The Brief is the filter, not the firehose — every item sourced, every one with a reason to care. Members go deeper in the curriculum; the sample lesson is open to everyone.