Models overview
Understand the Ethen model ecosystem, access surfaces, capability categories, runtime status, and model-comparison destinations.
Models overview
Ethen has two complementary model-facing systems: Model Library for current gateway catalog and runtime-oriented status, and Model Intelligence for normalized research and comparison. Use this overview when deciding where to look first. The two systems can inform the same decision, but neither should be treated as complete proof of the other’s data, availability, or maturity.
Model ecosystem
The model ecosystem includes model records, providers, capability families, operational status, normalized profiles, source evidence, and access-oriented product routes. Each layer answers a different question.
| Question | Primary surface | Evidence you should expect |
|---|---|---|
| Which models are represented in the gateway catalog? | Model Library | Model ID, provider, name, capability family, status, and available fields |
| Is a model configured or runnable now? | Model Library and Gateway | Catalog status, provider configuration, credential state, modality support |
| How does a model compare on research signals? | Model Intelligence | Benchmarks, specifications, charts, comparison data, quality flags |
| Which provider path may be used? | Model Library and Gateway | Provider association, status, approved access routes |
| Which model should I choose? | Both, plus task-specific testing | Workload fit, evidence, operational constraints, and observed results |
The catalog and intelligence layers should be consulted together when the decision matters. Research can identify promising candidates; operational status determines whether a candidate can be tested through the current environment.
Ethen exposes two complementary model surfaces: Model Library for gateway catalog and runtime-status truth, and Model Intelligence for normalized profiles, research, charts, and comparisons.
Keep these surfaces distinct. A catalog record can exist without a full research profile, and a research profile does not prove that the model is currently runnable through AI Gateway.
One decision, two records
For important selections, preserve both a research note and an operational note. The research note explains why a model is promising; the operational note captures provider, status, and the tested route. Keeping both prevents a successful run from erasing quality concerns or a strong profile from erasing configuration limits.
Ways to access models
The approved Batch 01 routes support three main entry points:
/model-libraryfor catalog inspection and model-status filtering;/model-intelligence/modelsfor normalized profiles and comparisons;/ai-gatewayand its approved child routes for configured access, playground use, documentation, and API-key management.
The console can also act as a shared workspace entry point. Its categories include chat, coding, research, media, and design, but the exact model path and maturity can vary by surface.
Access should be understood as a chain: catalog presence → provider configuration → credential readiness → capability match → runnable status → successful task test. A model can stop at any link in that chain.
The approved routes allow readers to inspect models in Model Library, research them in Model Intelligence, and move toward configured requests through AI Gateway or its playground.
Access depends on model status, provider setup, supported modality, and current product state. Do not treat a visible card as a promise of execution.
Model categories
The gateway catalog exposes capability families such as text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown. These categories help narrow a search, but they do not describe every supported input or output combination.
Model Intelligence can also organize profiles into categories and provider views. Some classification logic is derived from normalized metadata or keyword-based grouping. Category membership is useful for discovery and should not be presented as an independently validated scientific taxonomy.
Open-weight and proprietary distinctions can also appear in research data. Those labels help frame control, portability, and operational choices, but they do not establish license terms for an individual model.
Model Library uses capability families such as text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown. Model Intelligence also uses model types and derived categories.
A category is a navigation and analysis aid. Some Model Intelligence categories are derived from index fields or name keywords and should be disclosed as classifications rather than provider guarantees.
Availability and maturity
Several status layers can coexist:
- Documentation maturity comes from the locked manifest and remains under review.
- Product maturity is shown by the owning surface; the Gateway currently identifies itself as beta, and console metadata allows live, preview, mock, or setup-required states.
- Catalog status uses
catalog-only,provider-configured,runnable,unsupported-modality, andmissing-key. - Data completeness is represented by present or missing fields, source evidence, extraction confidence, notes, and Model Intelligence quality flags.
Do not compress these into one “available” badge in prose. A runnable model on a beta surface is not contradictory; the values describe different layers.
Dynamic fields deserve the same care. Prices, latency, throughput, context windows, output limits, benchmark results, provider availability, and profile counts can change. Documentation should explain how to read them rather than hardcode them.
Catalog status and product maturity answer different questions. Catalog status describes the current model/provider overlay; maturity describes the product or documentation posture.
Use catalog-only, provider-configured, runnable, unsupported-modality, and missing-key exactly. Keep Gateway beta and public-preview language visible where relevant, even though the recorded maturity remains ga pending review.
Where to compare models
Use Model Library when the comparison is operational. It can search model records, filter by capability family, provider, status, and attributes, sort results, change visible columns, and inspect a selected model. It also links toward Gateway actions where supported.
Use Model Intelligence when the comparison is analytical. Profiles can include benchmark sections, technical specifications, pricing and context information, comparisons, charts, summary cards, FAQs, provider data, SEO data, and quality flags. Unsupported or empty chart types can be skipped.
A disciplined comparison follows this order:
- Define the workload and required modality.
- Identify candidates using capability and research evidence.
- Remove candidates that do not meet status, provider, context, or output requirements.
- Compare cost, latency, throughput, and benchmark evidence without treating missing values as zero.
- Test the remaining candidates with representative work.
- Preserve the selected model, provider, date, visible status, and decision rationale.
The correct result is often a shortlist rather than a universal winner. Model choice should remain tied to the workload and the evidence available when the decision was made.
Use Model Library when you need fields, filters, provider status, and a path toward the playground. Use Model Intelligence when you need normalized profiles, benchmark views, provider pages, charts, or leaderboards.
Compare multiple dimensions and note missing data. Do not hardcode current counts, prices, or rankings into evergreen guidance.
A two-surface review
Begin with Model Intelligence when the question is “which candidates appear promising?” Review populated benchmarks, specifications, charts, comparisons, source coverage, and quality flags. Create a shortlist and note why each candidate remains.
Then open Model Library and ask “which candidates can the current environment evaluate?” Match exact identifiers where possible, check provider and status, and review context, output, price, latency, throughput, and notes. A candidate that cannot be mapped confidently should remain unresolved rather than being treated as runnable.
After a representative test, return to the research record. Compare observed performance with the earlier hypothesis and preserve any disagreement. This closes the loop between normalized evidence and actual workload behavior without claiming that one surface is authoritative for every question.
When no profile exists
A catalog model can be operationally useful even when Model Intelligence has no complete profile. In that case, base the decision on verified catalog fields, provider state, source notes, and representative testing. Do not create benchmark or architecture claims to fill the research gap.
The reverse can also occur: a normalized profile may exist without a current runnable route. Keep it in the research set and avoid describing the model as executable through Ethen until catalog and Gateway evidence supports that step.