Providers and model availability

Provider information explains where a model access path comes from; availability status explains how ready that path is in the current catalog. Use this page when a model is visible but cannot run, when credentials are missing, or when research and execution evidence disagree. The status model is verified, while regional access, account eligibility, permanent provider support, and automatic fallback are not.

Provider model

A provider record associates a model with an access source. The provider can affect configuration, credentials, pricing, latency, throughput, supported modalities, and runtime readiness.

Keep three identities together:

1. the exact model ID;
2. the provider;
3. the current status.

A display name without provider context can be ambiguous. A provider name without model status cannot establish readiness. A runnable status without the intended modality or task test is still incomplete evidence.

Model Library includes provider rollups and provider filtering. Model Intelligence can expose provider research pages. Those views organize records but do not create a service commitment.

A provider record represents the organization or runtime source associated with catalog models. It can carry a label, runtime provider ID, category, model counts, capability families, status rollups, and health-related fields.

Provider research pages and gateway provider overlays are separate views. Do not treat a normalized provider grouping as proof of configured access.

Availability

The catalog uses five distinct categories:

These categories should be preserved in documentation and troubleshooting. Replacing them with a generic red or green availability label loses the reason a request is blocked.

Availability is dynamic. Record the date and current surface when a decision depends on it.

The canonical model status values are catalog-only, provider-configured, runnable, unsupported-modality, and missing-key.

Runnable is the strongest current gateway-oriented status in this set. Provider-configured still requires model-level interpretation, and catalog-only is discovery evidence rather than executable access.

Regional and account constraints

The Batch 01 sources do not verify provider regions, country availability, account tiers, allowlists, quotas, billing prerequisites, or organization-specific restrictions. Do not infer them from a provider logo, model record, or runnable status.

A model may be runnable in the inspected environment and unavailable elsewhere. A missing key may be the visible blocker while another account condition remains unresolved. The correct procedure is to verify the current account and provider path through the owning product.

When documenting a deployment decision, list regional or account requirements as open checks unless an authoritative source establishes them. Avoid promises such as “available globally” or “works for all accounts.”

The current product surfaces do not define supported regions, account eligibility, provider plan requirements, quotas, export restrictions, or organization-specific access.

Do not claim universal availability. Verify the current provider account and environment before selecting a model for production work.

Environment-specific conclusions

Phrase availability findings with their scope: “runnable in the inspected environment on the observation date” is stronger and more accurate than “available.” The scoped statement can be verified and does not imply access for another workspace, account, or region.

When sharing a recommendation, include the condition that another environment must recheck provider configuration, credentials, modality, and status. This prevents a local success from becoming an unsupported platform-wide promise.

Separate product maturity

A model can be runnable while the owning Gateway surface remains beta or another interface remains preview. Keep product release posture separate from model status. The first describes the surface; the second describes the current catalog route for a model.

Fallbacks

Fallback uses another model, provider, or path when the preferred route is blocked. Approved platform language allows fallback behavior where configured.

A valid fallback plan states:

• the trigger condition;
• the alternate model and provider;
• capability and modality equivalence;
• context and output compatibility;
• cost and latency consequences;
• data-handling or licensing differences;
• whether approval is required;
• evidence that identifies the route actually used.

Do not assume the platform automatically falls back because multiple records are runnable. A manual alternate selection is safer than an undocumented substitution.

Fallback should be blocked when the alternate route changes an essential requirement or when the evidence needed to review the substitution is unavailable.

Approved copy allows fallback behavior where configured, but no universal fallback rule is established here.

A provider or model failure does not prove that Ethen will select another route. Document fallback only from the relevant Gateway configuration and include changes in cost, latency, model behavior, and data handling.

Provider pages

Provider pages can group models, normalized profiles, or status information associated with one provider. Use them for discovery and comparative research.

A provider page can help answer:

• which records are associated with the provider;
• which capabilities or model types appear;
• which research fields are populated;
• how models compare within the available data.

It cannot by itself answer:

• whether the current account has access;
• whether a specific credential is configured;
• whether all models are runnable;
• whether service is available in a region;
• whether prices or limits are permanent;
• whether the provider meets a legal or compliance requirement.

Return to the selected model’s catalog record and Gateway status before execution.

Model Library implements provider-specific catalog routes, and Model Intelligence implements provider indexes and dynamic provider pages.

The approved documentation route list has not approved those patterns for published documentation links. Use the approved Model Library and Model Intelligence indexes until the map is updated.

Operational guidance

Use a status-driven response:

Catalog-only. Keep the model in the research shortlist. Identify the supported configuration path before planning a run.

Provider-configured. Check credentials, requested modality, current account access, and product maturity. Then perform a small test.

Runnable. Confirm the exact model and provider, submit a bounded task, and preserve visible route or receipt evidence.

Unsupported-modality. Restate the required input and output types. Select a compatible capability family or a product surface that owns the modality.

Missing-key. Use the approved API-key route or current administrative process. Never place the key in a prompt, artifact, or documentation example.

For every case, distinguish research evidence from runtime evidence. A Model Intelligence profile can support why a model is interesting; Model Library and Gateway status support whether the current environment can use it. A successful test supports one workload at one time. None of those facts alone establishes universal availability.

Before relying on a provider, confirm current model status, provider configuration, required key, supported modality, source evidence, pricing availability, limits, and the consequence of provider failure.

Use a small representative request and preserve the exact model ID. Recheck status over time because provider health, catalog data, and availability can change.

Availability review record

Create a compact record whenever provider readiness affects a decision:

• exact model ID and display name;
• provider;
• capability and requested modality;
• current status;
• credential condition shown by the product;
• relevant context, output, price, latency, or throughput fields;
• date and route observed;
• next action and owner.

This record avoids the vague statement “the model is unavailable.” It shows whether the blocker is catalog state, provider setup, credential, modality, or another unverified account condition.

Status transitions

A record can move from catalog-only to configured, from missing-key to runnable, or in the opposite direction as configuration changes. Documentation should not promise a transition or its timing. Recheck status immediately before an important run.

When status changes, preserve the earlier observation if it influenced a decision. The history can explain why a model was excluded, why fallback was used, or why a test was delayed.

Provider comparison

Compare providers for the same workload using exact records. Review capability, status, current price fields, latency, throughput, context, output, source evidence, and observed behavior. Do not assume that the same model name produces identical operational results through every provider.

Provider research pages can suggest candidates, but the catalog and Gateway path own immediate readiness. If the research page and runtime status disagree, retain both and use the current execution surface for the test decision.

Credential boundaries

A key is configuration, not task context. It should be managed through the approved product control and never copied into prompts, artifacts, screenshots, or decision notes. A missing-key status supports only the conclusion that a required credential is absent; it does not define who may create one or how it is stored.

If a key is added and the model remains blocked, re-evaluate modality, provider configuration, account access, and product state rather than repeatedly replacing credentials.

Escalating an availability issue

Provide the model ID, provider, current status, route, date, requested modality, and non-secret error evidence. State whether the issue occurs in Model Library, Gateway, the console, or another surface. This distinction helps the owner separate catalog data, credential setup, routing, and runtime behavior.

Do not include raw secrets or make a regional claim based on one account. Keep the report scoped to the observed environment.