feat(agent): use main model for context compression when no override is set

[Sertug17]

Problem

Fixes #130

Context compression currently uses a small/fast auxiliary model (google/gemini-3-flash-preview) by default. As noted in the issue, compression is a fundamentally different task from quick summarization — it requires deep understanding of a long conversation to distill it without losing important context.

Change

When CONTEXT_COMPRESSION_MODEL is not explicitly set, fall back to self.model (the main agent model) instead of the auxiliary client's default:

# Before
compression_summary_model = os.getenv("CONTEXT_COMPRESSION_MODEL") or None

# After  
compression_summary_model = os.getenv("CONTEXT_COMPRESSION_MODEL") or self.model

Behavior

• If CONTEXT_COMPRESSION_MODEL is set → use that model (no change)
• If not set → use the main agent model instead of defaulting to gemini-flash

This ensures the most capable available model handles compression by default, while still allowing users to override with a cheaper/faster model if they prefer.

[teknium1]

Thanks for the PR, @Sertug17! The underlying concern from #130 has been addressed through a couple of recent changes:

1. Configurable compression model (commit 6366177) — The compression model is now configurable via config.yaml (under the compression section) or the CONTEXT_COMPRESSION_MODEL env var, so users can easily set it to their main model if they want higher-quality summaries.

2. Automatic fallback to main model (commit 3e2ed18) — When the auxiliary client fails (e.g. stale API key after switching providers), the compressor now automatically falls back to the user's active endpoint (OPENAI_BASE_URL + LLM_MODEL). On success, it caches the working client so the fallback cost is only paid once per session.

Together these mean: compression uses the fast/cheap model by default (keeping costs down), gracefully falls back to the main model if the auxiliary fails, and users can explicitly override to their main model anytime. We think this is a better default than always using the expensive main model for every compression, since compression happens fairly often in long sessions.

Issue #130 was already closed as well. Closing this PR, but appreciate the contribution — and your merged fix in #253 was great!

[Sertug17]

Thank you for the detailed explanation, @teknium1! The fallback with caching approach is indeed smarter than always using the main model keeps costs down while still ensuring quality when needed. Happy to have contributed with #253! .