Skip to main content
BenchLM
Provider-issued identifiers

Find the exact model ID before it reaches production

Source-linked IDs
55
API identifiers
49
Providers
10

Search documented API and weight identifiers, copy the exact string, and open the source that published it. Moving aliases and pinned IDs stay distinct; a BenchLM model key never masquerades as a provider ID.

Source-linked identifiers

Model ID directory

49 shown

What the identifier does and does not establish

An ID is only part of the deployment

The name on a model page, the identifier in your request and the provider serving that request are three different pieces of one setup. This directory gives you the documented identifier and the page that published it. The serving route and the snapshot you deploy stay your choice; the directory never guesses either from a display name.

Four identifier cases, what each string establishes, and what it leaves open.
CaseWhat the string establishesWhat it leaves openIn this directory
Stable IDThe provider’s current documented identifier for a model, such as claude-sonnet-5.Which snapshot answers today’s request, and whether a partner platform uses the same string and the same retirement date.Listed with the source page and the date we last checked it.
Pinned versionA dated snapshot the provider documents separately. It fixes the weights you call until that snapshot is retired.The retirement date on every route. The same snapshot can carry different dates on different platforms.Appears as its own row only when a provider publishes one. We do not derive a pinned ID from a stable one.
AliasA moving pointer such as gpt-5.3-chat-latest. A request resolves to whatever the provider points it at today.A fixed snapshot. An alias can be marked deprecated while the model behind it is still served, which is the current OpenAI status for that example.Listed with the provider’s own status label; an alias never stands in for a pinned ID.
Unresolved identityA model with a launch post but no published API identifier. GPT-5.3 Codex Spark is the current example.Everything an integration needs. There is no string to copy yet.No row. We leave the identifier blank rather than invent one from the product name.

Before and after: one Anthropic entry

Before: the request carries the display name from a model page, “Claude Sonnet 5”, and the integration assumes the first-party API. After: the request carries claude-sonnet-5 copied from this directory, sourced to Anthropic’s models overview and last checked on the date shown in the row; the route is chosen on purpose, because Anthropic, Amazon Bedrock, Vertex AI and Azure AI Foundry each publish their own schedule for the same model.

Limit: the source date is the last time we checked the provider page, not a guarantee the ID is still current today. A provider can rename or retire an identifier after that date; the deprecation calendar holds the dated notices we have, per route.

What “Check this model” does

The link opens Radar with the provider and this exact ID in the link fragment, sends no referrer, and stores nothing until you choose to. Radar does not pick a serving route from the ID; you choose the route there, and only routes with a published notice return a date.

A row without the link has no single documented API identifier from the provider’s own site, or belongs to a provider the check does not cover yet. Use the source link instead, and test the candidate against your own workload before switching; the custom benchmark guide covers a small repeatable check.

Only source-linked identifiers enter the directory

Repository aliases without a provider source stay out. Request-time reasoning settings also stay attached to their shared API ID instead of becoming fictional model IDs. Platform-specific IDs need their own source before they appear here.