[ENHANCEMENT] UI Option to Filter OpenRouter Quantization (FP4/Int4) to Fix CJK Encoding Issues

[jongleeat]

Problem (one or two sentences)

When using OpenRouter models (specifically z-ai/glm-4.7) with non-English languages like Korean, the model often outputs raw Unicode escape sequences (e.g., \uC548\uB855) instead of readable text.

This happens because OpenRouter automatically routes requests to low-bit quantization providers (specifically FP4 or Int4 from providers like Venice, NextBit, Mancer, DeepInfra). These aggressively quantized models fail to properly decode multi-byte characters (CJK), resulting in broken chat responses and corrupted file generation in artifacts.

Context (who is affected and when)

This affects international users (specifically Korean, Chinese, and Japanese speakers) who use OpenRouter as their API provider.

The issue occurs when the user selects a model without specifying a provider, and OpenRouter routes the request to a cheaper/faster FP4/Int4 provider. High-precision providers (FP16/BF16/FP8) handle these languages perfectly, but users currently have no easy way within Roo Code to force these options or exclude the bad ones.

Desired behavior (conceptual, not technical)

I would like a "Quantization Filter" or "Ignore Provider" setting added to the OpenRouter configuration menu in Roo Code.

Ideally, there should be a checkbox or input field (e.g., "Exclude Low-Bit Quantization (FP4/Int4)") that modifies the API request body sent to OpenRouter.

Technical Implementation Example:
When this option is enabled, Roo Code should inject the provider parameters into the API request as per the OpenRouter Documentation:

// Request body
"provider": {
// Option A: Allow only higher precision
"quantizations": ["fp16", "bf16", "fp8"],

// OR Option B: Explicitly ignore problematic providers
"ignore": ["venice", "deepInfra", "mancer", "nextbit"]
}

This would allow users to prevent encoding issues directly within the extension without needing to manually configure settings on the OpenRouter website or modify the extension's source code.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Summary: Add a checkbox to the OpenRouter settings that excludes low-bit quantized providers (FP4/FP6/Int4) from the provider routing, preventing broken CJK encoding.

Implementation:

1. Add a new setting field in packages/types/src/provider-settings.ts

   • Add openRouterExcludeLowQuantization: z.boolean().optional() to the openRouterSchema
   • This boolean controls whether to exclude FP4/FP6/Int4 quantization providers

2. Update the OpenRouter handler in src/api/providers/openrouter.ts

   • In both createMessage() and completePrompt(), when building the provider object for the request body, include quantizations: ["fp8", "fp16", "bf16", "int8"] if openRouterExcludeLowQuantization is enabled
   • This works with the existing openRouterSpecificProvider routing -- if a specific provider is chosen, the quantization filter is redundant but harmless; if no specific provider is chosen, it restricts routing to higher-precision endpoints
   • Per OpenRouter's provider selection docs, the provider.quantizations field specifies which quantization levels to allow

3. Add UI checkbox in webview-ui/src/components/settings/ApiOptions.tsx

   • Add a checkbox labeled "Exclude low-bit quantization (FP4/FP6/Int4)" in the OpenRouter provider routing section (near the existing provider dropdown, around line 872)
   • Include a descriptive note explaining this helps with CJK (Korean/Chinese/Japanese) encoding issues
   • Wire it to the openRouterExcludeLowQuantization setting field

4. Add i18n translations for the new UI labels in the appropriate locale files under webview-ui/src/i18n/

5. Add tests

   • Update src/api/providers/__tests__/openrouter.spec.ts to verify the quantizations field is included/excluded based on the setting
   • Verify the checkbox interaction in the UI component tests

This approach is minimal and non-breaking -- it defaults to off (existing behavior preserved), and when enabled it uses OpenRouter's documented provider.quantizations API to restrict to higher-precision providers.

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