feat(bench): fold typed registry capability fields into _model_caps - #1826
Open
thinmintdev wants to merge 1 commit into
Open
feat(bench): fold typed registry capability fields into _model_caps#1826thinmintdev wants to merge 1 commit into
thinmintdev wants to merge 1 commit into
Conversation
_model_caps matched only the freeform `capabilities`/`tags` lists, which are unmaintained in practice: across 49 installed models on a live box, only a handful carry a semantic label. That set stamps `identity.model.caps` onto every benchmark record, which is where the public leaderboard's capability pills come from — so a model whose capabilities are recorded in the TYPED fields showed no pill at all (#1823). The typed fields are the surface an operator actually edits via PATCH /api/models, so a typed edit should reach the roster without also hand-editing a parallel string list. Folded in following the existing defaults.mtp precedent: - vision <- carrying an mmproj, unless defaults.vision is explicitly False. registry/model.py documents defaults.vision=None as AUTO ("the sidecar loads whenever the model carries one") and True as an explicit no-op affirmation, so the projector — not the flag — is the real signal. - tool-calling <- capability_flags.tool_calling is True - reasoning <- defaults.enable_thinking is True Only unambiguous positives fold in. Every flag is tri-state and None means "unset / decided elsewhere", never "lacks the capability", so None and False both add nothing rather than asserting an absence. Safe for benchmark selection: suites match with caps_any, so a wider set can only make a model match more selectors, never fewer. The shipped suites select on ["chat", "coder"], which none of these labels touch. This is plumbing, not a fix for the coverage gap itself — on today's data it recovers exactly one model, because the typed fields are nearly as empty as the freeform ones (tool_calling set on 1 of 49, enable_thinking on 1). What it buys is that labelling from here on lands in one place and propagates. Note that caps are captured into records at run time, so the leaderboard only reflects a labelling pass after the affected models are re-benchmarked. Refs #1823 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item 3 of #1823.
Why
_model_capsmatched only the freeformcapabilities/tagslists. Those are unmaintained in practice — across 49 installed models on a live box, only a handful carry a semantic label. That set stampsidentity.model.capsonto every benchmark record, which is where the public leaderboard's capability pills come from, so a model whose capabilities live in the typed fields showed no pill at all.The typed fields are the surface an operator actually edits (
PATCH /api/modelsacceptsdefaultsandcapability_flags), so a typed edit should reach the roster without also hand-editing a parallel string list.What
Folded in following the existing
defaults.mtpprecedent:visionmmproj, unlessdefaults.visionis explicitlyFalsetool-callingcapability_flags.tool_calling is Truereasoningdefaults.enable_thinking is Truevisionkeys off the projector, not the flag, becauseregistry/model.pydocumentsdefaults.vision=Noneas AUTO — "the mmproj sidecar loads whenever the model carries one" — andTrueas "an explicit no-op affirmation". Sommprojpresence is the real signal and an explicitFalse(force-suppress) is the only thing that revokes it.Only unambiguous positives fold in. Every flag is tri-state and
Nonemeans "unset / decided elsewhere", never "lacks the capability" — soNoneandFalseboth add nothing rather than asserting an absence.Safety
Widening this set is safe for benchmark selection: suites match with
caps_any, so extra labels can only make a model match more selectors, never fewer. The shipped suites (roster.toml,smoke.toml) select on["chat", "coder"], which none of these labels touch. There's a test pinning thenarrow ⊆ wideproperty.Honest scope
This is plumbing, not a fix for the coverage gap itself. On today's data it recovers exactly one model, because the typed fields are nearly as empty as the freeform ones —
capability_flags.tool_callingis set on 1 of 49 models,defaults.enable_thinkingon 1, and the 6 with anmmprojalready carry a freeformvisionlabel. What it buys is that labelling from here on lands in one place and propagates automatically.Also worth knowing before anyone measures a labelling pass: caps are captured into records at run time, so the leaderboard only reflects new labels once the affected models are re-benchmarked.
Verification
pytest tests/bench tests/cli— 1113 passedruff check+ruff format --checkclean🤖 Generated with Claude Code