Workflow · last verified 2026-10-19

Your AI stack changed this week: triage it before it ships

The job this workflow does

The decision it improves is a weekly one: which of this week's vendor changes need a change in my code, my copy, or nothing, and how wide is the blast radius? Reading a changelog is not that decision. A changelog tells you what the vendor did. It does not tell you which of your files restate it, which of those compute money, or whether the page you would trust to confirm it has been updated yet.

Most teams do this ad hoc: someone sees a post, fixes the sentence they remember, and the other forty sites keep the old fact. Four of the five cases below are not a changed number in a file anyone was watching. The first changed a number in one file and left the same fact in forty-five more lines.

What you need before the first sweep

• Three URLs per vendor you depend on: the pricing page, the lifecycle or deprecations table, and the changelog or release notes. Docs pages come later; they are the slowest of the four.
• A fact register. A list of where each vendor fact lives in your tree. At minimum: the table your code computes money from, and the phrases your copy uses to restate rates, defaults and ids. If the register is "whatever I remember", step 4 will find what you remember.
• A weekly slot with an owner. A sweep nobody is assigned to read is a scheduled job with no consumer. Keeping that job alive and its output processed is the subject of scheduled AI agents and is not repeated here; not losing its drafts once it runs is consume then commit.

Which source settles which question

Vendors publish the same change in up to four places, at different speeds and with different omissions. Decide by the question you are asking, not by which tab is open. Every page below was fetched on 2026-10-19 and returned HTTP 200.

When two first-party sources disagree, apply this order. Prefer the record that is dated and names the version or condition over the page that describes behaviour in general. If one is newer and more specific, cite it and do not quote the other until it changes. Write the disagreement down with the date you saw it. Re-read the loser at the next sweep. The limit: a changelog is also the vendor's claim. When the behaviour carries risk, such as what a permission mode starts in, run it before you publish an assertion about it.

Five cases from 7 to 19 October 2026

Each case names its class, what the sources said, what the sweep found in our tree and what changed in the practice. The first two come from our own cost and copy; the third is a Gemini id we pin through a third party; the fourth is a docs-versus-changelog conflict; the fifth is a watch whose premise expired before its trigger fired. The tree is the aiArch repo, so every "we" is checkable against the dates given.

1. The cache rate that moved under a verification stamp (money)

What the vendor said. On 7 October 2026 Anthropic's release notes announced that reading a cached prompt on Claude Sonnet 5.5 would cost $0.10 per million tokens, down from $0.20. They describe it as 0.05 times the base input price, where it had been 0.1 times. The pricing page agrees. Its cache-read row now lists 0.05x for Opus 5.5 and Sonnet 5.5, and the paragraph beneath it states the general 10% rule first and the exceptions after.

What the sweep found. src/lib/cost.ts priced Sonnet 5.5 with no cacheReadMultiplier, so it fell through to the file-wide default of 0.1 (cost.ts:21, applied at :129). A comment beside the entry said the rate was "verified on the vendor pricing page 2026-10-03". That was true on 3 October and false from 7 October. Our weekly sweep first recorded it on 19 October, twelve days after the vendor note. It failed safe: it over-counted cache spend in the spend caps and the member cost display, so a cap would trip early, not late.

The same fact was restated elsewhere. Searching the tree at the commit before the fix returned 45 lines in 15 files: public pages, a cost widget, and lesson and item JSON. The search could not find cost.ts, because that file was wrong by omission. It also could not find sentences that applied the old rate to Sonnet 5.5 without naming Opus 5.5: answer explanations in one cost-modelling quiz file did exactly that, and the search never listed them.

The second ring. After the code fix landed, the copy pass wrote on two pages that our code still billed Sonnet 5.5 cache reads at the old rate. That was true before the code fix and false in the commit that carried it, and the release gate's copy review caught both before deploy. A statement about your own system is a restatement of the vendor fact too. A regenerated syndication package for a post that is already live on another site was a third: you can list a copy you cannot edit.

The practice. A verification stamp records when a fact was true, never that it still is. Put the number in one place, derive the rest from it, and sweep the stamp itself.

2. A new model that broke three assumptions without breaking a number (money and behaviour)

What the vendor said. On 7 October Anthropic launched Claude Haiku 5.5 (claude-haiku-5-5). The release note says outright that code written for Haiku 4.5 "can break", and it lists requests that can now return a 400, among them a manual thinking budget, the sampling parameters temperature, top_p and top_k, and assistant prefill. The migration guide narrows the sampling rule: temperature must be 1 and top_p 0.99 if sent at all, a request may not carry both, and any top_k fails. It also says the same text becomes about 30% more tokens than on Haiku 4.5. The pricing page lists $0.10 input and $0.50 output per million tokens for prompts up to 100,000 tokens. Once a request's prompt passes that line, the whole request bills at higher rates.

What the sweep found. On 12 October our sweep searched for the id and found it nowhere in content/, docs/, public/ or src/. Nothing was wrong. But catalogue pages stated the lineup as closed: "The eight canonical ids above are what to pass and to cite" (public/claude-model-selection.html, now "nine"). A closed-world sentence goes stale the day the catalogue grows, and no number in it changes.

What the sort decided. Three actions, in this order:

• Money. cost.ts:49 prices Haiku 5.5 at the base tier, with a comment that costOf() has no prompt-length tier and would undercount about five times above 100,000 tokens. That is safe only while no role uses the model, and the comment says to add the tier before one does. The public price table shows the step as a footnote (src/lib/pricing/seed.ts:73) after a pre-release review noticed the row would otherwise show the base price with no word of the step.
• Behaviour. modelFor('hint') still returns Haiku 4.5 (src/lib/llm.ts:43). Moving a role onto a new model is a behaviour change that belongs behind an eval gate, which is the argument of pinning a model is not pinning its behaviour. It is not a docs edit.
• Copy. The catalogue sentences, last, once the first two were settled.

The practice. Ask what the shape of each fact assumes. A flat price per token was the assumption; the 100,000-token step broke it without changing the headline rate. An additive change is not "nothing to do" just because nothing you said is false.

3. A deprecated model id that kept answering (contract)

What the vendor said. Google's Gemini API release notes for 8 October 2026 deprecate gemini-3.7-flash and gemini-3.5-flash. "API requests to gemini-3.7-flash are automatically routed to gemini-3.8-flash", and the 3.5 id likewise routes to gemini-3.6-flash. Google's deprecations table gives both rows no shutdown date and says the endpoint "is not shutting down and automatically routes API requests". The same release-notes entry also shuts down an agent, deep-research-pro-preview-12-2025, on 23 October. One entry, two different contract shapes: a hard date, and a silent substitution. The table's own note says its dates are the earliest possible retirement.

Why a calendar misses it. A date-driven watch asks "when does it stop?". For the Flash ids the answer is "it does not", and the id in your config still resolves. What changed is the model behind it. This is the case where a pin is a preference and the vendor holds the other end.

What the sweep found. Searching src/, public/, content/ and scripts/ for the two ids found exactly one use, and it is a pin:gemini-3.5-flash in the share-of-model tracker (scripts/seo/citation-tracker.mjs:41). Its own comments say pins are deliberate, because a series is only comparable if the model is held constant, and that a missing pin "fails loudly rather than silently substituting" (:32-33). A reroute is the substitution that comment refuses. But the tracker reaches Gemini through a third-party API (see LLM observability for that layer), so whether Google's reroute reaches it depends on what that layer sends. We have not checked, because checking spends money. Outcome as of 19 October: no edit, and an open question. Until someone checks, the next run's Gemini column cannot be assumed to measure the pinned model.

The practice. The contract class has two questions: when does it stop, and what does this id resolve to today. Log the model version a response reports, not the one you requested, so a substitution shows up in your own data. For why a pinned id fixes less than it appears to, see the pin pattern.

4. The docs lagged the changelog (behaviour, and a source conflict)

What the vendor said. The Claude Code changelog entry for 2.1.285 (29 September 2026) said a headless claude -p run, or a Python Agent SDK session, with no permission mode set would begin in auto if it used a third-party provider or had telemetry off. The entry for 2.1.302 (16 October) reversed that. On a fresh install, on a third-party provider, or with telemetry off, a session with no mode set now begins in default, and passing --permission-mode auto keeps auto. Three days later the permission-modes page still said such sessions start in "auto with Claude Code v2.1.285 or later".

What the sweep found. Two of our pages taught the 2.1.285 behaviour as current: the Claude Code workflow and the agent-harness guide. The ticket that flagged them named the wrong line for the second (line 83; the claim was on line 103). A ticket is a claim; search the page for the sentence, do not trust the number. Both pages now cite the changelog, and the harness guide's source note records that the docs page still describes 2.1.285. The pages rest on the changelog entry, not on a test run of the new default.

The practice. This is the conflict rule in use: the later, more specific, dated record wins; the lagging table is not quoted; the disagreement is written on the page with the date seen; the loser is re-read at the next sweep. Also re-read the changelog from the version you last verified forward. A rule added in one release can be reversed in a later one, and a page stamped with the first never sees the second.

5. The watch whose premise expired before its trigger fired (contract)

What happened. We hold a standing watch on the retirement of Claude Haiku 4.5. It has a trigger, a retirement notice, and a premise, that no successor existed to migrate the cheap, high-volume role to. Haiku 5.5 launched on 7 October and falsified the premise without firing the trigger. Anthropic's lifecycle table on 19 October still lists Haiku 4.5 as Active with no deprecation, and a tentative retirement of "Not sooner than October 15, 2026". That floor has now passed. Anthropic commits to "at least 60 days' notice" for publicly released models, so a notice can land any day and the earliest stop follows at least 60 days later.

The practice. Write every watch as trigger plus premise, each with the date you last checked it, and update the premise when a sweep contradicts it rather than waiting for the trigger. For a change that does carry a date, calendar the notice window beside the date. On the same table, Anthropic notified developers on 30 September that claude-sonnet-4-5-20250929 retires on 30 November 2026, a 61-day window, with claude-sonnet-5-5 as the replacement.

The workflow

1. Collect the week's changes, one line each

Read the three feeds for each vendor, newest first, back to your last sweep. Write each change as one line: date, vendor, what changed, URL. Do not interpret yet. For an aggregator you route through, read its catalogue only to confirm a price or slug you already have from the vendor.

2. Sort each change into a class

One change can carry more than one class; take the strictest action. A sort that ends in "nothing" is a valid result, as long as step 4 supports it.

3. Settle any conflict between sources

Use the order in the sources section. Record the disagreement, the dates and the source you chose, in the place a reader of the affected page will see it.

4. Sweep the blast radius before you edit anything

Search for the fact in four rings: the vendor's phrase, your statements about your own system, numbers derived from it, and copies outside the tree. Run the same search at the revision before the fix to measure the job, then again afterwards.

# every site that restates the fact: the wide net, now and at the revision before the fix
grep -rnE "0\.05.{0,40}Opus 5\.5" public content src
git grep -nE "0\.05.{0,40}Opus 5\.5" <rev> -- public content

Treat the result as a list of sites, not defects. The same search returned 45 lines before the fix and 49 after (50 once this page was in the tree, since case 1 above restates the rate), because the corrected sentences still name Opus 5.5 alongside Sonnet 5.5. A filter that drops lines mentioning the new fact is a convenience, not a gate: at the pre-fix commit it kept 38 of the 45 lines and dropped seven, and at least two of those seven (both in public/claude-agent-cost.html) named Sonnet 5.5 while still stating the old rate. grep exits 0 when it finds a match, 1 when it finds none and 2 on an error, so "none" is the clean answer only when the fact you searched for is now entirely false. Where it is still partly true, finish by reading each site.

Do not blind-replace. Some sites carry adjacent arithmetic or chart alt-text that needs its own re-read, and in our case a lesson's recomputed bill changed along with the multiplier.

5. Fix in order, in one change, and re-sweep

Money path, then behaviour gate, then contract calendar, then copy. Land the code and the copy together so the meter and the page agree. Re-run step 4 and read the delta. Check the copies you cannot edit and hand them to whoever can.

6. Record the result, including nothing and open items

For each change, one row: class, deciding source with date, sites found, sites changed, open items. Stamp what you verified with the date and what would falsify it (case 1). Write "checked these sources, nothing needed" when that is the answer. It makes a quiet week and a missed sweep look different.

7. Re-read the losers and the open items next week

A docs page that lagged is due a re-read. A watch premise is due a re-check. A floor date that has passed is a flag, not a closure.

Failure modes

• Reading a stamp as a guarantee. "Verified on 3 October" was accurate for four days (case 1).
• Sweeping the vendor's phrase only. Your statements about your own code and any derived figure restate the fact too (case 1).
• Treating the count as the defect count. A sweep for a fact that is still partly true never reaches zero (step 4).
• A silent default or fallback. An entry with no multiplier takes the file default (cost.ts:21), and an unknown model id is priced as claude-sonnet-5 (cost.ts:91, applied at :117). A comment in the same file records that Fable 5.1 was absent from the table until 12 September, so a turn on it would have billed at one fifth of its real rate. It was never routed, so nothing was mispriced. An additive change then becomes a wrong number with no error.
• Closed-world sentences. "These are the ids" goes stale when the catalogue grows, and nothing in it is false (case 2).
• Resolving a conflict silently. Pick a source without writing down why, and the next reader re-litigates it or trusts the lagging one (case 4).
• Deprecated read as stopped. A date-only watch cannot see an id that still answers as a different model (case 3).
• A watch that only waits for its trigger. The premise can expire first (case 5).
• Copies you cannot reach. A syndicated or cached copy needs its own owner (case 1).

Trade-offs

• A weekly sweep is late by design. Our sweep recorded the Haiku 5.5 launch five days after it and the cache rate twelve days after. A vendor can change something on a Tuesday that costs money before the next sweep. If a rate you pay moves daily, pull the pricing page on a shorter clock for that vendor only.
• The register is a standing cost. It only stays current if the sweep updates it. A stale register finds stale sites with confidence.
• Over-triage. Every wording change in a vendor's docs is not a ticket. The docs-only class exists so those get a line and no work.
• Waiting for the docs to catch up is also a decision. It is cheap when the claim is reversible and expensive when copy is already published on a wrong fact. Cite the newer source and say what you did.

Verification

You know it works when a change from last week can be replayed. Take one, run the step 4 search at the revision before its fix, and get the site list the original sweep produced. Then check three things: every row in the record names a class and a deciding source with a date, every "nothing needed" row has a search behind it, and no source disagreement exists only in someone's memory.

The honest state of our own run: the practice caught a money bug that failed safe, a closed catalogue that was not wrong, and a lagging docs page. It also showed where it is weak. The sweep's site list named one of the two pages that later misdescribed our code and missed the other, and the release gate caught both. The Gemini pin behind a third party is still unchecked (case 3). Two weeks is a small sample, and none of this is a measure of how many changes the sweep missed.

When not to use this workflow

Skip the register and the weekly sweep if you have one pinned model, no public copy that restates vendor facts, and spend you read in the vendor's own dashboard. Read the vendor's changelog email, change the one id and move on. The practice earns its cost when a vendor fact is restated in more than a handful of places, or when one of those places computes money.

Skip the four-way sort for a security fix you have to apply today; patch first and write the record after. Skip the careful source ranking when the vendor offers a machine-readable diff of its own prices and ids that you already consume; use that and keep the step 4 sweep for your copy.

Changelog

• 2026-10-19 — Initial version. The vendor facts were read from the pages cited below on 2026-10-19. The five cases are verified against the repo at the dates given: the pre-fix commit for the sweep counts, the current tree for the line references, and the ledger and sweep records for the dates.