OpenRouter — Model directory

Browse & DiscoverySee it liveopenrouter.ai

An enormous filter surface — 13+ collapsible facet sections at a fixed 240px — sits permanently open on the left, and the payoff is one pipe-separated meta line per card that answers author, recency and three price points without opening anything.

OpenRouter — Model directory — captured interface — Page excerpt · scroll inside to explore

Source capture · 2026-08-01Open full image ↗

Why this pattern works

The pipe-separated meta line — 'by author | date | context length | input price | output price' — as a way to pack five hard numbers into one scannable row per result card. Pair it with the modality tab strip (All, Text 337, Image 38, Embeddings 31...) as a lighter, always-visible alternative to burying the single most common filter inside the sidebar.

Design notes

Surface: Model directory / browse list, logged out
Navigation: Two tiers: a top bar (logo, search, primary nav links, Sign Up) and a left facet sidebar that functions as the real navigation — 13+ collapsible sections stacked vertically, only the top one expanded by default.
Layout: Fixed ~240px left sidebar with its own scroll, fluid main column. Inside the main column, a secondary horizontal facet — the modality tab strip — sits above a vertical stack of full-width bordered result cards.
Density: Tight sidebar rows (~36px) built for scanning many filters fast; roomier result cards (~110px+, 2-3 lines of description each) built for reading. The two densities coexist without feeling mismatched because the sidebar stays monochrome.
Color: Almost entirely grayscale — white surfaces, grey borders and meta text, black headings. The one accent color (violet) is spent only on the logo mark and the Sign Up button; category tag pills use muted low-saturation dot colors and stay small.
Type: One sans. Model names are the largest text on a card (~16px semibold); everything else — description, meta line, sidebar labels — sits at 13-14px regular. Hierarchy comes from the meta line's pipe structure, not from type size.
Pattern: A five-field pipe-separated meta line per result card (author | date | context | input price | output price) that turns a plain list row into a comparison table without ever drawing a grid.
States: Logged out: Sign Up button top right, no empty or loading state visible — the list is fully populated with live pricing, token counts and recency data on every card.
Don't: Don't let the sidebar's 13+ sections all render expanded at once. The pattern only works because most stay collapsed to a single row — expand them all and the 240px column becomes longer than the result list it's supposed to filter.

Make it your own

Turn this reference into a useful brief for your project. Copy it into the AI tool you already use.

Your project

Use withI want to

Tech stack

Add constraints

What should the tool respect?

Preview & edit prompt

Prompt text

# My project
[Describe the product, audience, and screen you want to improve]

Stack: Use the existing project stack
Task: Implement the interface and verify the result in the existing project.

## Tool guidance (Any AI tool)
Use available project tools to inspect, implement, and test. State any unavailable capabilities.

# Design reference: OpenRouter — Model directory
Source: https://openrouter.ai/models
Swipefile reference: https://swipefile.design/ref/openrouter-models/
Captured: 2026-08-01. This is a dated reference, not a claim about the current live product.
Capture scope: a page excerpt. Do not infer unseen sections or interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Model directory / browse list, logged out
- nav: Two tiers: a top bar (logo, search, primary nav links, Sign Up) and a left facet sidebar that functions as the real navigation — 13+ collapsible sections stacked vertically, only the top one expanded by default.
- layout: Fixed ~240px left sidebar with its own scroll, fluid main column. Inside the main column, a secondary horizontal facet — the modality tab strip — sits above a vertical stack of full-width bordered result cards.
- density: Tight sidebar rows (~36px) built for scanning many filters fast; roomier result cards (~110px+, 2-3 lines of description each) built for reading. The two densities coexist without feeling mismatched because the sidebar stays monochrome.
- color: Almost entirely grayscale — white surfaces, grey borders and meta text, black headings. The one accent color (violet) is spent only on the logo mark and the Sign Up button; category tag pills use muted low-saturation dot colors and stay small.
- typography: One sans. Model names are the largest text on a card (~16px semibold); everything else — description, meta line, sidebar labels — sits at 13-14px regular. Hierarchy comes from the meta line's pipe structure, not from type size.
- pattern: A five-field pipe-separated meta line per result card (author | date | context | input price | output price) that turns a plain list row into a comparison table without ever drawing a grid.
- states: Logged out: Sign Up button top right, no empty or loading state visible — the list is fully populated with live pricing, token counts and recency data on every card.
- dont: Don't let the sidebar's 13+ sections all render expanded at once. The pattern only works because most stay collapsed to a single row — expand them all and the 240px column becomes longer than the result list it's supposed to filter.

Useful for: The pipe-separated meta line — 'by author | date | context length | input price | output price' — as a way to pack five hard numbers into one scannable row per result card. Pair it with the modality tab strip (All, Text 337, Image 38, Embeddings 31...) as a lighter, always-visible alternative to burying the single most common filter inside the sidebar.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

Assembled in your browser. No API key or AI request needed. Changing the fields refreshes the preview.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

OpenRouter — Model directory

Make it your own

Keep exploring

Help improve Swipefile?