Model and Modality PlaybooksJune 24, 2026Big Y

AI Model Catalog Guide: How to Read Providers, Endpoints, Groups, and Prices

Use this AI model catalog guide to read providers, endpoints, groups, availability status, pricing units, and route checks before production.

AI Model Catalog Guide: How to Read Providers, Endpoints, Groups, and Prices

An AI model catalog is useful only when it helps a team make a production decision. A page full of model names is not enough. Developers need to know which provider owns the model, which endpoint family the app will call, which group or route tier will serve traffic, whether the row is currently available, and how the price is measured before the first real user request goes through it.

This AI model catalog guide was checked on June 24, 2026 against Flatkey public pages, the live Flatkey pricing API, saved Ahrefs research, and official model-catalog documentation from Microsoft, Google, Vercel, and OpenAI. Treat every catalog count, status, endpoint family, and pricing field as a point-in-time snapshot. Before production traffic, re-open Flatkey pricing, confirm the exact model row, and run a low-risk route test.

The practical goal is simple: turn model browsing into a repeatable review. If your team can read provider, endpoint, group, status, price, and owner from the same AI model catalog record, the model decision becomes easier for engineering, finance, support, and procurement to approve.

Quick Answer: How To Read An AI Model Catalog

Read an AI model catalog from left to right: provider first, endpoint second, group third, status fourth, price fifth, and route test last. That order keeps teams from picking a model name that looks attractive but cannot be called safely through the endpoint, group, or budget policy the application actually uses.

Catalog Field What It Tells You Decision To Make Flatkey Check
Provider Who supplies or hosts the model route. Can this provider meet your feature, risk, and support expectations? Confirm the vendor record and any provider-specific row notes.
Model ID The exact string your app will request. Can the app use this ID without alias drift or stale documentation? Copy the model row from /pricing, not from memory.
Endpoint family The protocol shape: chat, responses, image generation, video, Gemini, Anthropic, or another route. Does the current SDK, request body, streaming mode, and response parser fit? Check the supported endpoint family before changing the base URL.
Group The route tier or resource pool that serves the request. Which group should handle staging, production, fallback, or cost-sensitive traffic? Compare the exact group label and group ratio before launch.
Status Whether the latest catalog check is clean, unsupported, or unresolved. Should this row receive production traffic, a smoke test, or no traffic? Do not treat a visible row as available until status and a request test agree.
Pricing unit How usage is charged: input, output, cache, image, video, second, or fixed job-style unit. Which budget formula and quota should apply? Review token-style fields and non-token price fields separately.
Route test Whether the model works for the exact feature path. Can engineering, finance, and support accept the result? Run a staging request, then inspect usage, cost, status, and logs.

Current Flatkey AI Model Catalog Snapshot

The live Flatkey pricing API snapshot used for this article returned success: true on June 24, 2026. It exposed 637 catalog rows, 23 vendor records, five usable group labels, and six endpoint families. The top-level pricing version in the response was a42d372ccf0b5dd13ecf71203521f9d2.

Snapshot Field June 24, 2026 Value How To Use It
Total catalog rows 637 Use the AI model catalog as a row-level source, not a static provider list.
Vendor records 23 Provider identity matters for support, compliance, and fallback decisions.
Endpoint families openai, gemini, image-generation, anthropic, openai-response, openai-video Endpoint family tells you whether the current request format can work.
Availability statuses available, official_unsupported, unknown_failure Status should drive traffic gating and smoke-test priority.
Available rows 132 Still require a route test for your endpoint, group, prompt, and quota.
Official unsupported rows 37 Do not use these for production without a newer verified status.
Unknown failure rows 468 Treat as unresolved until route, account, upstream, or status evidence is checked.

Flatkey's public homepage positions the product around one API key, the OpenAI-compatible base URL https://router.flatkey.ai/v1, clear pricing, unified billing, and one dashboard for keys, usage, and routing. Those claims make the AI model catalog operationally useful, but they do not remove the need to verify the specific row your product will call.

Read Providers Before You Read Model Names

Model names travel across vendors, gateways, docs, and aliases. Provider identity is the first stabilizing field. It tells you who supplies the model route, which account or upstream may be involved, where support expectations come from, and whether the model belongs in a direct provider plan, a gateway route, or a restricted evaluation path.

Official cloud catalogs take the same problem seriously. Microsoft Foundry Models separates models sold by Azure from partner and community models, and tells customers to review model descriptions, model cards, documentation, and legal terms before selecting a model. Google Model Garden lets teams filter by model collections and providers, then open model cards for more detail. The lesson for any AI model catalog is the same: provider is not decoration; it is part of the operating contract.

For Flatkey evaluation, write down:

  • Provider or vendor: the vendor record associated with the row.
  • Model row: the exact model ID visible in Flatkey pricing.
  • Owner: the team, feature, customer, or budget owner requesting the model.
  • Reason for selection: quality, cost, latency, modality, context, tool use, image, video, or fallback behavior.
  • Replacement route: what the app should use if the provider row changes status.

Read Endpoints As Contracts, Not Labels

An endpoint family tells your app what request and response shape to expect. A model that appears under an openai endpoint family may fit an OpenAI-compatible SDK flow. A model that appears under anthropic, gemini, image-generation, openai-response, or openai-video may need a different request body, parser, streaming behavior, file handling path, or usage interpretation.

That is why a useful AI model catalog should be read together with the migration plan. If your app already uses an OpenAI-compatible client, start with the OpenAI-compatible API migration workflow: change the base URL in staging, keep the model ID explicit, run a small request, inspect the response, then review logs and cost. Do not assume every model row supports every endpoint style.

Endpoint Family What To Check Common Failure Mode
openai Base URL, model ID, messages format, streaming, tool calls, JSON mode, usage fields. SDK call succeeds in syntax but uses a model row that does not support the feature.
openai-response Responses-style request body, output parsing, tool behavior, multimodal input. Chat-completions assumptions leak into a Responses-style workflow.
anthropic Messages request shape, system prompt handling, image input behavior, usage fields. An OpenAI-style body is sent to an Anthropic-style route without adaptation.
gemini Gemini request shape, multimodal input, safety settings, response parsing. Model selection ignores provider-specific feature or response differences.
image-generation Input image rules, output size, quality, moderation, format, and accepted result count. Budgeting by request count hides image quality and retry costs.
openai-video Duration, aspect, async job state, polling, failure handling, and usage unit. Video jobs are treated like cheap synchronous text calls.

Read Groups As Route And Cost Policy

In a unified gateway, a group is not just a label. It can represent a route tier, resource pool, account path, or pricing policy. The June 24 Flatkey snapshot exposed usable group labels including Economy, Standard, Claude Economy, Claude Official, and Seedance2.0 Official. The response also included group descriptions and group ratios.

When reading an AI model catalog, groups answer questions that a model name cannot:

  • Which group should staging use? A low-risk route may be enough for integration tests.
  • Which group should production use? Production may need a different provider path, cost profile, or support expectation.
  • Which group should fallback use? A fallback route must be compatible with quality, latency, and budget requirements.
  • Which group should finance review? Group-level ratios can change the effective cost for the same model name.
  • Which group should procurement approve? A direct or official route may carry different evidence needs than an economy route.

The safe habit is to record the group in the model decision, not just the model ID. A model row that looked reasonable in one group can have a different cost or operating path in another group.

Read Prices By Unit Before Comparing Rows

Pricing fields are easy to misread because different model families expose different units. Text models often separate input, cached input, and output. Image and video rows may add quality settings, generated media units, job duration, or fixed model-price style fields. OpenAI's public pricing page, for example, separates input, cached input, and output prices per 1M tokens for its models. Google Model Garden notes that open source model usage can involve tuning and deployment compute charges. Microsoft Foundry notes that serverless deployments are typically billed for API inputs and outputs, often in tokens, while managed compute uses virtual machine core hours.

For a Flatkey AI model catalog review, separate pricing shapes before comparing rows:

Pricing Shape Fields To Inspect Budget Question
Token-style text model_ratio, completion_ratio, cache_ratio Will the feature spend more on prompts, outputs, cached context, or retries?
Multimodal chat Endpoint family, input tokens, output tokens, image/video inputs, cache behavior. Are non-text inputs changing the effective cost?
Image generation Model row, endpoint family, output settings, retry count, accepted image count. What does one accepted image cost after failures and edits?
Video generation Model row, duration, quality, job state, retry policy, model_price if present. Can quota stop expensive jobs before a budget incident?
Group-adjusted route Group label, group ratio, production route, fallback route. Is the team comparing the group it will actually use?

For a deeper cost workflow, use the AI model pricing comparison guide after you shortlist rows. This AI model catalog guide helps you decide which rows deserve pricing analysis in the first place.

Read Status Before Production Traffic

A visible catalog row is not the same as a production-ready route. In the June 24 Flatkey snapshot, only 132 of 637 rows had available as the latest availability status. The remaining rows were split between official_unsupported and unknown_failure. That does not mean every unresolved row is permanently unusable; it means the row needs current route evidence before it carries user traffic.

Use status as a gate:

  1. Available: run a staging smoke test for your exact endpoint, group, request body, and prompt shape.
  2. Official unsupported: do not launch production traffic unless a newer source proves the status changed.
  3. Unknown failure: investigate whether the issue is upstream status, account permission, route configuration, region, quota, or transient failure.
  4. No clear status: treat the row as unapproved until a dashboard or API test creates evidence.
  5. Status changed: update the model decision record and notify the owner before rerouting users.

The status field is also a finance control. A fallback route that silently moves from a clean low-cost row to an unresolved or more expensive row can turn a model experiment into an incident. Keep status, group, and price together in every AI model catalog review.

A Flatkey Workflow For Catalog Review

Use this workflow when a team asks to add or change a model behind one key.

  1. Open the current catalog: start from Flatkey pricing and copy the exact row.
  2. Record provider and group: do not approve a row using model name alone.
  3. Confirm endpoint family: match the route to your SDK, request body, streaming plan, and parser.
  4. Check status: only route production traffic after status and a live request agree.
  5. Classify the pricing unit: token, cache, image, video, duration, fixed price, or group-adjusted route.
  6. Run a low-risk test: send a staging request through https://router.flatkey.ai/v1 or the relevant route family.
  7. Review usage and cost: inspect the dashboard for model, usage, cost, status, and routing evidence.
  8. Set quota and owner: connect the row to a key, budget owner, limit, alert, and rollback route.
  9. Save the decision: keep the catalog row, date, status, group, price fields, test result, and owner signoff together.

This is also the clean handoff between engineering and finance. Engineering proves the route works. Finance proves the unit and owner make sense. Support proves the model decision can be explained when a customer asks why a feature changed.

Template: AI Model Catalog Review Record

Keep a compact record for every model row that reaches staging or production. This turns AI model catalog browsing into an operating habit.

AI model catalog review record
Review date:
Requester:
Feature or workflow:
Environment: development / staging / production / batch / customer-facing

Model row:
Provider or vendor:
Endpoint family:
Group:
Availability status:
Pricing fields:
Expected unit: input tokens / output tokens / cached input / image / video / duration / fixed job

Route test:
Request path:
SDK or client:
Response accepted: yes / no
Usage visible: yes / no
Cost visible: yes / no
Quota attached: yes / no

Owner:
Budget owner:
Support owner:
Fallback route:
Rollback condition:
Next review date:

Common AI Model Catalog Mistakes

Mistake Why It Creates Risk Better Review
Picking by model name only Aliases, providers, endpoint families, and groups can differ. Approve the exact row: provider, endpoint, group, status, price, owner.
Assuming OpenAI-compatible means every feature works Tool use, streaming, images, video, and response formats can vary by route. Run a feature-level smoke test before launch.
Ignoring group labels The same model name can have different cost or route behavior by group. Record the production group and compare group ratios.
Treating unresolved status as harmless Unknown failures can hide route, permission, upstream, or account issues. Gate traffic until status and request evidence are clean.
Comparing prices without units Input tokens, output tokens, cached tokens, images, and video jobs do not budget the same way. Classify the pricing unit before using a comparison table.

When A Unified AI Model Catalog Helps Most

A unified AI model catalog helps most when your product already spans more than one provider, modality, or operating owner. A single-provider prototype can often start from one official docs page. A production AI product usually needs a more durable view: GPT, Claude, Gemini, DeepSeek, Qwen, image models, video models, routing groups, status, quotas, usage, and cost in one review loop.

Flatkey is designed for teams that want one API key, one compatible base URL, unified pricing and billing, and one dashboard for keys, usage, and routing. The catalog review is where that value becomes concrete. You can compare rows, choose a route, test the endpoint, attach quota, and keep usage evidence in one operating path instead of spreading the decision across provider portals and spreadsheets.

The right next step is not to trust a row blindly. Start with the current model pricing page, copy the exact model and group, test the route in staging, then get a key when you are ready to evaluate the workflow in your own application.

FAQ

What is an AI model catalog?

An AI model catalog is a searchable list of model rows with enough context to choose, test, and operate a model. A useful catalog should expose provider, model ID, endpoint family, group or route tier, availability status, pricing unit, and documentation or dashboard evidence.

Why does provider matter in an AI model catalog?

Provider identity tells you who supplies or hosts the route, which terms and support expectations may apply, and which fallback or procurement review is needed. Model name alone is not enough for production approval.

How should I compare endpoint families?

Compare endpoint families by request shape, SDK compatibility, streaming behavior, tool support, multimodal input, response parsing, and usage fields. A row that works for chat may not work for image, video, Gemini, Anthropic, or Responses-style requests.

What is a model group?

A model group is a route or resource label that can affect cost, upstream path, support expectation, or fallback behavior. In Flatkey, read the group alongside the model ID and price fields before approving a route.

How often should teams recheck an AI model catalog?

Recheck before every production launch, model swap, fallback change, major price review, or incident follow-up. AI model catalogs change quickly, so dated snapshots should not be treated as permanent availability or pricing guarantees.

Final Catalog Review Step

Before a model row reaches production, assign an owner to each field in the AI model catalog record. Engineering owns endpoint fit and route testing. Finance owns price unit and budget. Support owns customer-facing impact. Platform owns quota, fallback, and rollback. That is how a catalog becomes infrastructure instead of a model menu.

To run the Flatkey version of the review, open Flatkey pricing, select a model row, confirm provider, endpoint, group, status, and price unit, then get a key and test the route before scaling traffic.