feat: reject parameter combinations providers won't accept - #170
Open
brunobuddy wants to merge 2 commits into
Open
feat: reject parameter combinations providers won't accept#170brunobuddy wants to merge 2 commits into
brunobuddy wants to merge 2 commits into
Conversation
The catalog records which parameter combinations providers reject, in each parameter's `applicability` rules. Nothing enforced them. parseParams said so in a comment: cross-parameter rules were "not yet enforced", so the data that distinguishes this catalog from a metadata list was only ever rendered on the site. Adds the engine: - checkApplicability reports supplied parameters that conflict with the rest of the request, with the parameters that caused each conflict. - isApplicable answers the same question for one parameter. - dropUnsupported strips everything a model won't accept and returns a payload safe to spread into a provider call, plus what it removed and why. Catalog-driven equivalent of LiteLLM's drop_params, extended to conditional conflicts. - resolveModelId maps a bare model slug or full id onto a catalog id, reporting ambiguity rather than guessing. - parseParams now enforces conflicts, after each value passes its own type and range check so a range error doesn't surface as a conflict. When a rule references a parameter the request omitted, evaluation falls back to that parameter's catalog default, since that is what the provider applies instead. So top_p alone is fine on Claude 3 Opus, which defaults temperature to 1, while top_p with temperature 0.5 is reported. checkValue moves to its own module, shared with parseParams rather than duplicated.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Jul 30, 2026
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
1 participant
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.
First of four. The endpoint, MCP server and agent skill all build on this, so it goes first on its own.
💭 Why
Each parameter in the catalog can carry
applicabilityrules describing when a provider accepts it. Nothing enforced them.parseParamssaid as much in a comment: cross-parameter rules were "not yet enforced".So the data that separates this catalog from a model-metadata list was display-only.
✨ What changed
checkApplicabilityreports supplied parameters that conflict with the rest of the request, naming what caused each conflict.isApplicableanswers the same for a single parameter.dropUnsupportedstrips what a model won't accept and returns a payload safe to spread into a provider call, plus what went and why.resolveModelIdmaps a bare slug or full id onto a catalog id, reporting ambiguity instead of guessing.parseParamsenforces conflicts, after per-value type and range checks pass.checkValuemoves to its own module instead of being duplicated.👤 For users
Catches what people currently hit as provider 400s:
top_pwith a non-defaulttemperatureon Anthropic, sampling knobs on reasoning models, a thinking budget without thinking enabled.dropUnsupportedis the catalog-driven equivalent of LiteLLM'sdrop_params, extended to conditional conflicts.📝 Notes
top_palone is fine on Claude 3 Opus (temperature defaults to 1);top_pwithtemperature: 0.5is reported.thinking.budget_tokensdefaults to 4096 and still only applies when thinking is enabled.dropUnsupportedconverges and never emits a request it would itself reject, which guards its fixed-point loop against non-termination.