Hosted vs first-party AI models | WebmasterID Models

Creator vs billing provider

For most AI models there are at least two parties involved:

The model creator — the lab that trained the model and owns the model weights or the model identity (Anthropic, Google, DeepSeek, Mistral, Meta, and others).
The billing provider — the platform that serves inference and sends you the invoice. This may be the creator's own first-party API, or a separate hosting platform such as a managed inference service or a cloud marketplace.

These are different entities, with different docs, different rate limits, different pricing semantics, and different compliance postures. Conflating them is a recurring source of confusion when reading AI model pricing.

How the catalogue keeps them separate

Every model record in the catalogue has a single providerSlug for the creator. Hosted availability is recorded as a separate set of hosted availability records — one per host × model pair — so a single model can appear under multiple hosts without the creator changing. Each hosted record carries its own model identifier (the slug the hosting platform uses in API calls), its own pricing references, and its own freshness state.

What to look at when a model is hosted

The model creator — listed on the model page as the provider.
The hosted availability record — which platforms serve this model and which billing provider applies.
The hosted model ID — the slug used in API calls on the host. This is rarely identical to the creator's canonical model ID.
The hosted pricing references — set by the host, not the creator.
The freshness state — hosted pricing tends to change more often than first-party pricing.

Why Groq and Together do not become model creators

Hosting platforms serve other people's models. They publish their own model IDs, their own pricing, their own SLAs, and their own region maps — but they did not train the models they serve. The catalogue treats them as hosting platforms with hosted availability rows, not as model creators with their own entity entries. This keeps the entity graph honest: when a hosting platform changes its hosted model lineup, the underlying model record (and its citations) is untouched.

Hosted availability vs pricing reference

Hosted availability is a yes/no signal: this host serves this model right now, with this hosted model ID. The pricing reference is a separate field — sourced from the host's own pricing page, with its own retrievedAt timestamp. Availability can be verified independently of pricing, which matters when a host adds a model before publishing pricing or when pricing changes mid-month.

Common mistakes

Reading hosted pricing as creator pricing.
They come from different sources and have different terms. Always trace the citation back to the page it came from.
Treating the hosted model ID as the creator's canonical ID.
Hosts pick their own slugs. The same model can appear with different IDs across hosts, and the creator's ID may differ from all of them.
Ranking hosts by price without checking unit semantics.
Hosts publish pricing in different units (per request, per token, per second of compute). A direct numeric comparison without unit alignment is meaningless.
Assuming the host inherits the creator's compliance posture.
The hosting platform's data-handling, retention, and regional posture is its own. Verify against the host's terms, not the creator's.

Apply this workflow

Practise this lesson

These exercises route the lesson concept through the verified-data product surfaces. Each one ends with a concrete artifact you can share.

Data gaps to watch

When a model has hosted availability but no hosted pricing reference on file, the host has not published pricing in a machine-readable way yet — or the catalogue has not retrieved it. Either way, treat the absence as a question to confirm externally before integrating.

/use-cases/hosted-inference — the use case that weights hosted availability and hosted pricing references.
/pricing — verified pricing rows for both first-party and hosted.
/docs/pricing-fields — the data-model definition for pricing fields.
/demos/hosted-inference — the guided demo that walks this distinction end-to-end.

Sources and freshness

Hosted pricing tends to change more often than first-party pricing. The catalogue records a retrievedAt timestamp on every row and flags rows that exceed the freshness threshold via the reverification queue.

Teaching example

Illustrative — not a recommendation.

Situation: An engineer reads two cost estimates for the same model — one from the creator's docs, one from a third-party hosting platform — and they differ.

Decision to make: Which pricing reference should the finance projection use, and how should it be sourced?

Verified fields that matter:

Model creator (providerSlug)
Hosted availability records per platform
Hosted model ID on each platform (often different from canonical)
First-party pricing reference + retrievedAt
Hosted pricing reference + retrievedAt per platform

What to inspect next:

Weak vs better approach

Weak approach

Pick the lowest number across all pricing surfaces.
Assume the model creator's terms apply to the hosted platform.
Reuse the creator's model ID in the hosted API call.
Skip the hosted retrievedAt date.

Better approach

Trace each pricing row back to the source that issued the invoice.
Confirm hosted availability + hosted model ID per platform.
Record creator vs billing provider as separate fields in the brief.
Capture retrievedAt for both first-party and hosted rows.

Why better: The lowest displayed number can come from a platform you are not actually integrating with. The better approach keeps creator and host distinct so the finance projection cannot collapse them.

Example artifact

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

Hosted-provider mapping note

## Hosted mapping (illustrative)
Model creator: <creator-slug>

Hosted availability records:
- Host: <platform-A> · hostedModelId: <slug-A> · pricing: <unit> · retrievedAt: <date>
- Host: <platform-B> · hostedModelId: <slug-B> · pricing: unverified-data · retrievedAt: n/a

Data gap: <platform-B> pricing not yet retrieved — flag for /reverification.
Integration target: <platform-A>. Finance projection uses <platform-A> pricing only.

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 the model creator from the billing provider.
Step 2
Apply in /select →
Filter to models with verified hosted availability.
Step 3
Verify in /sources →
Trace each pricing row back to its primary source.
Step 4
Test in /lab →
Confirm host-specific behaviour against your schema before integration.

Review before moving on

Creator and billing provider are recorded as separate fields in my notes.
I have the hosted model ID for the platform I will actually call.
I have a hosted pricing reference with a retrievedAt date.
I have flagged any host-side data gap for /reverification.
I have NOT ranked hosting platforms by price.

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

What this lesson does not teach

Ranking hosting platforms by price — the catalogue records pricing references, not rankings.
Asserting which host is faster — the catalogue does not measure latency.
Recommending a specific host for a specific workload.