Skip to content

Conversation

@roomote
Copy link
Contributor

@roomote roomote bot commented Jan 29, 2026

Summary

Re-applies the image support feature for VS Code LM API provider from PR #11065 that was reverted in PR #11068, with a fix for the @types/vscode version mismatch issue.

The Problem

The original PR upgraded @types/vscode from ^1.84.0 to ^1.106.0 in src/package.json. This caused a mismatch with the engines.vscode field which specifies ^1.84.0, resulting in pnpm vsix build failures.

The Solution

This PR keeps @types/vscode at ^1.84.0 in package.json (matching engines.vscode) while the pnpm-lock.yaml resolves to version 1.108.1 which provides the LanguageModelDataPart API needed for image support. This approach:

  • Maintains compatibility with VS Code 1.84.0+
  • Provides TypeScript types for the new LanguageModelDataPart API
  • Resolves the vsix build failure from the original PR

Changes

  • Re-apply convertImageToDataPart() for image-to-LanguageModelDataPart conversion
  • Re-apply checkModelSupportsImages() for model image capability detection
  • Re-apply useSelectedModel update to use models actual supportsImages capability
  • Re-apply comprehensive tests for image support
  • Update pnpm-lock.yaml to resolve @types/vscode ^1.84.0 to version 1.108.1

Testing

  • All 51 vscode-lm related tests pass
  • TypeScript type checking passes
  • Lint checks pass

Relates to #11064
Supersedes the reverted #11065


Important

Re-applies image support for VS Code LM API with a fix for @types/vscode version mismatch, ensuring compatibility and adding comprehensive tests.

  • Behavior:
    • Re-applies convertImageToDataPart() in vscode-lm-format.ts for image conversion to LanguageModelDataPart.
    • Re-applies checkModelSupportsImages() in vscode-lm.ts for detecting model image capability.
    • Updates useSelectedModel.ts to use model's actual supportsImages capability.
  • Testing:
    • Adds comprehensive tests for image support in vscode-lm.spec.ts and vscode-lm-format.spec.ts.
    • All 51 vscode-lm related tests pass.
  • Dependencies:
    • Keeps @types/vscode at ^1.84.0 in package.json.
    • Updates pnpm-lock.yaml to resolve @types/vscode to version 1.108.1.

This description was created by Ellipsis for 7ec9664. You can customize this summary. It will automatically update as commits are pushed.

Re-applies the image support feature from PR #11065 that was reverted,
with a fix for the @types/vscode version issue.

The fix keeps @types/vscode at ^1.84.0 in package.json (matching
engines.vscode) while the pnpm-lock.yaml resolves to version 1.108.1
which provides the LanguageModelDataPart API.

This approach:
- Maintains compatibility with VS Code 1.84.0+
- Provides TypeScript types for the new LanguageModelDataPart API
- Resolves the vsix build failure from the original PR

Changes:
- Add convertImageToDataPart() for image-to-LanguageModelDataPart conversion
- Add checkModelSupportsImages() for model image capability detection
- Update useSelectedModel to use models actual supportsImages capability
- Add comprehensive tests for image support

Relates to #11064, #11065
@roomote roomote bot requested review from cte, jr and mrubens as code owners January 29, 2026 07:16
@dosubot dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. Enhancement New feature or request labels Jan 29, 2026
@roomote
Copy link
Contributor Author

roomote bot commented Jan 29, 2026

Rooviewer Clock   See task on Roo Cloud

Reviewed the VS Code LM API image support changes. Found one issue regarding consistency between dynamic and static model definitions.

  • Inconsistency in image support detection: checkModelSupportsImages uses broad prefix matching that may conflict with static vscodeLlmModels definitions for models like gpt-3.5-turbo, gpt-4, o1, o3-mini

Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.

Comment on lines +602 to +621
export const IMAGE_CAPABLE_MODEL_PREFIXES = [
"gpt", // All GPT models (gpt-4o, gpt-4.1, gpt-5, gpt-5.1, gpt-5.2, gpt-5-mini, gpt-5.1-codex, etc.)
"claude", // All Claude models (claude-haiku-4.5, claude-opus-4.5, claude-sonnet-4, claude-sonnet-4.5)
"gemini", // All Gemini models (gemini-2.5-pro, gemini-3-flash-preview, gemini-3-pro-preview)
"o1", // OpenAI o1 reasoning models
"o3", // OpenAI o3 reasoning models
]

/**
* Checks if a model supports image inputs based on its model ID.
* Uses prefix matching against known image-capable model families.
*
* @param _family The model family (unused, kept for API compatibility)
* @param id The model ID
* @returns true if the model supports image inputs
*/
export function checkModelSupportsImages(_family: string, id: string): boolean {
const idLower = id.toLowerCase()
return IMAGE_CAPABLE_MODEL_PREFIXES.some((prefix) => idLower.startsWith(prefix))
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The broad prefix matching here creates an inconsistency with the static vscodeLlmModels definitions in packages/types/src/providers/vscode-llm.ts. For example, gpt-3.5-turbo, gpt-4, gpt-4o-mini, o1, and o3-mini all have supportsImages: false in the static definitions, but this function returns true for them because they match the "gpt", "o1", or "o3" prefixes. This means VsCodeLmHandler.getModel() may report supportsImages: true while useSelectedModel (which uses the static definitions) reports supportsImages: false for the same model. Consider either updating the static definitions to match the dynamic behavior, or making this function more granular to exclude older models that don't support images.

Fix it with Roo Code or mention @roomote and request a fix.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NaccOll @hannesrudolph what do you think of this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NaccOll @hannesrudolph what do you think of this?

Should use exact matching, and even consider adding a supportImage attribute to the statically defined models in vscode-lm instead of matching on the provider side. That would make adding and maintaining new models much easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Enhancement New feature or request size:L This PR changes 100-499 lines, ignoring generated files.

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

3 participants