Models and providers
Understand how Ethen represents models, providers, status, availability, aliases, routing, and fallback boundaries in current catalog surfaces.
Models and providers
A model and a provider are related but separate parts of an execution path. Read this page when a catalog entry is visible yet a run is unavailable, when two records share similar names, or when a routing decision needs to be interpreted. The current catalog types verify model, provider, capability, status, pricing, context, performance, and source-evidence fields, but provider presence never guarantees access for every account, region, modality, or workload.
Models
A model record identifies the system being considered or requested. In Ethen, models appear in at least two grounded representations:
- the Gateway catalog, used by Model Library for operational fields and status;
- the normalized Model Intelligence profile, used for research, comparisons, charts, benchmarks, specifications, FAQs, and quality information when present.
These representations can overlap without being identical. A catalog record is oriented toward provider and runtime status. A normalized profile is oriented toward evidence and analysis. A reader should not assume that every profile maps to a runnable catalog entry or that every catalog row has complete research enrichment.
Verified catalog fields can include model ID, provider, model name, capability family, context window, maximum output tokens, latency, throughput, pricing fields, capability tags, source files, extraction confidence, and notes. Missing values remain unavailable.
A model record can include an ID, display name, capability family, context window, output limit, latency, throughput, prices, capability tags, source files, extraction confidence, notes, and runtime status.
Not every record contains every field. Missing values mean unavailable. Model Library records and Model Intelligence profiles serve different purposes and may contain different evidence.
Providers
A provider is the configured source associated with model access. The provider may determine credentials, route readiness, supported modalities, and other operational constraints. This batch does not establish a permanent provider list or universal regional availability.
Provider information should be read alongside model status:
| Provider-related observation | What it supports | What it does not support |
|---|---|---|
| Provider name appears on a record | The catalog associates the model with that provider | The account has access |
Status is provider-configured | A provider relationship has been configured | The intended request will run |
Status is missing-key | A required credential is absent | That adding any key will solve every issue |
Status is runnable | The current catalog reports the strongest execution-ready state | Guaranteed availability across all contexts |
| Provider page or rollup exists | Models can be grouped by provider | A contractual or regional commitment |
Provider configuration is operational state. It can change independently of research data or model capability.
A provider is the organization or runtime source associated with a model. The catalog can also represent provider health, whether configuration exists, whether setup is required, whether a mock fallback is used, and whether an adapter or coding probe is available.
Provider presence does not prove all models from that provider can run. Provider labels and runtime provider IDs are separate data fields and should not be merged casually.
Model aliases
An alias is a name that may point to another model identifier, version, or route. The supplied Batch 01 types and explorer support model identifiers, but they do not provide enough evidence to document a universal alias-resolution process.
When two names appear related:
- Compare the exact model IDs rather than display names alone.
- Check the provider attached to each record.
- Review capability, context, output, pricing, and status fields independently.
- Use source files or notes when available.
- Avoid assuming that one name automatically upgrades, redirects, or remains stable.
An alias can simplify selection, but it can also hide a version change. Documentation should preserve the identifier visible at the time of a decision whenever reproducibility matters.
The current catalog type definition exposes model IDs and display names but does not define a universal alias system or alias-resolution contract.
Use the exact model ID presented by the surface when configuring or copying a model reference. Treat shorter names as display labels unless a product-specific source explicitly defines them as accepted aliases.
Availability
Availability is represented through distinct status categories:
catalog-only: represented in the catalog, without a verified configured path;provider-configured: provider access is configured, but task readiness still needs confirmation;runnable: currently reported as ready for supported execution;unsupported-modality: the requested type is not supported by the selected path;missing-key: a required provider credential is absent.
These statuses should not be collapsed into “available” and “unavailable.” They identify different corrective actions. A catalog-only record calls for configuration review. A missing key calls for credential setup. Unsupported modality calls for a different model, capability, or route. Runnable calls for a task-specific test and evidence review.
Availability also differs from maturity. A documentation manifest may say ga, a product page may identify a beta surface, and a model record may say runnable. Those values refer to different layers and must remain separate.
Model Library distinguishes catalog-only, provider-configured, runnable, unsupported-modality, and missing-key. These are the canonical current status categories for this documentation set.
A record can be useful for research even when it is not runnable. Availability may depend on provider setup, current adapter support, modality support, and environment configuration.
Routing
Routing is the selection of a model lane or processing path for a request where the product exposes that behavior. A routing decision can use model, provider, capability, status, cost, latency, context, or other available evidence, but Batch 01 does not verify one automatic routing algorithm across every Ethen product.
A transparent routing record should make it possible to answer:
- Which model ID was selected?
- Which provider was associated with the request?
- Which capability or modality was required?
- What status was visible before execution?
- Which evidence influenced the choice?
- Was the route selected by a person, a configured rule, or presentation logic?
Model Intelligence routing suggestions are derived presentation logic. They can help a reader compare candidates, but they are not proof that Gateway used the same route or that the suggestion is correct for every workload.
Approved copy supports model routing as a platform capability, and the catalog exposes a default-route marker.
Do not infer a universal automatic routing algorithm, model-selection policy, or fallback chain. Document a route only when the relevant Gateway or product implementation defines it. A default-route marker is evidence about the current catalog overlay, not a guarantee for every request.
Building a route candidate set
A route candidate set should contain only records that meet the workload’s non-negotiable requirements. Begin with capability and modality, then remove records whose current status blocks the intended action. For the remaining candidates, record provider, context, maximum output, pricing, latency, throughput, source evidence, and notes when present.
This creates a defensible distinction between eligible and preferred. Eligibility comes from capability and operational readiness. Preference comes from quality, cost, latency, context, evidence, and risk. A model with strong benchmark evidence may be preferred but ineligible because its route is catalog-only. A runnable model may be eligible but remain a poor fit for the workload.
Version and identity discipline
Keep the exact model ID used for a test. Display names can be shortened for readability, and research profiles may use normalized slugs, but those identifiers should not silently replace the catalog ID. When a provider exposes related versions, compare each record independently rather than assuming newer, larger, or similarly named entries inherit the same status and fields.
A decision note should link the research identity to the operational identity when the relationship is verified. If the mapping is unclear, preserve both names and flag the gap. This is preferable to merging records based on appearance.
When provider evidence conflicts
If a provider rollup, model record, and detail page appear inconsistent, do not choose the most favorable status. Record the route, date, selected record, and visible values from each surface. The difference may result from dynamic updates, normalization cadence, or distinct product responsibilities.
Use the Gateway or current runtime result to establish whether the immediate request can proceed. Use Model Intelligence to explain research evidence. The conflict remains a documentation issue until the owning sources are reconciled.
Fallback behavior
Fallback means using another model, provider, or path when the preferred route cannot proceed. Approved terminology allows “fallback behavior where configured,” which is intentionally conditional.
Do not assume fallback from the presence of multiple models. A valid fallback requires at least:
- another candidate with a compatible capability or modality;
- a provider path that is configured and permitted;
- acceptable context and output constraints;
- a clear decision about quality, cost, latency, and risk;
- evidence showing which route actually handled the request.
Fallback may be inappropriate when the replacement changes data handling, model behavior, licensing assumptions, or output format. A blocked request can be safer than an invisible substitution.
When fallback is supported, document the specific product configuration that enables it. When it is not verified, present alternate selection as a manual recovery step rather than an automatic platform guarantee.
Approved language permits fallback behavior where configured, but the inspected sources do not define its trigger, selected provider, retry behavior, or effect on cost and data handling.
Treat fallback as an explicit configuration concern. A later Gateway page should document triggers, observability, and failure behavior from route implementation and tests.
Fallback evidence
When an alternate route is used, the task record should name the original model and provider, the blocking status, the replacement, and the reason the replacement remained acceptable. Preserve any change in modality, context, output, price, or review requirement. Without that record, later reviewers cannot tell whether the observed result came from the preferred route or from a substitution.