Case Studies on RadarModel.com

Stop a Deploy When an AI Model Your App Calls Is Retired

Sun, 18 Oct 2026 00:00:00 +0000

Picture a support app that calls gpt-4.1 for its answer drafts and o4-mini for tagging tickets. The model names sit in a config file and in a couple of prompts. Nobody on the team reads the provider’s deprecation page, and nobody should have to.

The cheapest place to notice a model going away is the deploy pipeline. It already runs on every change, it already fails loudly, and the people who can fix a model name are the ones watching it. So RadarModel AI goes there, as one more step before the deploy.

Watch OpenRouter for Price Rises and Retirements on the Models You Use

Sun, 18 Oct 2026 00:00:00 +0000

An agency builds chat features for a dozen clients and routes them all through OpenRouter. One client runs on Claude Sonnet, two on GPT-4o-mini because they’re cheap, a few on Gemini Flash for the long context. The agency quotes fixed monthly prices. A price change on any of those models comes straight out of its margin, and a retirement date means a client project to schedule.

OpenRouter publishes its whole model list with prices, limits and retirement dates, and it needs no key. That makes it the easiest list to watch. RadarModel AI reads it every hour from a small server the agency already has, and posts to the team’s Slack channel when one of the watched models changes.

Catch Hand Fixes on a Production Postgres Database With a Pinned Baseline

Sun, 18 Oct 2026 00:00:00 +0000

A shop runs its orders on Postgres. Migrations live in the repo and go out with each release. Then come the nights when they don’t: checkout is slow, someone adds an index on production by hand, someone else makes a column NOT NULL to stop bad rows, and the fixes work. Nobody writes them back into the migrations.

The default rolling baseline would report each of those changes once, in the next scan. That’s fine when someone reads every report. This team wanted more nagging than that. A hand fix should keep showing up until someone has decided about it, by writing the migration or by rolling the change back.

Compare Staging and Production MySQL Schemas Before a Release

Sun, 18 Oct 2026 00:00:00 +0000

Release day for a team on MySQL. The new code has been tested on staging for a week, and staging has had the release’s migrations for a week. The question before shipping is a plain one: what does staging have that production doesn’t, and what does production have that nobody put in staging?

Migration tools answer half of it, the half they applied. RadarModel Schema’s diff reads both databases as they are and lists every difference, whoever made it.