feat: add dynamic model loading for Roo Code Cloud provider

[roomote]

Summary

Enables the Roo Code extension to dynamically load available models from the Roo Code Cloud provider via the /v1/models endpoint.

Changes

• New fetcher: Added getRooModels() function to fetch models from Roo Code Cloud /v1/models endpoint
• Dynamic provider: Added "roo" to the list of dynamic providers
• Type updates: Updated RooHandler to support dynamic model IDs (changed from RooModelId to string)
• Model caching: Integrated with existing modelCache infrastructure for efficient caching
• Graceful fallback: Falls back to static model definitions if dynamic loading fails

Technical Details

Model Loading Strategy

• Models are loaded asynchronously on handler initialization
• Dynamic models are merged with static models (static definitions take precedence)
• Uses 5-minute memory cache + file cache from existing infrastructure
• 10-second timeout prevents hanging on network issues

Type Safety

• Maintains backward compatibility with existing static models
• Generic type changed from RooModelId to string to support dynamic model IDs
• All type definitions updated across shared/api.ts and provider-settings.ts

Testing

• Linting passes
• Type checks pass
• Follows patterns from other dynamic providers (requesty, glama, unbound)
• Error handling with descriptive logging

Related

This PR works in conjunction with Roo-Code-Cloud PR #1316 which adds the /v1/models endpoint.

---

Important

Adds dynamic model loading for Roo Code Cloud provider, integrating API fetching, caching, and UI updates for model selection.

• Behavior:
  • Adds getRooModels() in fetchers/roo.ts to fetch models from /v1/models endpoint.
  • Integrates Roo Code Cloud as a dynamic provider in provider-settings.ts and webviewMessageHandler.ts.
  • Updates RooHandler in roo.ts to support dynamic model IDs and caching.
  • Falls back to static models if dynamic loading fails.
• Type Updates:
  • Changes RooModelId to string in RooHandler.
  • Updates type definitions in shared/api.ts and WebviewMessage.ts.
• UI Components:
  • Adds Roo component in providers/Roo.tsx for model selection.
  • Updates ApiOptions.tsx and ModelPicker.tsx to support dynamic model loading.
• Testing:
  • Updates tests in webviewMessageHandler.spec.ts and validate.test.ts to cover new functionality.
• Misc:
  • Adds Roo to dynamicProviders in provider-settings.ts.
  • Handles authentication state changes in ExtensionStateContext.tsx to refresh models.

^{This description was created by for 6a1c35e. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Review Summary

I've completed my re-review of this PR. All previously identified issues have been successfully addressed, and no new issues were found in the latest changes.

Issues Found

• Remove accidentally committed pr-body.md file from repository root
• Logout handler should flush shared model cache to maintain symmetry with login handler

Latest Changes Reviewed

The latest commit (6a1c35e) improves response handling in the Roo models fetcher:

• ✅ Always sends response even when no models are returned
• ✅ Prevents frontend from waiting indefinitely for a response
• ✅ Adds clear comment explaining the behavior
• ✅ No new issues introduced

Positive Observations

✅ Follows the same patterns as other dynamic providers (glama, unbound, requesty)
✅ Type definitions correctly updated across all relevant files
✅ Proper integration with modelCache infrastructure
✅ Appropriate error handling with fallback to static models
✅ Async loading strategy is well-designed
✅ No breaking changes to existing functionality
✅ URL handling correctly prevents duplication of /v1 suffix
✅ Test coverage added for router models integration
✅ Zod schema validation properly integrated for type safety
✅ Improved error handling with validation errors logged
✅ Auth state change handling now properly reloads models on login
✅ Comment clarity improvements in latest commit
✅ Logout handler now properly flushes model cache with error handling
✅ Successfully removed redundant instance cache in favor of shared cache infrastructure
✅ Replaced axios with native fetch API and AbortController for better timeout handling
✅ Simplified URL normalization while maintaining correctness
✅ Comprehensive error handling for fetch-specific error types
✅ Auth state watcher properly triggers model refresh on login
✅ Response always sent to prevent frontend hangs, even with empty model lists

---

View Job

[roomote]

PR Review Complete

✅ No issues found

This PR successfully implements dynamic model loading for the Roo Code Cloud provider. The implementation:

• Follows established patterns from other dynamic providers
• Has proper error handling and timeout mechanisms
• Correctly integrates with existing model cache infrastructure
• Includes appropriate fallback behavior
• Updates all necessary type definitions and UI components

The code is ready to merge.

[ellipsis-dev]

On logout, mergedModels are cleared but the memory cache isn’t flushed. Consider calling flushModels('roo') in the logged-out branch to avoid stale dynamic models.

[roomote]

The logout handler clears the instance's model cache but doesn't flush the shared model cache via flushModels("roo"), creating an asymmetry with the login handler (lines 65-72) which does flush the cache. This could allow stale authenticated models to persist in the shared cache after logout, potentially causing the next login to use outdated model data until the 5-minute TTL expires.

[roomote]

Re-review completed. Found 1 new issue regarding cache management symmetry in the logout handler.

[roomote]

Re-review complete. One issue remains unresolved (logout handler cache flush). Otherwise, the implementation follows established patterns and integrates well with the existing codebase.

[cte]

LGTM

[roomote]

All previously identified issues have been successfully resolved. The PR is ready for review and approval by a human reviewer.

[daniel-lxs]

Not a blocker, but this maintains this.mergedModels as an instance cache when modelCache.ts already handles caching. Requesty and other dynamic providers just call getModels() and let the shared cache do its thing. Should we keep this additional cache layer?

[jr]

I think it looks reasonable, at least from my phone. Left a number of non-blocking suggestions/seagulling.

[jr]

This isn't harming anything, but probably isn't doing any good for a provider that doesn't take a user specified base url.

[jr]

Not a blocker but iirc fetch() with an abort signal covers a wider range of timeout cases than axios.

[jr]

Do we need some kind of tiered pricing support (or is that allowed with this pattern/standard)?

[jr]

We might be able to lean on zod for more of this, but I don't think that's blocking either.

[roomote]

All previously identified issues have been successfully resolved. No new issues found in this review.

[roomote]

No issues found.

[roomote]

No issues found.

[roomote]

All previously identified issues have been successfully resolved. No new issues found in the latest changes.

[roomote]

No issues found.