AI Guides › Playbooks
By Nigel Guy · 8 min read
When Anthropic says it is designing its own chips for Claude, builders either ignore it as a hardware story or over-read it and start rethinking vendors on the strength of a job advert. Neither changes anything you ship. The useful reading: the models under your product will keep changing, and the question is whether your setup can take a change without a fire drill.
The rule: treat hardware news as a reminder that the model you call is temporary, and keep your build in a state where swapping it is a config change plus a test run, not a rewrite.
| Claim | Status at time of writing |
|---|---|
| Anthropic is building an in-house team to design custom chips for Claude | Confirmed by Anthropic to TechCrunch, 5 August 2026 |
| Stated aim: co-design hardware and models so Claude runs faster and more efficiently | Confirmed, as reported by TechCrunch and others |
| Anthropic called it the latest step in a "multi-chip approach", with partner chips remaining central | Widely reported from Anthropic's statement; Anthropic's own news pages describe training and running Claude on AWS Trainium, Google TPUs and NVIDIA GPUs |
| Job listings for silicon engineering and a silicon programme manager describe work from architecture through tapeout to production | Reported from Anthropic's careers listings |
| A ship date for an Anthropic chip | None given |
| Samsung as a manufacturing partner | Reported by The Information, not confirmed by Anthropic |
Anthropic also keeps buying outside capacity: a Google and Broadcom TPU deal announced in April 2026 for capacity from 2027, and a SpaceX compute deal in May 2026 that came with higher Claude Code rate limits. Its own chip is one more source, not a replacement.
The usual reasons are cost, fit and dependence. At very large scale, small efficiency gains per request add up. A chip designed alongside the model can be shaped around what that model does, which is what Anthropic means by co-design. And owning some hardware reduces dependence on suppliers whose prices and allocation you don't control. Google (TPUs) and Amazon (Trainium) went down this road years ago; Anthropic already runs on both.
For you, the effect is indirect. Chip programmes take years to reach production, and none of this changes the model you call today. Over time, more capacity shows up as new models, limits and prices, and older models get retired to make room. That last part reaches your code.
Five lines, each with a pass condition. Fill it in once a quarter, or whenever compute news makes you twitch.
| Line | Question | Pass condition |
|---|---|---|
| 1. Model ID location | Where does your model name live? | One config value or environment variable, not scattered through your code |
| 2. Retirement watch | When can your current model be retired? | You've checked Anthropic's Model deprecations page and know the date, and the email address on your Console account is one someone reads |
| 3. Test set | Can you tell if a new model is worse for your job? | 20 or so real inputs with a note of what a good answer looks like, saved somewhere you can rerun them |
| 4. Usage map | Do you know which keys call which models? | You've exported your usage CSV and every model in it is one you meant to use |
| 5. Second route | If your main route hits limits or an outage, what happens? | A written fallback: another Claude model, Claude on another cloud, or a manual process. Even "we wait" counts, as long as it's a decision |
Line 1. Search your codebase, automations and no-code tools for strings starting claude-. Every hit outside your config file is a place a retirement will break something. Move them into one setting.
Line 2. Anthropic's deprecations page lists each model as Active, Legacy, Deprecated or Retired, with a tentative retirement date, and says customers with active deployments get at least 60 days' notice for publicly released models. Requests to a retired model fail. One catch: those dates apply to Anthropic-run platforms (the Claude API, Claude Platform on AWS and Microsoft Foundry). Amazon Bedrock and Google Cloud set their own schedules, so check their model tables if that's how you reach Claude.
Line 3. Use real past work, not invented examples. You're checking for regressions on your task, not ranking models.
Line 4. In Claude Console, go to Usage, click Export, and read the CSV. It breaks usage down by API key and model, which is the quickest way to find an old script still calling something you forgot about.
Line 5. Anthropic says Claude is available on AWS (Bedrock), Google Cloud (Vertex AI) and Microsoft Azure (Foundry). A second route is a real option, but model availability, dates and pricing differ by platform, so verify before you rely on it.
Use this with Claude, pasting in whatever describes your setup. Fill in the four bracketed inputs.
You are a careful technical reviewer helping a small business check whether its Claude-based tool can survive a model change without breaking.
Context:
- What the tool does: [ONE_PARAGRAPH_DESCRIPTION]
- Where and how it calls Claude (paste config, code snippets, or describe the no-code steps): [INTEGRATION_DETAILS]
- Model IDs we believe we use: [MODEL_IDS]
- How we reach Claude (Claude API, Bedrock, Vertex AI, Foundry, or a third-party app): [ACCESS_ROUTE]
Goal: produce a filled-in Swap-Readiness Card with five lines: model ID location, retirement watch, test set, usage map, second route.
Steps:
1. List every place a model ID appears in what I pasted, and say whether it is centralised.
2. For each model ID, tell me to confirm its status and retirement date on the current Anthropic deprecations page, or on my cloud provider's model table if I use Bedrock or Vertex AI. Do not state a date from memory.
3. Propose a test set of 15 to 25 inputs drawn from the task I described, with one line each on what a good output must contain.
4. Name the single riskiest gap and the smallest change that closes it.
Output: a five-row table (Line, Current state, Pass or Fail, Next action), then the test-set list, then the riskiest gap in two sentences.
Constraints: do not recommend switching vendors or rewriting the tool unless something I pasted shows it is necessary. If any input is missing or unclear, ask me for it before answering rather than guessing.
Before you answer, check: have you invented any retirement date, price or limit? If so, remove it and replace it with an instruction to verify.
A two-person agency runs a client-reply drafting tool. It was built last year and calls claude-sonnet-4-5-20250929, hard-coded in two scripts and one Zapier step. They read the chip headline and wonder whether to move to another provider.
Running the card:
claude-sonnet-5-5. The notice email went to a former contractor's address. They update the Console contact.They rerun the 20 inputs on the replacement, fix two prompt quirks and switch the variable. The chip story changed nothing directly; it prompted them to find a retirement that would have broken them in eight weeks.
Reading a hiring announcement as a roadmap. There's no ship date, no price effect and no model change announced. Moving providers or redesigning around "Anthropic hardware" now is acting on a story that hasn't happened.