Summary

For custom providers, custom_providers[].models[*].context_length is not applied consistently across runtime paths.

The main model can honor the override during agent initialization, but other paths may fall back to probing /models metadata and then to 128000 if the provider does not return a context field. This causes inconsistent behavior and spurious warnings such as:

Compression model (gpt-5.4) context is 128,000 tokens, but the main model's compression threshold is 250,000 tokens.

Reproduction

Example config:

model:
  default: gpt-5.4
  provider: custom
  base_url: https://example-proxy/v1

compression:
  enabled: true
  threshold: 0.8

auxiliary:
  compression:
    provider: custom
    model: gpt-5.4
    base_url: https://example-proxy/v1

custom_providers:
  - name: Example Proxy
    base_url: https://example-proxy/v1
    model: gpt-5.4
    models:
      gpt-5.4:
        context_length: 500000

Provider /models returns either no context_length field, or a different model id than the configured one.

Actual behavior

Different runtime paths compute different context lengths for the same model/runtime:

• main model initialization can use the custom_providers override
• compression feasibility checks can probe /models, miss metadata, and fall back to 128000
• runtime switching / fallback activation can lose the previously resolved override

Expected behavior

All runtime paths should use a single override resolution flow:

1. explicit config override (model.context_length or matching custom_providers[].models[*].context_length)
2. provider metadata probing
3. fallback default

For custom providers, explicit config should win consistently for:

• agent initialization
• switch_model()
• compression feasibility checks
• fallback runtime activation

Notes

Related to #5089, but broader: this affects runtime behavior and compression warnings, not just status display.