[Feature] Support per-model context_window separate from max_tokens

[0xYiliu]

Problem

Current implementation uses agents.defaults.max_tokens as both:

1. output max tokens for LLM request
2. context window threshold for session summarization

This causes premature "Memory threshold reached..." for models with large context windows (e.g. GLM-5 200K), when max_tokens is intentionally set lower (e.g. 8192) for output control.

Proposal

Add context_window as an optional field in model_list entries, e.g.:

{
  "model_name": "glm-5",
  "model": "zhipu/glm-5",
  "api_key": "...",
  "api_base": "...",
  "context_window": 200000
}

Resolution priority:

1. model_list[].context_window
2. fallback to existing behavior for backward compatibility

Affected Areas

• pkg/config/config.go (ModelConfig schema)
• pkg/agent/instance.go (ContextWindow initialization)
• pkg/agent/loop.go (summarization threshold dependency)

Why

Different models have different context lengths. Output limit (max_tokens) should not be treated as context window.

[nikolasdehor]

This is a real problem. Using max_tokens as both the output cap and the context window threshold conflates two completely different concepts. A model like GLM-5 with a 200K context window but max_tokens: 8192 (for output control) will trigger premature summarization after ~8K tokens of conversation history, which defeats the purpose of using a large-context model.

Suggested implementation approach:

1. Config schema — add optional context_window to ModelConfig in pkg/config/config.go:

type ModelConfig struct {
    // ... existing fields
    ContextWindow int `json:"context_window,omitempty"`
}

2. Resolution logic in pkg/agent/instance.go:

func (a *Agent) getEffectiveContextWindow() int {
    if a.config.ContextWindow > 0 {
        return a.config.ContextWindow
    }
    // Fallback: existing behavior (max_tokens)
    return a.config.MaxTokens
}

3. Summarization threshold in pkg/agent/loop.go — replace the current max_tokens check with getEffectiveContextWindow().

This is fully backward compatible since the field is optional and the fallback preserves current behavior. Could also consider a built-in lookup table for known models (e.g. gpt-4o = 128K, claude-opus-4-6 = 200K) as a secondary fallback, but the explicit config field is the right first step.

I'd be interested in working on a PR for this if there's maintainer interest.