OpenRouter: transforms:["middle-out"] declared unconditionally on all requests
- Langage dominant
- Rust
- Étoiles
- 54.2k
- Forks
- 6.2k
- Merge moyen
- 3 j 4 h
- PR mergées (30 j)
- 240
Description
**Describe the bug**
Goose unconditionally inserts `transforms: ["middle-out"]` in every OpenRouter chat completion request, regardless of conversation length or model context size. The insertion happens in `crates/goose/src/providers/openrouter.rs` `stream()` (line 293) with no threshold or condition.
From LLM request logs:
```
.input.transforms = ["middle-out"] (present on all requests, including 2-message conversations)
```
OpenRouter's middle-out transform compresses messages from the middle of the conversation when the prompt exceeds the model's context window. It is inert for short prompts (it only activates when the prompt approaches or exceeds the context limit). However, goose forces the transform on all requests, including large-context models (>8k context) where OpenRouter no longer defaults to applying it.
The transform declaration does not break caching for short conversations (middle-out is inert when the prompt fits within context). The issue is that the unconditional declaration forces the transform on models where OpenRouter would not apply it by default, and the redundant declaration adds unnecessary complexity.
---
**To Reproduce**
Steps to reproduce the behavior:
1. Configure goose with an OpenRouter provider (e.g., `z-ai/glm-5.2`)
2. Enable LLM request logging
3. Start a session and send a single message
4. Inspect the logged request payload
5. Observe that `.input.transforms` is `["middle-out"]` even for a 2-message conversation
---
**Expected behavior**
The `transforms` field should not be unconditionally set on every request. Either:
- Omit the field and rely on OpenRouter defaults (middle-out is applied by default only for <=8k-context endpoints), or
- Only include the transform when the conversation approaches the model's context limit
Users who want to force the transform can opt in via the existing `OPENROUTER_PARAMETERS` environment variable.
---
**Screenshots**
N/A
---
**Please provide the following information**
- **OS & Arch:** Any
- **Interface:** CLI / UI
- **Version:** 1.45.0
- **Extensions enabled:** N/A
- **Provider & Model:** OpenRouter - any model (notably affects >8k-context models like z-ai/glm-5.2)
---
**Additional context**
**Root cause:** `crates/goose/src/providers/openrouter.rs` `stream()` function, line 293. The `transforms` field is inserted unconditionally via `payload.as_object_mut().insert("transforms", ...)`.
**Proposed fix:** Remove the unconditional `transforms: ["middle-out"]` insertion (line 293). Rely on OpenRouter's built-in defaults (which apply middle-out only for <=8k-context endpoints) and user opt-in via `OPENROUTER_PARAMETERS` for explicit control.
**Tradeoff:** Long conversations on >8k-context models would no longer get automatic compression protection unless the user configures it via `OPENROUTER_PARAMETERS`. Goose's own context management should handle overflow prevention.
**Relevant files:**
- `crates/goose/src/providers/openrouter.rs` (line 293) - unconditional transforms insertion
**OpenRouter API reference:** `transforms` is a top-level array field. Middle-out compresses/removes messages from the middle of the prompt when it exceeds the context window. OpenRouter defaults to middle-out only for endpoints with context <= 8k. See [OpenRouter docs](https://openrouter.ai/docs/api-reference/overview).
Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
The bug is in crates/goose/src/providers/openrouter.rs at line 293, where the 'transforms' field is unconditionally inserted. Start by examining the stream() function and the payload construction. Understand OpenRouter's default behavior for context windows via its API documentation. The fix is to remove the unconditional insertion, letting OpenRouter apply its defaults. Test by enabling LLM request logging and verifying the field is absent for short conversations.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- rust
- Domaine
- backend-api-design
- Type d'issue
- Bug
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Activité
- Active
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 75/100