Skip to content

fix(agent): honor custom provider context in compression feasibility check#8721

Closed
HamsteRider-m wants to merge 3 commits into
NousResearch:mainfrom
HamsteRider-m:fix/compression-feasibility-custom-provider-context
Closed

fix(agent): honor custom provider context in compression feasibility check#8721
HamsteRider-m wants to merge 3 commits into
NousResearch:mainfrom
HamsteRider-m:fix/compression-feasibility-custom-provider-context

Conversation

@HamsteRider-m

@HamsteRider-m HamsteRider-m commented Apr 13, 2026

Copy link
Copy Markdown

Summary

  • prefer explicit auxiliary.compression.context_length overrides during compression feasibility checks
  • fall back to runtime config-aware resolution for scoped model.context_length and custom_providers[].models[model].context_length
  • add regression coverage for explicit auxiliary overrides, runtime-config custom providers, and non-primary summary models

Test Plan

  • python -m pytest tests/run_agent/test_compression_feasibility.py -q -vv

Fixes #5089

Hanson Mei added 2 commits April 13, 2026 16:18
…check

- resolve config context length for auxiliary compression models
- scope top-level model.context_length to the active primary endpoint
- add regression coverage for custom-provider overrides and non-primary summary models

Fixes NousResearch#5089
@HamsteRider-m HamsteRider-m force-pushed the fix/compression-feasibility-custom-provider-context branch from cd637f0 to a029cf7 Compare April 13, 2026 08:56
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/agent Core agent loop, run_agent.py, prompt builder area/config Config system, migrations, profiles labels Apr 28, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #14119 and #8786 — multiple competing PRs for custom provider context_length in compression. See also #8785 (bug report).

@smallerxie

Copy link
Copy Markdown

PR #17460 is related to this issue — it fixes the same compression feasibility check gap by auto-loading custom_providers inside get_model_context_length() for all callers, not just the ones that were manually wired in #15844.

See also: #12977, #13807, #8785

@teknium1

Copy link
Copy Markdown
Contributor

This appears implemented on current main by the compression-feasibility path now present in agent/conversation_compression.py.

Automated hermes-sweeper review evidence:

  • agent/conversation_compression.py:136-145 calls get_model_context_length() for the auxiliary compression model and forwards both config_context_length=getattr(agent, "_aux_compression_context_length_config", None) and custom_providers=agent._custom_providers.
  • agent/agent_init.py:1326-1342 reads auxiliary.compression.context_length into _aux_compression_context_length_config.
  • agent/agent_init.py:1395-1407 resolves configured custom providers and stores them on the agent for reuse by the feasibility check.
  • agent/model_metadata.py:1565-1578 resolves custom_providers[].models[model].context_length before probe/fallback paths.
  • tests/run_agent/test_compression_feasibility.py:174-197 and nearby tests cover the explicit auxiliary override and call shape.

I also checked the related #17460 discussion item; that PR is broader, but the specific compression-feasibility gap in this PR is already covered on main.

@teknium1 teknium1 closed this Jun 10, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/agent Core agent loop, run_agent.py, prompt builder P2 Medium — degraded but workaround exists sweeper:implemented-on-main Sweeper: behavior already present on current main type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Status banner fails to detect context_length from custom_providers

4 participants