Repository navigation
[FEATURE]: Design V2 per-model tool filtering #34491
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Design how V2 controls tool availability per model/provider.
This is intentionally a placeholder/design issue that needs follow-up.
Context from the V2 beta discussion:
- Some models should not receive every tool.
- Example concern: GPT receiving edit, patch, and write tools simultaneously when model-specific prompting/tooling may want a narrower set.
- The old model-specific transform logic should become a cleaner plugin/hook/materialization mechanism.
Expected scope:
- Define whether filtering is configured by model, provider, agent, plugin, or request hook.
- Decide precedence when multiple plugins/configs affect the tool list.
- Ensure TUI/client can understand unavailable tools if needed.
- Add follow-up implementation tasks after the design is clear.
Activity
github-actions commentedon Jun 29, 2026
This issue might be a duplicate of existing issues. Please check:
PreToolBuild/PostToolBuildhooks for runtime manipulation of the tool list before it is sent to the LLM — closely related to the per-model tool filtering design described here.rekram1-node commentedon Jun 30, 2026
Shipped a band-aid fix in #34558 (merged):
ToolRegistry.materializenow takes the resolved model and gates the edit-tool family the way V1 did — OpenAI/GPT models getapply_patch, every other model getsedit/write. This unblocks the immediate concern (GPT no longer receives edit + write + apply_patch simultaneously).This is intentionally minimal and does not address the actual design ask in this issue, so keeping it open. Still needed for the proper solution:
materialize.Note: a plugin-based approach isn't feasible today — the V2
PluginHosthas notoolcapability and there's no model-aware turn-time hook (onlyaisdk, which sees the model but operates on the language-model object, not the tool roster). The proper design would need that infra first. The architecture already earmarksmaterializeas the filtering seam (tool/builtins.ts: "provider/model filtering belongs to a future materialization phase"), so the band-aid lives in the right place — it just needs to become driven by configuration rather than hardcoded.Related: #19942.
kitlangton commentedon Jul 4, 2026
#34558 fixed the immediate failure mode and added coverage: GPT/OpenAI models receive
apply_patch, while other models receiveedit/write.Keeping this open for the unresolved design: replace the hardcoded provider/model check with configurable policy, define composition and precedence across model/provider/agent/plugin inputs, and decide whether unavailable tools require client representation.
opencode-agent commentedon Jul 5, 2026
Superseded by #35408, which defines the shared V2 model-context hook and includes per-model tool filtering. The remaining precedence and client-representation questions have been carried into that tracker.