Model detail pages
Read Model Library and Model Intelligence detail pages, interpret their fields, and move to supported model-use surfaces carefully.
Model detail pages
Model detail pages turn a model identifier or normalized slug into a focused view. Use them after narrowing the catalog or research index and before relying on a model for a task. Ethen currently has verified Model Intelligence dynamic profile routes and implementation evidence for Model Library provider/model routes, but route-map approval and data completeness must still be respected.
Overview
A detail page should identify which system produced it.
Model Intelligence profile pages use a dynamic route under /model-intelligence/models/[slug]. Static parameters are generated from normalized model profiles. The page can render profile metadata, benchmark sections, technical specifications, pricing, context, comparisons, charts, summary cards, FAQs, provider data, quality flags, and SEO information when present.
Model Library detail pages are linked from the Gateway explorer using provider and model information. The implementation includes provider-level and provider/model dynamic routes together with a composer-oriented detail surface. Because route maps can lag implementation, user-facing links must follow the approved route inventory in effect for the batch.
A detail page is only as complete as its source record. Missing enrichment should remain absent or clearly unavailable.
Ethen currently has two detail-page patterns. Model Library detail pages combine gateway catalog status, provider data, a composer or playground area, metrics, related models, and FAQs. Model Intelligence detail pages render normalized research bundles.
The products answer different questions. Model Library emphasizes current gateway-oriented status and actions; Model Intelligence emphasizes evidence, benchmarks, comparisons, charts, and normalized content.
Route identity
Preserve the route family when discussing a detail page. A Model Intelligence slug identifies a normalized research profile, while a Model Library provider/model route identifies an operationally oriented detail surface. Similar titles do not make the pages interchangeable.
When linking is not approved by the active route map, name the page concept without publishing the deep link. This keeps documentation aligned with implementation review rather than with a guessed URL pattern.
Capabilities
Capability information can come from the gateway catalog, normalized profile data, or the detail-page presentation layer. Verified capability families include text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown.
Read capabilities in context:
- confirm the exact model ID or slug;
- identify the provider;
- distinguish broad family from detailed modality support;
- inspect capability tags or notes when available;
- check current status before moving toward execution.
A model can have multiple relevant capabilities. That does not imply every route supports every combination of inputs and outputs. The selected provider and runtime path remain part of the capability check.
The composer on a Model Library detail surface can provide a path toward using the model where supported. Its presence should not be described as proof that the model is runnable; verify the status and configuration shown by the page.
A detail page can show the model’s capability family and capability tags. Model Library uses verified families from the gateway catalog; Model Intelligence can add model type and normalized profile context.
Capability labels are classification evidence, not a guarantee that every input or output variation is supported. Check runtime status and product-specific requirements before use.
Benchmarks
Model Intelligence profiles can include benchmark data and charts. Benchmarks are evidence about defined tests, not a general guarantee of quality.
On a detail page, check:
- which benchmark or metric is named;
- whether the value is present or missing;
- whether the profile exposes source or quality information;
- whether a composite or derived verdict is being shown;
- whether the workload resembles the test being summarized.
The adapter can group chart material into intelligence and quality, speed and throughput, latency and response time, context/cost/pricing, and architecture/scale. Unsupported or empty chart types may be skipped. A missing chart does not mean the model scored zero.
When comparing two detail pages, compare like with like. Different benchmark coverage can make one page look stronger simply because it has more populated fields.
Model Intelligence profiles can render benchmark-oriented charts, summary cards, comparisons, quality flags, and FAQs when the normalized bundle contains them. Unsupported or empty charts can be skipped.
A missing chart is not a zero score. Derived verdicts and routing suggestions are presentation logic and should be treated as evidence-informed guidance.
Pricing and context
Detail pages may represent input price, output price, cache read or write price, web-search price, context window, maximum output, latency, and throughput. These values are dynamic and can be incomplete.
Use a field only after confirming:
| Check | Reason |
|---|---|
| Unit and direction | Input and output prices are not interchangeable |
| Provider association | The same model name may have different provider records |
| Presence | Missing values are unavailable, not zero |
| Date or current source | Pricing and limits can change |
| Workload relevance | A large context window may not benefit a short task |
Do not copy current numeric values into evergreen documentation. The detail page should remain the current source for the record.
Model Library detail pages can expose context window, output limit, latency, throughput, and multiple price fields when present. Model Intelligence can organize context, cost, pricing, latency, speed, and architecture sections.
Values can be missing or change. Verify current units and provider terms before making cost or capacity commitments.
Provider availability
Provider availability should be interpreted through the verified status categories:
catalog-only;provider-configured;runnable;unsupported-modality;missing-key.
The provider name indicates association, while status indicates the current operational condition. Neither establishes regional or account-wide access.
A provider page can group models and summarize provider-related information, but it should not be treated as a service commitment. Check the selected model’s own record, current credentials, and requested modality.
If a detail page and the catalog appear inconsistent, preserve both observations with the date and source. Dynamic data may have changed, or the normalized research profile may not use the same update path as the gateway catalog.
The Model Library pattern shows catalog status and provider health details, while Model Intelligence provider views group normalized profiles by provider.
Catalog-only, provider-configured, runnable, missing-key, and unsupported-modality are distinct. Provider presence is not equivalent to account or regional availability.
Using the model
Move from a detail page to use through a controlled sequence:
- Confirm the exact model and provider.
- Verify capability and modality fit.
- Check status and credential requirements.
- Review context, output, cost, latency, throughput, and quality evidence needed for the workload.
- Use an approved Gateway or console route.
- Start with a bounded read-only task.
- Record the selected model, status, date, and observed result.
A detail page may include related models or FAQs. Treat those as discovery aids. A related model still requires its own status and evidence review, and an FAQ answer should not override current runtime state.
If the page lacks data needed for a decision, return to Model Library or Model Intelligence rather than inferring the value. The purpose of the detail page is to concentrate available evidence, not to conceal gaps.
Use the product action that matches the evidence. Copy the exact model ID, open the approved playground when appropriate, or continue research in Model Intelligence.
The current product now implements Model Library provider and model routes, but the approved documentation route list still marks those patterns for verification. Keep generated links on the approved index routes until the map is updated.
Profile completeness review
Before relying on a detail page, mark each decision-relevant section as populated, missing, or not applicable. A model selected for a large-document task may need context, output, pricing, latency, and quality evidence. A coding task may prioritize benchmark and capability information. A media task needs exact modality support.
This completeness review prevents a visually rich page from being mistaken for a complete record. Summary cards and charts can occupy substantial space while a crucial provider or output field remains absent.
Related models
Related-model sections support discovery. They do not establish that the related record is a drop-in replacement. Open the related page and compare exact identity, provider, capability, context, output, status, price, and research coverage.
If a related model is proposed as fallback, document the changed constraints. A family relationship or similar name does not guarantee compatible behavior or data handling.
FAQ boundaries
FAQs can explain recurring questions about a profile, but answers are only as strong as the normalized data and implementation that generated them. A profile FAQ should not override current catalog status, provider configuration, legal terms, or product maturity.
When an FAQ contains a broad recommendation, trace it back to the underlying profile fields. If that evidence is incomplete, treat the answer as orientation rather than a final decision.
Composer-oriented detail surfaces
A composer on a Model Library detail route can make testing convenient, but the test still needs a verified model/provider selection and bounded context. Inspect any status warning before submission. If the composer changes the selected route or falls back, the evidence should identify the model that actually responded.
Do not treat a successful response as proof that every field on the detail page is current. Runtime success and research completeness remain separate.
Reporting a detail-page problem
Include the exact route, provider, model identifier or normalized slug, missing or conflicting section, and observation date. Distinguish a 404 or route problem from a profile-data gap and from a Gateway execution problem. Those failures belong to different owners and should not be collapsed into “the model page is broken.”