[FEATURE]: Apply the same cap / pagination treatment to /provider endpoint #35897

Series context (read this first)

This is the third in a series of three issues I'm filing about the long-running-deployment experience in opencode. Filing them separately so each one is reviewable on its own, but they share a story:

1. [FEATURE]: Make SQLite PRAGMA settings configurable for long-running deployments #35892 — Make SQLite PRAGMA settings configurable for long-running deployments — the underlying DB connection defaults become painful once the install has been running for a few months. The big symptom is the event table growing to ~1 GB / ~170k rows, at which point the default 8 MB cache is useless and busy_timeout=0 actively hurts under write contention.

2. [FEATURE]: Server-side cap + cursor pagination for /session/[id]/message to make long sessions loadable #35895 — Server-side cap + cursor pagination for /session/[id]/message — once the DB is fat, the next symptom is the chat history endpoint returning 1.93 MB raw / 1.11 MB gzipped because the frontend hard-codes limit=200 and the server has no ceiling. 30-90 s on cellular.

3. This issue (/provider) — same shape of problem on a different endpoint. Both [FEATURE]: Make SQLite PRAGMA settings configurable for long-running deployments #35892 and [FEATURE]: Server-side cap + cursor pagination for /session/[id]/message to make long sessions loadable #35895 feed into this: a long-running install that hits feat: compact and other improvements #1 will have accumulated enough providers/messages that /provider also hurts, and the same architectural fix (server-side cap + warning header) applies.

The three are deliberately scoped so each can be merged independently. If maintainers prefer one big PR I can roll them up.

TL;DR

GET /provider?directory=... returns the full model catalog for every supported provider in one shot. On my install: 3.88 MB raw / 235 KB gzipped — single endpoint, single request. On cellular, 5-15 s of pure network for the first response after a cache miss.

What's in there

Looking at the response, the body is a per-provider-per-model list of:

• model ID, name, display name
• capabilities (input/output modalities, attachment support)
• token limits (context / output)
• thinking settings, provider-specific options

It's not pathological data per row, but the count is the issue: opencode ships with many providers configured, and a fresh install may have several hundred model entries. 3.88 MB for a "list available models" response is the kind of thing that doesn't feel like a problem until you load it over a flaky connection, and then it suddenly is the problem.

What I'd like

Same shape as the /session/[id]/message issue (#2):

1. Server-side cap

{
  "server": {
    "providerMaxLimit": 1000,
    "providerDefaultLimit": 50
  }
}

• providerMaxLimit default 1000 (way more than anyone needs)
• providerDefaultLimit default 50
• Same Warning: 199 - "limit clamped to N" header on clamp

2. Cursor pagination (separate follow-up)

GET /provider?cursor=<modelID>&limit=50

Cursor is modelID (alphabetical sort) since models are listed by id.

Why this is a separate issue from the /message one

• Different endpoint, different schema
• The size problem is less acute (235 KB gzipped vs 1.1 MB)
• The fix is the same pattern, but I want them independently reviewable

Reproduction

Hit /provider?directory=<any_dir> and look at the size:

curl -sk -o /tmp/p.out "https://127.0.0.1:6022/provider?directory=$HOME" && ls -la /tmp/p.out

On a typical multi-provider install that's 2-4 MB. On cellular: painful.

Maybe a smaller-scoped version?

If maintainers want to keep this scoped, the minimum is just clamping: add providerDefaultLimit=50 + providerMaxLimit=1000 with a Warning header. That alone brings the worst case from 3.88 MB to ~150 KB without touching the frontend.

If that's all that gets merged, I'd be happy. Pagination can come later.