Per-model drill-down — usage, reliability, quality, and cost-vs-quality frontier
The follow-up question to the Models table: everything about ONE model over the selected range. Backs the Model detail dashboard page reached by clicking a model row.
Quality figures are computed directly from evaluation_scores grouped by model, not through the llm_events↔evaluation_scores span join the Cost vs Quality page uses — there is no fan-out to correct for when both sides are grouped by model directly.
frontier.points lists every OTHER model called in the project over the same range with its own cost and quality, each flagged cheaper against this model and carrying a qualityDelta (null when either side has no quality score yet) — the data behind “should I switch this workload?”.
Returns found: false with empty panels (200, not 404) for a model with zero calls in range, rather than erroring — a model can be renamed, retired, or simply unused in the chosen window.
Authenticated with a dashboard session (browser cookie), not x-api-key, and requires the dashboard:read permission.
Path Parameters
Project id.
Model id exactly as recorded on llm_events.model (e.g. gpt-5.6-luna, claude-opus-5). URL-encode the segment — model ids commonly contain dots and sometimes slashes (provider/model).
Query Parameters
7d, 30d, 90d Response
Model detail, or an empty found:false shell if the model had zero calls in range.
Response of GET /v1/projects/{id}/models/{model}.
false when this model had zero calls in the selected range — every other field below is then null/empty rather than the request erroring.
One row per day with at least one call, ascending.

