Model Library overview

Model Library is Ethen’s read-only gateway catalog and provider-status overlay. Use it when you need to find a model record, understand current operational status, inspect available fields, or move toward a supported Gateway path. The surface represents catalog truth; it does not guarantee that every model is runnable, enriched, or available to every account.

What the Model Library contains

The direct /model-library route loads gateway catalog models and provider rollups. Catalog records can include:

• model ID, provider, and model name;
• capability family and capability tags;
• status;
• context window and maximum output tokens;
• latency and throughput;
• input and output pricing;
• cache read and cache write pricing;
• web-search pricing;
• source files, extraction confidence, notes, and other evidence.

A field appears only when the catalog data supplies it. Blank pricing, latency, throughput, context, or output values are unavailable rather than zero.

The verified status categories are:

These values are more useful when paired with the selected model, provider, capability, and task.

Model Library is implemented as a read-only catalog of gateway models and provider overlays. Records can include identity, capability, context, output limit, latency, throughput, prices, source evidence, extraction confidence, notes, and runtime status.

A blank field is unavailable. The surface does not turn missing data into zero, and documentation should preserve that distinction.

Provider rollups

Provider rollups summarize groups of catalog records and can reveal how many entries share a provider or status pattern in the current dataset. Use them to navigate, not to make claims about permanent provider coverage. Open the individual model record before deciding whether a specific capability, price, context value, or status applies.

A rollup can change as records are added, removed, or reclassified. Record-level evidence remains the appropriate basis for a model decision.

Browse models

Browse the library when you do not yet know the exact model ID. The explorer can display a filtered list and maintain a selected model for inspection. Capability-family tabs provide a broad starting point, and provider or status filters can narrow the result.

A good browsing sequence is:

1. Choose the capability family that matches the workload.
2. Limit the view to providers you can evaluate or configure.
3. Inspect status before comparing secondary fields.
4. Sort by the field most relevant to the decision.
5. Select a record and review the inspector details and source evidence.
6. Copy the model ID only after confirming the provider and record.

Avoid using a display name as the only identifier. Similar names may belong to different providers, versions, or records.

The page loads the current gateway catalog and provider rollups, then renders searchable model rows with a selected-model inspector.

Rows expose model and provider information, status, actions, and configurable columns. The inspector gives a focused view of the selected record and can show source evidence when available.

Filter and sort

The inspected explorer verifies text search, capability-family tabs, provider filtering, status or attribute filtering, selectable columns, and sorting by name, provider, status, or context window. Search state is synchronized to URL parameters including q, family, provider, status, and sort.

URL state is useful for reproducing a view, but it does not freeze the underlying catalog. Opening the same URL later may return different records if catalog data or statuses have changed.

Columns should be chosen according to the question. For access readiness, show provider, capability, and status. For model-fit analysis, add context, output, latency, throughput, or pricing when available. For provenance review, inspect source files, extraction confidence, and notes.

The explorer renders filtered records in a scrollable region. The inspected implementation does not expose pagination state or controls, so documentation must not claim a page size.

Capability tabs, provider filtering, attribute filtering, text search, and sorting help narrow the catalog.

Verified attribute filters include runnable, provider configured, missing key, catalog only, unsupported modality, default route, has pricing, has context, and high confidence. Verified sort choices are name, provider, status, and context window.

Open a model page

Selecting a record opens a model inspector and can expose links toward model detail, provider views, the Gateway playground, documentation, or API-key areas, depending on the current UI and approved route map.

Two model-page families must remain distinct:

• Model Library provider and model detail routes are generated by the explorer, but route verification must match the active route map.
• Model Intelligence has a verified dynamic model-profile route built from normalized slugs.

A detail page may show a composer-oriented surface, capabilities, runtime information, related models, FAQs, or other enriched content when implemented. Do not assume every catalog row has all sections or that a profile slug can be derived from the catalog ID.

Before following a deep link, preserve the model ID and provider from the library so you can verify that the destination represents the intended record.

Model Library rows link to provider/model detail paths, and the current repository contains direct provider and model route implementations. The approved documentation route list has not yet been updated for those patterns.

Use the row action inside the product, but keep published documentation links limited to approved routes until the approved documentation route list is revised. Model Intelligence model profiles use a separately verified dynamic slug route.

Move from research to use

Model Library is a checkpoint between research and execution. Use this handoff:

1. Confirm the model’s capability family and current status.
2. Review provider configuration and credential requirements.
3. Check context, output, pricing, latency, throughput, and evidence fields that matter to the workload.
4. Use Model Intelligence for benchmarks or broader comparison when a normalized profile exists.
5. Move to Gateway or the console only through an approved route.
6. Test a small read-only task before relying on the model for sensitive or state-changing work.

A library record does not select the model for you. It supplies operational evidence for a decision. The final choice should include task fit, research quality, status, risk, and observed performance.

If a model is blocked, use the status to choose the next action. Resolve a missing key through the approved credential path, choose a compatible modality when support is absent, or select another candidate when the provider path is not ready. Do not disguise the blockage with an undocumented automatic fallback.

After identifying a candidate, inspect status truth and source evidence, compare it in Model Intelligence when a profile exists, and move to the approved AI Gateway playground only when the model and provider state support the intended path.

Copy the exact model ID rather than guessing an alias. Confirm keys and configuration before production use. A successful playground request does not establish permanent availability or pricing.

Reading the selected-model inspector

The inspector is the point where a broad result list becomes one record. Confirm the exact ID, provider, capability family, and status before copying the identifier or following an action link. Review evidence fields and notes when they are present, especially when a value was extracted from source files rather than entered as a permanent product fact.

If the inspector exposes a field not shown in the table, treat the inspector as additional detail for the selected record, not as a global property. If the list and inspector disagree, preserve the observation and refresh or reselect the record before proceeding.

Column sets for common tasks

For a readiness review, show model name, provider, capability, and status. For a capacity review, add context and maximum output. For an experience review, add latency and throughput. For a budget review, show the relevant price fields and provider. For a provenance review, inspect sources, confidence, and notes.

A focused column set reduces the chance of comparing unrelated fields. It also makes missing values visible. Do not replace absent data with a placeholder that looks numeric.

Catalog snapshots and decision records

The library is dynamic. A saved filter URL can reproduce query state, but it does not preserve the exact records or statuses from the day of a decision. When reproducibility matters, record the selected model ID, provider, visible status, date, relevant populated fields, and source notes.

This decision record should be stored with the project or artifact that depends on it. If the status later changes, the earlier choice remains understandable without pretending that catalog data is immutable.

Safe transitions to Gateway

Follow only approved Gateway links and recheck the selected model after the transition. A playground or documentation page may use a different selection context than Model Library. Confirm the provider and credential state again before a run.

When the transition is blocked, preserve the status. A missing key requires configuration; unsupported modality requires a different route; catalog-only requires a supported access path. These are operational outcomes, not search failures.