taodeng/ocp
1
0
Fork 0
mirror of https://github.com/dtzp555-max/ocp.git synced 2026-07-27 07:55:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(ocp-connect): revert the unknown-id fallback to 8192 — 32000 over-advertised

Browse Source 
The previous commit raised ocp-connect's unknown-id fallback from 8192 to 32000 on
the stated grounds that 32000 was "the LOWEST max_output_tokens.default in the CLI
2.1.220 registry". That is false, and the change it justified made this PR violate
its own thesis.

Pairing-free enumeration of the compiled registry (17 occurrences, no grep-window
artifacts):

    7 max_output_tokens:{default:64000,upper:128000}
    5 max_output_tokens:{default:32000,upper:64000}
    2 max_output_tokens:{default:8192,upper:8192}
    2 max_output_tokens:{default:32000,upper:32000}
    1 max_output_tokens:{default:32000,upper:128000}

    distinct defaults: 8192 / 32000 / 64000     GLOBAL MINIMUM: 8192

The floor is 8192, held by claude-3-5-haiku and claude-3-5-sonnet — and those are
exactly the ids that reach the fallback, since "claude-3-5-*" matches none of the
family prefixes. So the raise over-advertised the only two real models the branch
serves, by 4x, in a PR whose entire claim is that advertised metadata should be true.

Verified by exercising the real classifier (verbatim source slice, not a replica):

    claude-3-5-haiku            8192  FALLBACK   registry 8192   exact
    claude-3-5-sonnet           8192  FALLBACK   registry 8192   exact
    claude-opus-5              64000  family     registry 64000  exact
    claude-sonnet-4-6          32000  family     registry 32000  exact
    claude-haiku-4-5-20251001  32000  family     registry 32000  exact
    claude-sonnet-5            32000  family     registry 64000  under (safe)

Also in this commit:

- The family table's comment said "FAMILY FLOOR of the CLI registry". It is the floor
  over each family's members CURRENTLY IN models.json, not over the registry family:
  claude-opus-4-0 / -4-5 are opus-family at 32000, so the opus row would over-advertise
  them 2x. Unreachable today (ocp-connect derives ids from /v1/models, i.e. models.json),
  but the comment now states the real scope and what to do if a legacy opus is added.

- The test table keyed haiku on "claude-haiku-4-5-20251001" while telling the reader to
  extract values id-anchored. That id has ZERO id-anchored hits: the registry record is
  id:"claude-haiku-4-5" and the dated string appears only as its provider_ids.first_party
  (10 bare-string hits). Following the instruction on that row returns nothing, which is
  precisely what pushes a reader back to the bare-string search this test exists to
  prevent. The row now carries the registry id.

Reviewer credit: the reviewer that found this also retracted its own earlier finding,
which is what produced the 32000 fallback in the first place. Both directions verified
independently here before acting.

server.mjs: unchanged by this commit (ALIGNMENT.md requires no cli.js citation).
Suite: 462 passed, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gbqUZ8HfBZpjjbzQ85oH8
This commit is contained in:
taodeng
2026-07-27 12:16:01 +10:00
co-authored by Claude Opus 5
parent 1e9d3e89d8
commit cb87b82935
3 changed files with 27 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+1 -1
View File
@@ -4,7 +4,7 @@
### Changed
- **`maxTokens` now matches the CLI registry instead of a uniform 16384 (#195).** Every Opus entry and `claude-sonnet-5` go to **64000**, `claude-sonnet-4-6` and `claude-haiku-4-5` to **32000** — the `max_output_tokens.default` each model declares in the compiled CLI 2.1.220 registry. This corrects **advertised metadata only**: `models.json` is the SPOT (ADR 0003) and every value in it should be the truth about the model. **It changes nothing about how OCP behaves.** OCP never enforces `maxTokens` — `buildCliArgs` passes no output-token flag to the CLI at all — and OpenClaw addresses a local OCP over `openai-completions`, whose request field (`max_completion_tokens`) appears nowhere in this repo. The value is consumed only by clients that choose to honour it, via `setup.mjs` / `scripts/sync-openclaw.mjs` / `ocp-connect`. **Expect no change in answer length or quota burn.** `ocp-connect`'s independent family table moves to the family floor (opus 64000, sonnet 32000, haiku 32000) since prefixes cannot distinguish versions.
- **`maxTokens` now matches the CLI registry instead of a uniform 16384 (#195).** Every Opus entry and `claude-sonnet-5` go to **64000**, `claude-sonnet-4-6` and `claude-haiku-4-5` to **32000** — the `max_output_tokens.default` each model declares in the compiled CLI 2.1.220 registry. This corrects **advertised metadata only**: `models.json` is the SPOT (ADR 0003) and every value in it should be the truth about the model. **It changes nothing about how OCP behaves.** OCP never enforces `maxTokens` — `buildCliArgs` passes no output-token flag to the CLI at all — and OpenClaw addresses a local OCP over `openai-completions`, whose request field (`max_completion_tokens`) appears nowhere in this repo. The value is consumed only by clients that choose to honour it, via `setup.mjs` / `scripts/sync-openclaw.mjs` / `ocp-connect`. **Expect no change in answer length or quota burn.** `ocp-connect`'s independent family table moves to the floor over each family's current `models.json` members (opus 64000, sonnet 32000, haiku 32000), since prefixes cannot distinguish versions. Its unknown-id fallback stays at **8192** — the registry's global minimum, held by `claude-3-5-haiku` and `claude-3-5-sonnet`, which are the only real ids that reach it (`claude-3-5-*` matches no family prefix).
## v3.25.0 — 2026-07-27