Skip to content

fix: honor custom provider context for auxiliary compression - #26102

Closed
cherished-liuxu wants to merge 1 commit into
NousResearch:mainfrom
cherished-liuxu:fix/aux-compression-custom-provider-context
Closed

cherished-liuxu wants to merge 1 commit into
NousResearch:mainfrom
cherished-liuxu:fix/aux-compression-custom-provider-context

Conversation

@cherished-liuxu

Copy link
Copy Markdown

Summary

  • preserve the custom provider context when deriving the auxiliary compression model
  • avoid falling back to the main provider when large is configured under a custom provider
  • add a regression test covering the custom-provider auxiliary compression path

Test Plan

  • pytest -q tests/test_aux_compression_custom_provider_context.py

@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 duplicate This issue or pull request already exists labels May 15, 2026
@alt-glitch

Copy link
Copy Markdown
Contributor

Duplicate of #13813 (and competing with #8721, #21953, #8786). Multiple open PRs address the same bug: auxiliary compression feasibility check not threading custom_providers through to get_model_context_length(). See also tracking issue #12977.

@teknium1

Copy link
Copy Markdown
Collaborator

This appears to be implemented on main already. This is an automated hermes-sweeper review.

Evidence:

  • agent/conversation_compression.py:136 now calls get_model_context_length() for auxiliary compression with custom_providers=agent._custom_providers.
  • agent/model_metadata.py:1529 / agent/model_metadata.py:1565 show get_model_context_length() accepts custom_providers and checks custom provider per-model context overrides before fallback probing.
  • The fix was introduced by 7becb19ea00c13bdff6f78b71aa3ddfb0bdb5378 (fix(auxiliary): forward custom_providers to compression model context-length detection) and is contained in release tag v2026.5.16.
  • The maintainer discussion on this PR identified it as a duplicate of the same missing custom_providers threading bug.

@teknium1 teknium1 closed this Jun 12, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jun 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 duplicate This issue or pull request already exists 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.

3 participants