Skip to content

fix(run_agent): read context_length from providers/custom_providers for compression model - #13813

Closed
ms-alan wants to merge 4 commits into
NousResearch:mainfrom
ms-alan:fix/13807-compression-context-length
Closed

fix(run_agent): read context_length from providers/custom_providers for compression model#13813
ms-alan wants to merge 4 commits into
NousResearch:mainfrom
ms-alan:fix/13807-compression-context-length

Conversation

@ms-alan

@ms-alan ms-alan commented Apr 22, 2026

Copy link
Copy Markdown
Contributor

Summary

When auxiliary.compression.model uses a custom provider with per-model context_length configured under providers/<key>/models/<model>/context_length, the compression feasibility check now looks up that value — mirroring the main model's existing providers lookup in __init__.

Root cause: _aux_compression_context_length_config was only populated from auxiliary.compression.context_length (explicit override). The same providers / custom_providers per-model context_length lookup that exists for the main model was missing for the auxiliary model.

Fix: In _prepare_compression(), added providers/custom_providers context_length lookup for the auxiliary compression model (mirrors the main model lookup in init`)

Testing

  1. Configure auxiliary.compression.provider: custom + auxiliary.compression.model pointing to a local endpoint with context_length: 262141 in providers.local-kimi.models.kimi-code/kimi-code.context_length
  2. Start a session — the compression threshold should use 262141 instead of the endpoint's auto-detected 128000

Closes #13807

teknium1 and others added 4 commits April 22, 2026 11:36
…or compression model

When auxiliary.compression.model uses a custom provider with per-model
context_length configured in providers/local-kimi.models.kimi-code.context_length,
the compression feasibility check now looks up that value — mirroring the
main model's existing providers lookup in __init__.

Previously it only checked auxiliary.compression.context_length (explicit override)
and endpoint auto-detection, ignoring the per-model config in providers.

Closes NousResearch#13807
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint area/config Config system, migrations, profiles labels Apr 22, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #13540 which also targets the same compression context_length propagation gap via a different approach.

1 similar comment
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #13540 which also targets the same compression context_length propagation gap via a different approach.

@smallerxie

Copy link
Copy Markdown

Related: PR #17460 addresses the same root cause but with a more general approach. Instead of adding a providers lookup in _prepare_compression() (compression-only), it auto-loads custom_providers inside get_model_context_length() — fixing all auxiliary paths at once.

See also: #13540, #12977, #13807

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for identifying the auxiliary compression context-length propagation gap. This is now implemented on current main; this is an automated hermes-sweeper review.

  • Commit 7becb19ea00c13bdff6f78b71aa3ddfb0bdb5378 forwards the agent's compatible custom-provider configuration to compression context-length detection.
  • agent/conversation_compression.py:236-245 now passes custom_providers=agent._custom_providers to get_model_context_length() for the actual auxiliary compression client.
  • agent/agent_init.py:1653-1665 builds that list through get_compatible_custom_providers(), whose compatibility layer covers both legacy custom_providers and keyed providers configuration.

The later shared-path fix satisfies the PR's requested behavior without duplicating provider lookup logic in the compression check.

@teknium1 teknium1 closed this Jul 12, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jul 12, 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 runtime: loop, agent_init, prompt builder, context-compression, responses endpoint 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.

auxiliary compression model does not read context_length from providers config

4 participants