New model alerts (the app notices a new model for you)

What it is

What it is

AI providers ship new models all the time, and Omniscio's model picker is a hand-curated list — so a newly-released model doesn't show up until someone notices and adds it. The new-model watcher removes that chore: Omniscio checks each provider you've configured, in the background, and tells you — automatically — when a provider is offering a model Omniscio doesn't list yet. You never have to watch a changelog or a pricing page yourself.

It is on by default. Turn it off at Settings → Notifications → New model alerts (newModelWatcherEnabled).

Where to find it

An inbox card — "New (Provider) model" — with a one-click Add it for me button as its action. The watcher's own switches are in Settings → Notifications → New model alerts.

How it behaves

What you see

When a genuinely-new model appears:

1. One inbox card — "New (Provider) model: (model id)", telling you a provider is now offering a model Omniscio doesn't list yet.
2. One desktop notification — fired when the card is first created.
3. A one-click "Add it for me" — the card's Start session button launches a session pre-instructed to add the model properly: look up its official pricing (and flag it for confirmation rather than guess if it can't find it), add it to the model picker with a friendly label, add its pricing row, update the tests — and leave the work on a branch for you to review. It never pushes or merges on its own. You can also just dismiss the card.

Each model alerts once, ever — dismiss it and it won't nag, even across restarts.

Two limits keep this from ever becoming a flood:

• Aggregators don't raise cards at all. OpenRouter fronts ~58 labs and lists 430 models, so one card per model is the wrong unit entirely — its models feed the model picker instead (see below). Single labs like Claude or Gemini ship two or three models a year, which is exactly where a card each is useful.
• At most 10 cards per check, across every provider combined. If a provider's list suddenly widens by hundreds, that is a change in the list, not news you need 200 times. The overflow is dropped and the event is logged.

Which providers it watches

• Watched (a real model-list API Omniscio can poll): Claude, DeepSeek, GLM, MiniMax, Meta, OpenAI, Gemini, Kimi, Qwen, OpenRouter. It only checks the ones you've actually configured a key for — no key, silently skipped.
• Not available (no model-list endpoint, or you pick the model per-session): Antigravity, Hermes, Terminal, OpenClaw, OpenCode, Pi. The settings description says this out loud so coverage is never a mystery.
• OpenRouter is watched but never alerts. It's an aggregator, not a lab: one endpoint fronting 430 models from ~58 vendors, adding roughly six a week. Instead of cards, its catalog keeps your OpenRouter model list up to date — see Which OpenRouter models you see below. Omniscio still keeps only first-party frontier labs (Claude, GPT, Gemini, Qwen, DeepSeek, Kimi, GLM, MiniMax, Llama, Grok, Mistral) and knows that OpenRouter's qwen/qwen3.8-max is the same model as the plain qwen3.8-max it already offers.
• Fast-follow — Cursor, whose only model-list source is a cursor-agent --list-models CLI call rather than a web endpoint.
• Coverage keeps itself current. Every Anthropic-compatible vendor that publishes a model-list URL is watched automatically the day it's added, so a newly-supported provider can't quietly ship with no coverage. Leaving one out takes a deliberate entry with a written reason, and a test fails if a vendor goes dark without one.

How it decides something is "new"

The key idea: "new" means new since Omniscio started watching, not "absent from Omniscio's curated list." Omniscio deliberately lists only a chosen subset of each provider's models, so a plain "endpoint minus our list" comparison would flag dozens of old models the first time it ran.

Instead, the very first time it polls a provider it records what's there as a baseline — silently for the old models (so it doesn't dump dozens on you at once). It does still surface the current-generation models Omniscio doesn't list yet, judged by each model's own release date: a model released within about two months of the provider's newest is surfaced, while older ones stay quiet. A provider that publishes no release dates stays fully silent on that first poll. From then on it alerts on models that appear later and that Omniscio doesn't already offer in any of its pickers.

Each provider also gets a small noise filter so a busy endpoint can't cry wolf: OpenAI's ~80-entry list is narrowed to real chat models (no embeddings/audio/image), Kimi's 400+ list to its one working family, Gemini drops experimental/tuning entries, Claude ignores re-dated snapshots of models you already have, and OpenRouter is cut to first-party frontier labs. Model ids from a provider are sanitized (length + character checks) before they can ever reach an alert.

Which OpenRouter models you see

OpenRouter gives you access to every model it carries — you are never limited to a list Omniscio ships. What the list controls is simply which models appear in the picker by default, so you aren't scrolling 430 rows.

That default list now keeps itself current. Omniscio already downloads OpenRouter's catalog daily, so it picks the defaults from it on three rules: the model can call tools (agent work needs that), it comes from a first-party frontier lab, and it's current-generation. Newest first, about a dozen shown. Nobody has to remember to refresh a hand-written list.

To choose your own: Settings → Accounts → Custom Providers → the models button on the OpenRouter row. One model id per line. Once you save your own list, the automatic refresh stops touching it — your choice can't be undone by a nightly update. Use automatic again hands it back, and clearing the box does the same.

Two deliberate safety behaviours:

• The list can never end up empty. If the catalog can't be reached or nothing matches the rules, Omniscio falls back to the list it ships with, because an empty picker would leave you unable to start a session at all.
• Turning off new model alerts doesn't freeze your model list. That setting controls alerts. With it off, Omniscio still refreshes the OpenRouter catalog in the background and simply raises nothing.

FAQ

Does it cost anything? No. Listing a provider's models is a free metadata call — no AI tokens, no account usage. The only paid action is the session you launch by clicking "Add it for me".

Why didn't I get any alerts at first? The first poll of a provider mostly just learns a baseline — it stays silent on the old models it finds. It will, though, surface any current-generation model Omniscio doesn't list yet (judged by the model's release date), and after that first poll it alerts on anything genuinely new.

Why isn't provider X covered? Either it has no model-list endpoint Omniscio can poll, or you pick its model per-session so there's no fixed list to watch (Antigravity, Hermes, Terminal, OpenClaw, OpenCode, Pi). Cursor is a planned fast-follow.

Will it spam me when a provider ships a new embedding or audio model? No — each provider has a filter that keeps only real chat models, so non-chat releases are ignored.

Why don't I get cards for new OpenRouter models any more? By design. OpenRouter carries 430 models and adds about six a week, so a card each buried the inbox — 215 cards, 198 of them inside one minute, before this changed. Its new models now flow into your OpenRouter model list instead, where you'll simply find them next time you pick a model.

Can I still use an OpenRouter model that isn't in the list? Yes. The list is only what the picker shows by default — any OpenRouter model id works. Add it in Settings → Accounts → Custom Providers → the models button on the OpenRouter row.

I edited my model list. Will Omniscio overwrite it? No. Saving your own list stops the automatic refresh for good. Use Use automatic again (or clear the box) if you want Omniscio to keep it current for you.

For agents

Under the hood (for agents with repo access)

• Service: src/main/services/model-discovery/model-watcher-service.ts — a registered daily tick (first run +90s), stopped in gracefulShutdown alongside the sibling monitors. Pure, injectable orchestration in model-watcher-core.ts (unit-tested with no network).
• Per-provider adapters + endpoints: model-discovery-adapters.ts (credential-bound, data-driven — no providerId === 'x' branching); the pure spec table (coverage + which filter) is model-discovery-adapter-specs.ts, which DERIVES the compat half from ANTHROPIC_COMPAT_PROVIDER_IDS gated on a published modelsListUrl, minus a reasoned UNWATCHED_COMPAT_PROVIDERS map.
• Noise filters + id sanitization + per-model created/created_at timestamp extraction (for the first-poll surface): model-discovery-filters.ts. Set logic in model-discovery-diff.ts: "new since baseline" (computeNewModelIds) plus the first-poll "surface current-generation, not-offered" (computeSeedSurfaceIds — a self-calibrated ~60-day window off the newest listed model; empty timestamps ⇒ fully silent).
• Aggregators + the alert budget. ProviderAdapter.isAggregator (from AGGREGATOR_PROVIDER_IDS, data-driven) marks a vendor fronting many labs: it records its baseline and feeds the picker but raises nothing. MAX_ALERTS_PER_TICK (10) caps a tick across ALL providers and logs when it trims (metric=model_alert_budget_hit). computeNewModelIds is a plain set difference with no recency or volume bound, so without that cap any widening of a seeded provider's list becomes one card per model — which is how 198 cards landed in one minute on 2026-09-03.
• The OpenRouter vendor test resolves the REAL vendor — the segment before the slug (openRouterVendorOf), never the first. A first-segment check reads anthropic/tencent/hy-mt2-7b as anthropic and lets it through. The vendor allow-list + parser + picker derivation live once in src/shared/providers/openrouter-model-picks.ts.
• Picker derivation: extractCatalogEntries keeps id + release date + tool support from the payload already fetched; deriveOpenRouterPickModels applies the three rules and falls back to the shipped snapshot rather than returning an empty list. Persisted as openrouterPresetModels, with openrouterPresetModelsCustomized marking a user-pinned list the refresh must not overwrite; substituted into the preset by effectiveCustomProviders(userProviders, { openrouterModels }).
• "Already offered?" is a cross-picker check (isOfferedByAnyProvider in provider-models.ts), NOT provider-scoped: the watcher polls vendor ids (e.g. openai) that have no picker of their own — their models live under the codex / gpt pickers — so a provider-scoped check would fail open and suppress every alert for that vendor.
• Baseline store: model-seen-store.ts — an atomic JSON file model-watcher-seen.json in userData (a MISSING or corrupt file reads as first-run, so it reseeds rather than storms). Deliberately not a DB table.
• Alert: the standard inbox alert primitive with dedupKey new-model:<provider>:<id> (model-watcher-alert.ts); the "Add it for me" prompt is the alert's session-prompt preset.
• Credentials stay main-only, never logged, never in a URL (Gemini uses the x-goog-api-key header, not ?key=).
• Gates: newModelWatcherEnabled (default on, re-read each tick), inert under AMC_INSTANCE_ID (e2e/sandbox), kill switch AMC_DISABLE_NEW_MODEL_WATCHER=1.
• Contract with test-locked invariants: .claude/memory/contracts/model-discovery-contract.md.

Related

• provider-status-alerts.md — the sibling watcher that tells you when a provider is down rather than when it ships something new.
• ai-providers.md — the providers and models this watcher is about.
• per-model-thinking-level.md — what you may want to set once a new model is added.