Status-aware model selection | WebmasterID Models

Two kinds of status signal

The catalogue records two different status signals for each provider, and keeps them strictly separate:

Vendor-reported status — what the provider's official status page says about its services right now. Sourced from the provider's published status surface.
Independent probe — an HTTP probe the catalogue runs against the provider's documented endpoint. Records observation timestamps and response shapes.

These two signals can disagree. The catalogue does not reconcile them — it shows both so the reader can decide which one is load-bearing for their workflow.

Status observations are not uptime percentages

Aggregate uptime metrics ("99.9%") require a measurement regime: sampling cadence, geographic coverage, success criteria, and a published methodology. The catalogue does not publish any of those, so it does not publish aggregate uptime. What it does publish is a stream of observations — what the probe saw, when, from where — and a link to the vendor's own status surface for context.

When status should gate a model decision

If the workload is latency-sensitive or revenue-critical: status observations are part of the evidence pack, not a footnote.
If the model is hosted on a third-party platform: read the host's status signal, not just the creator's.
If the provider had a recent incident: open both the vendor's status page and the independent probe history.
If status is observed but the vendor status page is silent: treat the discrepancy as a question, not a verdict.

Where to look in the catalogue

The /status page lists every observed provider with both signals side by side. The model record pages link to their provider's status surface. The machine-readable counterpart at /api/status/anthropic (and the other provider slugs) returns the same observations as JSON.

Common mistakes

Treating the vendor status page as ground truth.
Vendor status pages can lag actual incidents. The independent probe is the second opinion.
Reading an observation as an uptime claim.
Observations are timestamps + response shapes. They do not extrapolate to an SLA.
Skipping status because 'the model is verified'.
Verification is about field-level citations. It does not say the endpoint is currently serving traffic.
Treating creator status as host status.
For hosted models, the host's status surface is the load-bearing one — the creator's surface may be irrelevant.

Apply this workflow

Data gaps to watch

Some providers do not publish a machine-readable status surface, in which case the catalogue records only the independent probe. Treat that as a gap to monitor externally — not as a missing feature.

/status — observed status across tracked providers.
/research/ai-provider-status-monitoring — the long-form research piece on monitoring methodology.
/docs/status-observations — the data-model definition for status observations.
/learn/model-lifecycle — the partner lesson on lifecycle gating.

Sources and freshness

Status observations are the most volatile signal in the catalogue — they update on every probe run. The vendor status URLs carry their own citations and retrievedAt dates.

Teaching example

Illustrative — not a recommendation.

Situation: An incident on the provider's status surface says 'partially degraded' but the catalogue's independent probe records normal responses for the same window.

Decision to make: Which signal does the team treat as load-bearing for the integration decision, and what gets recorded?

Verified fields that matter:

Vendor-reported status (per provider status page)
Independent probe observations (per /api/status/<provider>)
Observation timestamps
Provider docs that define the status surface

What to inspect next:

Weak vs better approach

Weak approach

Treat the vendor status page as ground truth without checking the probe.
Read observations as an uptime percentage.
Skip the host's status signal when integrating a hosted model.
Reconcile vendor + probe signals silently in your notes.

Better approach

Keep vendor-reported status and independent probes as separate signals.
Treat observations as timestamps + response shapes, not SLAs.
For hosted models, read the host's status surface AND the creator's.
Record any disagreement between signals as an explicit data point.

Why better: Vendor status pages can lag actual incidents. Keeping signals separate makes the disagreement a data point your reviewer can investigate instead of a hidden assumption.

Example artifact

Illustrative example — not a recommendation. Substitute your own values when you run the workflow.

Status observation note

## Status observation (illustrative)
Window: <ISO start> to <ISO end>

Vendor-reported status (per provider page):
- <status> · message: <verbatim>

Independent probe (per /api/status/<provider>):
- Observations: <n> · response shapes: <summary>

Disagreement: <yes/no — describe>
Action: <continue / escalate to provider / surface in brief>

Substitute your real values when you walk the workflow. The catalogue never generates this artifact for you.

Concept → workflow bridge

Step 1
Learn the concept →
Separate vendor-reported status from the independent probe.
Step 2
Apply in /status →
Inspect both signals side by side per provider.
Step 3
Verify in /sources →
Trace the citation behind the vendor status surface.
Step 4
Test in /lab →
Schedule canary observations alongside model regression checks.

Review before moving on

Vendor status and independent probe signals are recorded separately.
Observations are NOT presented as an uptime percentage.
For hosted models, the host's status signal is included.
Any signal disagreement is a recorded data point.
Status is gated to the workloads where it actually matters.

Caution: No persistence — the checklist resets on every visit. Capture progress in your own notes.

What this lesson does not teach

Publishing uptime percentages — the catalogue records observations, not aggregate SLAs.
Ranking providers by reliability — the catalogue does not.
Replacing your own status monitoring or on-call alerting.