Provider coverage reference

ProviderEntity shape

interface ProviderEntity {
  id: string;
  slug: string;
  name: string;
  description: string;
  // documentation surface
  docsUrl?: string | null;
  apiDocsUrl?: string | null;
  pricingUrl?: string | null;
  modelCatalogueUrl?: string | null;
  statusPageUrl?: string | null;
  deprecationsUrl?: string | null;
  // verification
  verified: boolean;
  verificationStatus: 'verified' | 'partial' | 'unverified';
  lastCheckedAt: string | null;
  updatedDate: string | null;
  notes?: string | null;
  // operational
  headquarters?: string | null;
  website?: string | null;
}

A provider record is intentionally lean. The model entries attached to a provider carry the per-model pricing, lifecycle, modality, and benchmark fields; the provider record itself records the documentation surface and the overall verification status.

Coverage dimensions

Six URLs make up the provider surface, each one verified independently:

• docsUrl — top level technical documentation.
• apiDocsUrl — stable API reference URL (Messages, chat-completions, etc.).
• pricingUrl — primary pricing reference.
• modelCatalogueUrl — the page listing the provider's current models.
• statusPageUrl — public status page (used by the status pipeline; not an uptime claim).
• deprecationsUrl — official deprecation schedule, where the vendor publishes one.

Model creator vs hosted platform

Providers fall into one of two roles:

• Model creator. The organisation that trains and releases the model. Anthropic (Claude), Google (Gemini), DeepSeek (DeepSeek V4 Pro), Mistral (Mistral Large 3), and Meta (Llama 4 Scout / Maverick) are model creators. The model record's providerSlug always points at the creator.
• Hosted platform. An inference provider that does not create models but charges for running third-party ones. Groq and Together AI are hosted platforms. The catalogue intentionally does not carry per-model records under providerSlug: "groq" or providerSlug: "together-ai" — that would misattribute the model's origin. Pricing offered by these platforms lives in data/hosted-pricing.ts and carries pricingContext: "hosted_provider_api".

Both roles can be verified — the verification is about whether the platform's primary documentation is reachable and has been used to populate the records that depend on it, not about whether the platform creates models.

Hosted availability vs hosted pricing

For hosted-platform providers, the catalogue separates two claims: (1) availability — the platform exposes the model under a specific hosted model ID, and (2) pricing — the per-token rate the platform charges. Availability is stable; pricing is volatile and reference- only. The provider page renders both, but they are not coupled: an availability row can render even if its associated pricing row goes stale.

The reverse also holds — a model creator's provider page surfaces "third-party hosting of our models" from the availability catalogue, distinct from any first-party pricing the creator may publish. Meta's provider page is the worked example: Llama 4 Scout has no Meta first-party API pricing, but availability on Groq is recorded and rendered. See /research/api-pricing-methodology.

Current provider coverage matrix

Derived from the data layer at render time:

What "verified" means at the provider level

A provider is marked verified when its primary documentation surfaces (docs, API reference, pricing reference) have been successfully retrieved and used to populate at least one verified model record. Anthropic, Google, and DeepSeek are verified by this definition today. The provider's notes field records the date, the citation tokens used, and the scope of what was verified.

Partial verification

A provider is marked partial when its primary URLs are reachable but some model-record fields remain null. Mistral is the canonical example: the models overview and API reference were retrieved, but per-model spec card pages return 404, so context window / max output / modality / pricing on the Large 3 record remain unverified. The provider notes spell out the specific gap and the unblock (a manual browser pass).

Blocked retrieval

When a provider's primary URLs cannot be retrieved (HTTP 403, JS-only rendering, redirect loop), each blocked attempt is recorded in verification-attempts.ts with URL, date, outcome category, and a free-text note. The provider record carries verified: false and verificationStatus: "partial" until the gap closes. OpenAI is the current example — platform.openai.com returns 403 to automated retrieval and the attempt log shows every URL that was tried. Audit log is on /coverage.