Problem

The compare page should make it easier to understand differences between models, providers, pricing, capabilities, and performance characteristics. The current experience can be improved with richer information and clearer display patterns.

Scope

Review and improve the compare page so it better supports side-by-side decision-making.

Areas to consider

Model metadata and lifecycle details.
Provider availability and routing support.
Pricing and cache pricing differences.
Context windows, modality support, and capability differences.
Benchmark and quality signals.
Better visual hierarchy for scanning large comparisons.

Acceptance criteria

Comparisons expose the most important differences clearly.
Pricing and capability differences are easy to scan.
The page remains responsive and usable with multiple models.
Empty or unavailable data states are clear.
Loading states and suspense boundaries do not disrupt comparison layout.

Activity

linear-code[bot]5mo ago

AI-102

opencode-agent[bot]5mo ago

Now I have a thorough understanding of the codebase. Here is my response:

We're super sorry about this issue you're facing! We'll have someone look at this as soon as possible.

Issue understanding

The compare page at `apps/web/src/app/(dashboard)/compare/page.tsx` has a solid component tree but needs UX improvements in information density and scannability. Key observations:

ComparisonTable (comparisonComponents/ComparisonTable.tsx) is the most information-dense section but is hidden behind a collapsed card with a fixed max-h-[800px] scroll container. The table already computes "best value" stars for pricing/latency/throughput/benchmarks but does not show cache pricing differences, routing/providers per model, or model lifecycle status prominently.
OverviewCard shows per-model cards with modalities/dates/context/license but uses a grid layout that can become hard to scan with 3-4 models — no visual comparison cues (best/worst, diff highlights).
PricingAnalysis has rich per-model stat cards + bar chart + meter table, but cache pricing (cached_input_token_price on Price type) is available in the data yet not surfaced in any comparison view.
AvailabilityComparison already exists and shows which API providers offer each model, but the data derivation relies on pricing provider IDs — no direct model → provider routing info.
GatewayUsageComparison shows 30-day token sparklines but the loading/empty state could be clearer for models with no gateway data.
The empty state (CompareDashboard line 231-335) and the not-found state are reasonable but could benefit from more guidance.
There is no capability diffing (e.g., highlighting that only model A supports web search, vision, or reasoning).
The loading.tsx skeleton is very basic — may cause layout shift when comparison sections mount.
getComparisonModelsCached already fetches benchmark_results, prices, subscription_plans per model — most data is available.

AI Agent Prompt (Copy/Paste)

Bug: The compare page at apps/web/src/app/(dashboard)/compare/page.tsx has poor information density and unclear comparison UX. Users need to easily scan differences in pricing (including cache pricing), model capabilities, benchmarks, provider availability, and lifecycle dates.

Goal: Improve the compare page without breaking existing functionality. Run `pnpm dev --filter @ai-stats/web` and `pnpm lint --filter @ai-stats/web` to verify.

Key areas to inspect and improve:
1. apps/web/src/components/(data)/compare/comparisonComponents/ComparisonTable.tsx — Already has "best value" stars. Add cache pricing rows, provider/routing availability column, and a better visual diff (color-coded best/worst). Remove the max-h-[800px] clamp or make it expandable.
2. apps/web/src/components/(data)/compare/comparisonComponents/OverviewCard.tsx — Add visual indicators for which model wins on context length, recency, license openness. Show "reasoning" and "web_access" capability chips.
3. apps/web/src/components/(data)/compare/comparisonComponents/pricingAnalysis/PricingAnalysis.tsx — Surface cache pricing (cached_input_token_price, cached_input_read_tokens, cached_input_write_tokens) as a row in the meter comparison table or a dedicated section. Add a "Cache savings" column.
4. apps/web/src/components/(data)/compare/comparisonComponents/AvailabilityComparison.tsx — Verify it shows per-model API providers correctly. Add routing support indicators if data exists (open_router_model_id).
5. apps/web/src/components/(data)/compare/ComparisonDisplay.tsx — Reorder/reorganize sections for better scan flow (e.g., overview first, then capability diffs, then pricing, then benchmarks).
6. apps/web/src/app/(dashboard)/compare/loading.tsx — Improve the skeleton to better match the comparison layout shape (per-model columns/sparkline placeholders).
7. apps/web/src/components/(data)/compare/CompareDashboard.tsx — Improve empty and error state copy, add a "share comparison" button.

Data model reference: ExtendedModel in packages/data/catalog/src/data/types.ts has benchmark_results, prices (with cached_input_token_price, api_provider_id, meter), subscription_plans, input/output_context_length, reasoning, web_access, input_types, output_types, status, release_date, deprecation_date, retirement_date.

Do not add new fetchers or API endpoints — all needed data is already available in comparisonData and usageByModel.

Clarifying Questions (Optional)

Should cache pricing be shown as absolute values or as a percentage savings vs. non-cache pricing?
For the loading skeleton, should it render per-model placeholder columns matching the actual comparison grid, or keep it simpler?

This is an automated response - a team member will follow up shortly.

opencode session | github run