feat: Add environment variables to override model context limits

[dcieslak19973]

Adds support for environment variables to override context window limits for different model configurations:

• GOOSE_CONTEXT_LIMIT: Global context limit override
• GOOSE_LEAD_CONTEXT_LIMIT: Override for lead models in lead/worker mode
• GOOSE_WORKER_CONTEXT_LIMIT: Override for worker models in lead/worker mode
• GOOSE_PLANNER_CONTEXT_LIMIT: Override for planner models

This resolves issues with LiteLLM proxy models and other custom models that don't match Goose's predefined model name patterns and were defaulting to 32k context limits.

Changes:

• Add ModelConfig::new_with_context_env() for custom env var support
• Add get_context_limit_with_env_override() with precedence logic
• Update lead/worker and planner model creation to use specific env vars
• Fix CLI context display to use proper model config instead of hardcoded 32k
• Add comprehensive tests for env var override behavior
• Update documentation with usage examples

Fully backward compatible - existing behavior unchanged when env vars not set.

[Copilot]

Pull Request Overview

Adds support for overriding model context window limits via environment variables, enabling custom limits for main, lead, worker, and planner models without changing code defaults.

• Introduce ModelConfig::new_with_context_env and get_context_limit_with_env_override with precedence logic
• Update provider factory (create_lead_worker_from_env) and CLI (display_context_usage, planner setup) to use the new env‐aware constructors
• Extend documentation and add unit tests for context limit overrides

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
documentation/docs/guides/environment-variables.md	Add GOOSE_*_CONTEXT_LIMIT table and examples
crates/goose/src/providers/factory.rs	Replace ModelConfig::new with new_with_context_env for lead/worker
crates/goose/src/model.rs	Implement new_with_context_env, get_context_limit_with_env_override, update new, add tests
crates/goose-cli/src/session/mod.rs	Use model_config.context_limit() in CLI display; use planner-specific env var

Comments suppressed due to low confidence (3)

crates/goose-cli/src/session/mod.rs:1306

• Add a unit or integration test for display_context_usage to verify it reports the correct limit from model_config.context_limit() instead of the old hardcoded value.

        let context_limit = model_config.context_limit();

crates/goose-cli/src/session/mod.rs:1453

• Add a test for planner mode to ensure GOOSE_PLANNER_CONTEXT_LIMIT is correctly applied when creating the reasoner.

    let model_config = ModelConfig::new_with_context_env(

documentation/docs/guides/environment-variables.md:126

• [nitpick] Consider removing the comma in 128,000 to match numeric formatting used elsewhere (e.g., 128000) for consistency.

| `GOOSE_CONTEXT_LIMIT` | Override context limit for the main model | Integer (number of tokens) | Model-specific default or 128,000 |

[michaelneale]

its a lot of new env vars. but looks ok to me (and documented)

[dcieslak19973]

@michaelneale thanks; I'm not 100% on how to make the failing check succeed. any pointers? The bot here doesn't seem to be able to help

[angiejones]

@dianed-square @emma-squared can one of you review the doc piece?

[dianed-square]

Hi @dcieslak19973 -- do you have a good link target for "LiteLLM proxies" we can add for readers who would like additional context?

[dcieslak19973]

I'm not affiliated with LiteLLM (though I do use it and like it a lot):

https://docs.litellm.ai/
https://github.com/BerriAI/litellm

[dianed-square]

Thanks! Approved with a request to add a link for "LiteLLM proxies" if feasible

[dcieslak19973]

Thanks! Approved with a request to add a link for "LiteLLM proxies" if feasible

I'm not affiliated with LiteLLM (though I do use it and like it a lot):

• https://docs.litellm.ai/
• https://github.com/BerriAI/litellm

[dianed-square]

@michaelneale thanks; I'm not 100% on how to make the failing check succeed. any pointers? The bot here doesn't seem to be able to help

@dcieslak19973 -- I've been able to resolve this by rebasing against the latest main branch