fix: adjust token clamping threshold from 20% to 80% for GLM-4.5 compatibility

[roomote]

This PR fixes issue #6806 where GLM-4.5 models on OpenRouter were failing with token limit errors after upgrading to v3.25.8.

Problem

The commit c52fdc4 introduced a 20% clamping threshold for model max tokens relative to the context window. This was too restrictive for models like GLM-4.5 that legitimately require high output token counts (98,304 tokens out of 131,072 context window = 75%).

Solution

Adjusted the clamping threshold from 20% to 80% of the context window. This:

• Prevents models from using the entire context for output (which could cause issues)
• Allows models with legitimate high output requirements like GLM-4.5 to function properly
• Only applies clamping when truly necessary (when maxTokens > 80% of context)

Changes

• Modified getModelMaxOutputTokens function in src/shared/api.ts to use 80% threshold
• Updated all related test cases to reflect the new threshold
• All tests pass successfully

Testing

• ✅ src/shared/__tests__/api.spec.ts - 21 tests passing
• ✅ src/api/providers/__tests__/openrouter.spec.ts - 12 tests passing
• ✅ src/api/transform/__tests__/model-params.spec.ts - 45 tests passing
• ✅ All linting and type checks pass

Fixes #6806

---

Important

Adjusts token clamping threshold from 20% to 80% for GLM-4.5 compatibility, updating getModelMaxOutputTokens and related tests.

• Behavior:
  • Adjusts token clamping threshold from 20% to 80% in getModelMaxOutputTokens in api.ts.
  • Ensures models with high output requirements, like GLM-4.5, function correctly.
  • Clamping only applies when maxTokens > 80% of context window.
• Testing:
  • Updates test cases in api.spec.ts, openrouter.spec.ts, and model-params.spec.ts to reflect new 80% threshold.
  • All tests pass successfully, ensuring no regressions.
• Misc:
  • Fixes issue GLM 4.5 OR Chutes AI error 400 #6806 related to token limit errors for GLM-4.5 models.

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

[roomote]

Reviewing my own code because apparently I trust no one, not even myself.

[roomote]

Is using Math.floor() here intentional? With a context window of 131,072, this gives 104,857 tokens instead of 104,858. While minor, would Math.ceil() or Math.round() better maximize available tokens for edge cases?

[roomote]

Consider extracting this magic number to a named constant like MAX_OUTPUT_TOKEN_RATIO = 0.8 for better maintainability. This would make it easier to adjust in the future and clearer about the intent.

[roomote]

Would it be helpful to add a specific test case for the GLM-4.5 scenario that triggered this issue? Something like:

Suggested change

	})
	test("should handle GLM-4.5 model with 98,304 tokens out of 131,072 context window", () => {
	const model: ModelInfo = {
	contextWindow: 131_072,
	supportsPromptCache: false,
	maxTokens: 98_304, // 75% of context window
	}
	const settings: ProviderSettings = {
	apiProvider: "openrouter",
	}
	const result = getModelMaxOutputTokens({
	modelId: "z.al/glm-4.5",
	model,
	settings,
	format: "openrouter",
	})
	expect(result).toBe(98_304) // Should use model.maxTokens since 75% < 80%
	})

[roomote]

The comment is good, but could we be more explicit about why 80% was chosen? Perhaps mention that this leaves approximately 20% for input tokens and system prompts, which is typically sufficient for most use cases?