Unmask Stealth Models

Build a source-backed shortlist of possible model publishers and serving providers. Track downtime, degradation, and recovery across the anonymous route, named comparison routes, gateway status reports, and upstream provider incidents. Report attribution as a hypothesis until an authoritative disclosure establishes the mapping.

This is a maintainer research skill in .agents/skills; do not load its hypotheses, outage ledger, or reports into product prompts, runtime skills, or candidate-visible eval memory.

Establish the observation window

Resolve the exact anonymous model ID and serving gateway from its current public catalog. Record first-seen date, catalog snapshot time, context/output limits, tool support, reasoning controls, price, and any documented upstream routing. Preserve aliases and retirement/replacement events; a stealth alias may change underlying models over time.

Use the requested period. If none is given, start with the last seven days of available history and state the actual coverage. Identify candidate publishers and inference hosts separately: the lab that trained a model need not operate the endpoint. Start with candidates supported by public routing metadata or release evidence, rather than assigning every incident to a popular lab.

Collect public evidence

Verify these entrypoints when invoked; status platforms and URLs can move:

• OpenRouter status and incident history.
• Vercel status and incident history, specifically the AI Gateway component.
• OpenRouter model pages, their uptime/provider detail, and the public model catalog.
• Vercel model pages and their provider/status views, and the public model catalog. For example, Glyph Cluster.
• Candidate upstream status pages reached from official provider documentation. Include regional and model-specific components when published.

Prefer official incident records and advertised public feeds/APIs over scraped charts. Discover actual feed/API links from the current page; do not assume all platforms expose Statuspage endpoints. A screenshot of a chart can support coarse timing but is not request-level failure evidence. Keep public community reports as separate, lower-confidence observations with links, publication time, and any explicit failure time. Do not count copies of one incident as independent corroboration.

Distinguish inference outages from website/login, billing, control-plane, and unrelated Vercel deployment incidents. A status page returning HTTP 200 proves only that the status page loaded. Catalog disappearance can mean retirement or access restrictions rather than downtime.

Use existing authorized request telemetry when available. Classify 429s, account/credit failures, local connectivity, malformed requests, context errors, and moderation separately from upstream availability. Record route, endpoint provider, region, status/error, and request ID when present. Never retrieve unrelated credentials or place keys in the ledger.

Retain a resumable ledger

Use a user-specified destination, otherwise a confirmed ignored directory such as .data/stealth-model-attribution/<model-slug>/. Keep fetched public records and exact source excerpts beside an append-only JSONL observation ledger. Do not overwrite earlier incident revisions: append updates referencing the original observation ID. Store a compact report in the same folder unless a tracked research report is requested.

Each observation records:

Field	Meaning
id, subject, kind	Stable observation ID, model/gateway/provider/component, and incident, uptime, catalog, request, or community evidence
sourceUrl, sourceIncidentId, capturedAt	Source identity and UTC retrieval time
eventStart, eventEnd, publishedAt, updatedAt	UTC event timing separately from reporting timing; unknown times remain null
timePrecision, boundaryUncertaintySeconds	Chart resolution, polling interval, or explicit timestamps; never invent exact boundaries
scope	Affected model, component, region, gateway, and endpoint provider, where known
state, failureClass, sampleCount	What was observed, error classification, and actual request count if available
rawPath, relatedObservationIds	Retained source evidence and relationships/deduplication

Record monitoring gaps and the covered time range. No published incident is not evidence of health. A health observation applies only to the sampled route, region, and time.

Compare outages and competing explanations

Align event intervals in UTC; keep the user's timezone for displayed timestamps. Use failure onset and recovery separately. Choose timing tolerance before examining candidate rankings, based on the coarsest measurement cadence and known reporting lag. Show strict overlap and tolerance-based overlap separately; do not expand tolerance until a favored candidate matches.

For each candidate, report matched anonymous outages, unmatched anonymous outages, candidate-only outages, and observed healthy controls during candidate incidents. Include overlap durations and onset/recovery offsets when supported. Keep unknown coverage out of both match and mismatch denominators. If only isolated incidents are available, report individual alignments without a correlation coefficient or probability.

Use controls to distinguish causes:

• Several unrelated models failing on one gateway suggests gateway or shared infrastructure trouble.
• One named upstream failing on multiple independent gateways while the anonymous route fails is stronger serving-provider evidence.
• Anonymous recovery tracking one upstream while unrelated routes stay healthy strengthens that association.
• An anonymous route staying healthy during a scoped candidate outage weakens the association only when its region/endpoint coverage is comparable; fallback routing can mask failures.

Account for shared cloud/region/network dependencies, gateway routing changes, fallbacks, free-tier throttling, maintenance, low traffic, and status reporting delay. Events from a single common incident are one piece of evidence. Repeated distinct incidents with independent controls are stronger than many screenshots of the same outage.

Availability correlation usually identifies a possible serving dependency. It does not by itself establish the model family, checkpoint, or publisher. Capability fingerprints and release timing may support hypotheses but remain separate evidence; model self-identification is weak evidence.

Report and continue

Produce a table of candidate publisher, possible serving provider, supporting incidents, contradicting observations, confounders, coverage, and attribution strength. Use unresolved, weak, supported hypothesis, or confirmed; confirmation requires an official alias mapping or public publisher/gateway disclosure. Do not manufacture numerical confidence from outage coincidences.

Lead with the strongest current hypothesis and its limits, cite the underlying incident URLs, and list the observation that would most clearly distinguish competing explanations. Preserve rejected hypotheses and why they were weakened. On later invocations, resume from the ledger and append new observations without silently rewriting earlier conclusions.

Creating this skill does not start scheduled monitoring. If ongoing tracking is requested, define the duration, collection cadence, destination, and end condition before scheduling. Default to public passive evidence; live model canaries are a separate explicitly requested, budgeted activity and must follow the repository eval admission contract. Do not trigger outages or probe private infrastructure to obtain attribution evidence.