[BUG] Context Condensing Regression: No dedicated model selector, using active model causes high cost/errors, and switching models breaks continuation

[cmpdev23]

Problem (one or two sentences)

The option to select a dedicated model for context condensing has been removed from settings. The current workaround (switching models before condensing) breaks the conversation and causes API errors when switching back to the original model, making context condensing effectively unusable.

Context (who is affected and when)

Affects all users who use expensive/slow models (e.g., Claude Opus) for coding and previously relied on a dedicated cheaper model (e.g., Gemini Flash) for context condensing. This impacts anyone working on long tasks where context needs to be condensed regularly, making them choose between high cost or a broken workflow.

Reproduction steps

1. Open Roo Code settings — notice the option to select a dedicated model for context condensing is no longer present (it was available in a previous version).
2. 2. Start a long conversation with an expensive model (e.g., Claude Opus 4.6).
3. 3. When the context gets long, click the "Condense context" button in the chat.
4. 4. Observe that the condensation runs using the currently active model (Opus 4.6), which is slow and expensive for this simple task.
5. 5. Workaround attempt: Before condensing, switch to a cheaper/faster model (e.g., Gemini Flash). Condense the context. Then switch back to the original model (Opus 4.6).
6. 6. Observe that after switching back, the model is no longer able to continue the conversation — it produces only API errors.

Expected result

A dedicated model selector for context condensing should be available in settings (as it was before), allowing users to pick a fast and cheap model (e.g., Gemini Flash) for condensing, independently of the main coding model. After condensing, the original model should seamlessly continue the conversation without errors.

Actual result

1. The dedicated model selector for context condensing is gone from settings.2. Condensing now always uses the currently active model, making it slow and costly when using a powerful model like Opus.3. If the user manually switches to a cheaper model to condense, then switches back to the original model, the conversation breaks entirely — the model can no longer continue and only returns API errors (likely a system prompt / cross-model configuration conflict).

Variations tried (optional)

• Tried condensing with the active model (Opus): works but is very slow and expensive.
• • Tried switching to Gemini Flash before condensing, then switching back to Opus: condensing succeeds, but the conversation is broken afterward — only API errors occur when continuing with Opus.
• • • The old behavior (dedicated model selector in settings) worked perfectly and this regression makes context condensing practically unusable for users who rely on affordable models for this task.

App Version

latest

API Provider (optional)

None

Model Used (optional)

Claude Opus (main model), Gemini Flash (attempted condensing model)

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've investigated this issue and here's what I found:

Root Cause

The dedicated condensing model selector was intentionally removed in PR #10901 (commit 9d65772d2). The commit message explains the rationale:

"Modern conversations include provider-specific data (tool calls, reasoning blocks, thought signatures) that only the originating model can properly understand and summarize."

So this is not a regression bug -- it was a deliberate design decision. The concern is that conversations now contain provider-specific constructs (Anthropic tool_use blocks, OpenAI function calls, reasoning/thinking blocks, etc.) that a different provider's model may not properly parse when generating a condensation summary.

Analysis

That said, the current implementation in src/core/condense/index.ts already converts tool_use/tool_result blocks to text representations via transformMessagesForCondensing() before sending them to the condensing API call (lines 310-316). This was specifically done so that "some providers (like Bedrock via LiteLLM) [can work] without needing to pass the tools parameter." This means the technical barrier cited in the removal PR is already partially mitigated.

Proposed Implementation Plan

If the maintainers agree this feature should be restored, here is my proposed approach:

1. Add condensingApiConfigId back to global settings in packages/types/src/global-settings.ts and packages/types/src/vscode-extension-host.ts (ExtensionState)
2. Restore the condensing API handler creation in src/core/condense/index.ts -- add back the optional condensingApiHandler parameter to SummarizeConversationOptions and summarizeConversation(), using it when provided (falling back to the task's main API handler)
3. Restore the API config dropdown in the settings UI -- add an API configuration selector in the condensing section of webview-ui/src/components/settings/ContextManagementSettings.tsx (or PromptsSettings.tsx where it previously lived)
4. Wire up the state through ClineProvider.ts and Task.ts to pass the condensing API handler when a custom config is selected
5. Update context management in src/core/context-management/index.ts to accept and forward the condensing API handler
6. Update tests across all affected test files

This approach essentially reverts the removal from PR #10901 while keeping the existing transformMessagesForCondensing() safeguard that converts tool blocks to text, which should handle cross-provider compatibility concerns.

However, I want to flag that the maintainers may have had additional reasons beyond what's in the commit message for removing this feature. Before implementing, I'd recommend getting explicit approval from the team.

Please mention @roomote in a comment saying that you approve this plan (or suggesting modifications), and I'll proceed with the implementation.

[cmpdev23]

@roomote

Ok let's do this !

[roomote-v0]

I've seen your comment and will explore a potential fix. I'll work on restoring the dedicated condensing model selector following the plan outlined earlier. I'll open a PR to share progress.

[roomote-v0]

Opened a PR with my attempt at addressing this: #11988

The PR restores the dedicated model selector for context condensing by adding a condensingApiConfigId setting with an API config dropdown in the Context Management settings. When configured, a separate API handler is built for all condensing operations (manual, automatic, and context-window-exceeded recovery), falling back to the active model when unset.

All existing tests pass with updated assertions. Feedback welcome!