Keeping Up With AI Without Chasing It

Seven AI releases landed between 1 and 22 September 2026. Claude Fable 5.1, Gemini 3.8 Flash, GPT-6 Astra, GPT Image 2.5, Jev, Grok 4.7, and Claude Opus 5.5. Every one came with a benchmark chart showing it in front.

If you tried to keep up by reading the announcements, you would have finished the month knowing seven names and not one thing to do differently on Monday.

Across all seven, I changed one thing. Not because I was not paying attention, but because I was, and the rest did not earn a change.

Two things in that list were worth noticing, and neither was the pace. Opus 5.5 arrived costing about forty percent less to run than the model it replaced, rated by its own maker at or above their most expensive model, which is the third time this year the same capability got cheaper. And Jev is not a chatbot at all. It does not write text. You define the possible answers in advance, it reads a situation and returns one of them with a probability attached, and software acts on the result. A lot of what we currently pay a chatbot to do is a decision rather than a piece of writing, and that distinction is going to start showing up on invoices.

The useful skill is not tracking releases. It is having something that turns a release into a decision, including the decision to ignore it. Here are the two blocks I use. Both work in whatever AI tool you already have open.

Block one: the weekly check

Hand this one to AI. You are using AI to keep up with AI, which is the whole point: the machine reads the announcements so you do not have to, and reports only what touches the work you actually do.

You write the prompt once. It produces four statuses and nothing else:

That last row is the one people leave out, and it is the one that does the work. A release you have not explicitly skipped comes back every time someone mentions it. Writing down why you passed is what keeps the list quiet.

The prompt

Paste this into any assistant with web access. Fill the two bracketed sections once, then save the whole thing. Weekly is plenty. Monthly is fine.

Run it by hand for the first few weeks. You will not know what you want it to tell you until you have read a few of them. Once it is earning its place, put it on a schedule: ChatGPT runs recurring prompts inside the app and gives you three even on the free plan, and Claude does it through Cowork on the desktop app on paid plans.

Search for AI model releases from the major labs since [DATE OF YOUR LAST SCAN]. Prefer each lab's own announcement over coverage of it, and note the release date and the price where it is published.

My situation: [WHAT YOU USE TODAY, AND FOR WHAT. For example: ChatGPT for drafting and research, Gemini in my email and docs, and I pay for one seat. My work is mostly writing, analysis and client prep.]

For each release, do not summarise it. Give me one of four verdicts, with one sentence tied to my situation above:

• RUNNING, meaning I should switch to this now, and what I stop using
• TRIALLING, meaning it is worth one bounded test, and what specifically the test has to prove
• WAITING, meaning it is real but nothing in my situation calls for it yet, and what would change that
• SKIPPED, meaning it does not apply to me, and why, so I can stop reconsidering it

Then finish with a single line: what, if anything, I should actually change this week. If the honest answer is nothing, say nothing and do not pad it.

Two rules. If a price or a benchmark number is claimed but you cannot find it on a primary source, mark it unverified rather than repeating it. If your search comes back empty, tell me your search came back empty. That is a gap in the check, not a quiet month.

Those last two rules matter more than they look. The first time my own check came back with nothing, it was not because nothing shipped. It was because the sites it relied on were unreachable. An empty result that presents itself as good news is worse than no result at all.

If you use Claude Code

I run this as a saved skill rather than a pasted prompt, so it also updates a one-page board and keeps the history. If you work in Claude Code, the skill version is in the appendix at the bottom. If you do not, you are not missing anything important. The prompt above is the same thinking.

Block two: the twenty-minute comparison

The check tells you what is worth testing. This block is how you test it without it becoming a project.

Most tool debates run on vibes. Someone read a benchmark, someone else had a bad afternoon with it, and the loudest person wins. You can settle it properly in about twenty minutes, and the result is worth more than any chart because it is measured on your work.

The discipline is simple. Same task, same context, same day, judged on criteria you wrote down before you looked at the output.

The prompt

Run this once per tool you are comparing. Keep the bracketed parts identical across all of them, and paste the results into a single document at the end.

I am comparing AI tools on a real task from my own work. Do the task below exactly as specified. Do not ask me clarifying questions, and do not explain your approach. Produce only the finished output.

The task: [PASTE A REAL TASK YOU DID THIS MONTH. Not a puzzle and not a test. Something with your actual constraints in it.]

The context you should use: [PASTE THE SAME BACKGROUND YOU WOULD NORMALLY GIVE. The brief, the audience, the document, the examples of what good looks like.]

What finished looks like: [LENGTH, FORMAT, TONE, AND ANYTHING THAT WOULD MAKE IT UNUSABLE.]

Then score each result yourself, on a sheet you fill in before you start:

Two things to protect the result. Score the outputs without knowing which tool made which one, if you can manage it. And write the criteria down before you run anything, because a criterion invented after you have seen the output is just a reason for the answer you already had.

What a good test actually asks

The mistake is testing everything at once. A comparison is only useful when it has one question.

When I looked at Grok recently, the honest version of the question was not "is it good." It was narrower than that: the claim worth testing is cost on high-volume, low-judgment work, not quality on hard problems. So the test is one real batch of repetitive work, run on both, compared on cost per task and a fixed quality score. Until I run that, it stays off my recommendation list, and saying so is more useful than an opinion I have not earned.

Write your question down in that shape before you start. "Is it better" has no answer. "Is it cheaper than what I use today on the repetitive half of my week, at quality I would still send" has one, and you can have it by lunchtime.

What to do with the answer

Whichever way the comparison lands, save it. The result, the date, the task you used, and the criteria. Three months from now the next release will reopen the same question, and the only thing that will save you from re-litigating it is a note from the version of you who actually ran the test.

That is the whole practice. A check that is allowed to say nothing, a comparison narrow enough to finish, and a written record so neither one has to be repeated.

Appendix: the Claude Code skill

Save this as .claude/skills/model-radar/SKILL.md in any project. Run it with /model-radar.

---
name: model-radar
description: Weekly model-release scan filtered to my actual stack. Produces adopt/trial/wait/skip verdicts, not news. Run weekly or when you hear of a release.