chat: wip on model-specific tools #287666
Merged
Conversation
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
This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`. 1. This switches to `models?: LanguageModelChatSelector[];` to control enablement. definitely open to switching this out, but I think a synchronously-analyzable expression is important to retain the data flows in core without too many races. 2. The extension is able to define a tool at runtime via registerToolDefinition. This should let us have entirely service-driven tools from model providers without requiring a static definition for each one. We can also have model-specific variants of tools without a ton of package.json work for each variant of the tool (as initially proposed using `when` clauses) This then propagates that down into the tools service. Currently I have this as just compiling to a `when` expression once it reaches the main thread. Then, for the tools service, it takes an IContextKeyService in cases where tools should be enumerated, and the chat input sets the model keys in its scoped context key service. This allows the tools to be filtered correctly in the tool picker. I initially thought about allowing multiple definitions be registered for the same tool name/id for model-specific variants of tools but I realized that gets really gnarly and we already have a `toolReferenceName` that multiple tools can register into. Todo for tomorrow morning: - Tools don't make it to the ChatRequest yet, or something, still need to investigate - Need to make sure tools in prompts/models all work. For a first pass I think we can let prompts/modes reference all tools by toolReferenceName. - Validate that multiple tools actually can safely share a reference name (and do some priority ordering?) - General further validation - Some unit tests
📬 CODENOTIFYThe following users are being notified based on files changed in this PR: @bpaseroMatched files:
|
bhavyaus
reviewed
Jan 14, 2026
bhavyaus
approved these changes
Jan 14, 2026
connor4312
added a commit
to microsoft/vscode-copilot-chat
that referenced
this pull request
Jan 14, 2026
This PR goes with microsoft/vscode#287666 This allows the registration of tools that are scoped to specific language models. These tools can be registered at runtime with definitions derived from e.g. the server. I think we should adopt this and go away from the current `alternativeDefinitions` pattern which we have used previously. Example of having tools specific for GPT 4.1 vs 4o: ```ts ToolRegistry.registerModelSpecificTool( { name: 'gpt41_get_time', inputSchema: {}, description: 'Get the current date and time (4.1)', displayName: 'Get Time (GPT 4.1)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4.1' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2041 (GPT 4.1)')]); } } ); ToolRegistry.registerModelSpecificTool( { name: 'gpt4o_get_time', inputSchema: {}, description: 'Get the current date and time (4o)', displayName: 'Get Time (GPT 4o)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4o' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2040 (GPT 4o)')]); } } ); ```
github-merge-queue bot
pushed a commit
to microsoft/vscode-copilot-chat
that referenced
this pull request
Jan 22, 2026
* tools: add support for model-specific tool registration This PR goes with microsoft/vscode#287666 This allows the registration of tools that are scoped to specific language models. These tools can be registered at runtime with definitions derived from e.g. the server. I think we should adopt this and go away from the current `alternativeDefinitions` pattern which we have used previously. Example of having tools specific for GPT 4.1 vs 4o: ```ts ToolRegistry.registerModelSpecificTool( { name: 'gpt41_get_time', inputSchema: {}, description: 'Get the current date and time (4.1)', displayName: 'Get Time (GPT 4.1)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4.1' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2041 (GPT 4.1)')]); } } ); ToolRegistry.registerModelSpecificTool( { name: 'gpt4o_get_time', inputSchema: {}, description: 'Get the current date and time (4o)', displayName: 'Get Time (GPT 4o)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4o' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2040 (GPT 4o)')]); } } ); ``` * demo * fix * overrides * add overridesTool * fix inverted logic * test fixes and back compat * make memory tool model specific * fix tests and contribute memory to the vscode toolset * verison * fix unit tests * rm config * fix missing askquestions --------- Co-authored-by: bhavyaus <bhavyau@microsoft.com>
eleanorjboyd
pushed a commit
to eleanorjboyd/vscode-copilot-chat
that referenced
this pull request
Jan 23, 2026
* tools: add support for model-specific tool registration This PR goes with microsoft/vscode#287666 This allows the registration of tools that are scoped to specific language models. These tools can be registered at runtime with definitions derived from e.g. the server. I think we should adopt this and go away from the current `alternativeDefinitions` pattern which we have used previously. Example of having tools specific for GPT 4.1 vs 4o: ```ts ToolRegistry.registerModelSpecificTool( { name: 'gpt41_get_time', inputSchema: {}, description: 'Get the current date and time (4.1)', displayName: 'Get Time (GPT 4.1)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4.1' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2041 (GPT 4.1)')]); } } ); ToolRegistry.registerModelSpecificTool( { name: 'gpt4o_get_time', inputSchema: {}, description: 'Get the current date and time (4o)', displayName: 'Get Time (GPT 4o)', toolReferenceName: 'get_time', source: undefined, tags: [], models: [{ id: 'gpt-4o' }], }, class implements ICopilotTool<unknown> { invoke() { return new vscode.LanguageModelToolResult([new vscode.LanguageModelTextPart('Current year is 2040 (GPT 4o)')]); } } ); ``` * demo * fix * overrides * add overridesTool * fix inverted logic * test fixes and back compat * make memory tool model specific * fix tests and contribute memory to the vscode toolset * verison * fix unit tests * rm config * fix missing askquestions --------- Co-authored-by: bhavyaus <bhavyau@microsoft.com>
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.
This is a rethinking of the initial API proposed in
languageModelToolSupportsModel.d.ts.models?: LanguageModelChatSelector[];to control enablement. definitely open to switching this out, but I think a synchronously-analyzableexpression is important to retain the data flows in core without races.
whenclauses)This then propagates that down into the tools service. Currently I have this as just compiling to a
whenexpression once it reaches the main thread. Then, for the tools service, it takes an IContextKeyService in cases where tools should be enumerated, and the chat input sets the model keys in its scoped context key service. This allows the tools to be filtered correctly in the tool picker.I initially thought about allowing multiple definitions be registered for the same tool name/id for model-specific variants of tools but I realized that gets really gnarly and we already have a
toolReferenceNamethat multiple tools can register into.Todo for tomorrow morning:
let prompts/modes reference all tools by toolReferenceName.
some priority ordering?)