hermes - 💡(How to fix) Fix [Bug]: Native Bedrock Converse adapter does not forward context-1m beta — Opus 4.6/4.7 stuck at 200K (PR #16793 only patched OpenAI-compat path)

Summary

The native Bedrock Converse adapter (agent/bedrock_adapter.py) does not forward the context-1m-2025-08-07 beta header to additionalModelRequestFields, which blocks 1M-context for Claude Opus 4.6 / 4.7 on accounts with the entitlement.

PR #16793 (merged 2026-04-28) fixed this for the OpenAI-compat path through the AnthropicBedrock client (agent/anthropic_adapter.py — _CONTEXT_1M_BETA = "context-1m-2025-08-07" machinery on lines 267, 558, 792). The native Converse path was missed.

Users on the native bedrock_converse provider (which the setup wizard recommends for direct AWS Bedrock without a Mantle/proxy) are stuck at 200K even with the entitlement.

Reproduction

1. ~/.hermes/config.yaml configured for native Bedrock:

   provider: bedrock
   model: us.anthropic.claude-opus-4-7

   (No OPENAI_BASE_URL/Mantle proxy — direct boto3 path.)

2. Confirm AWS account has the 1M context beta entitlement (Anthropic gate it; was on the allow-list for me).

3. Start Hermes, observe banner reports 200K context for claude-opus-4-7.

4. Inspect build_converse_kwargs() in agent/bedrock_adapter.py — additionalModelRequestFields is never populated with anthropic_beta.

5. BEDROCK_CONTEXT_LENGTHS table doesn't list claude-opus-4-7 at all; it falls through to the claude-opus-4 substring match (200K) or the 128K default.

Expected

When user opts in (their AWS account has the entitlement), bedrock_converse adapter sends:

additionalModelRequestFields={"anthropic_beta": ["context-1m-2025-08-07"]}

and get_bedrock_context_length("us.anthropic.claude-opus-4-7") returns 1_000_000.

Verified working

I wrote a local patch that:

1. Adds opt-in via HERMES_BEDROCK_1M_CONTEXT env var (default OFF, so accounts without the entitlement are unaffected).
2. When ON + model is Opus 4.6/4.7, injects anthropic_beta=["context-1m-2025-08-07"] into additionalModelRequestFields, merging with any caller-supplied betas instead of clobbering.
3. get_bedrock_context_length() returns 1M only when both opt-in is set AND model is capable.
4. 14 new tests in tests/agent/test_bedrock_1m_context.py covering opt-in/opt-out, model gating, beta merging, and context-length lookup. The 2 existing TestBedrockContext1MBeta tests (which cover the OpenAI-compat path PR #16793 fixed) still pass — total 16/16 green.

Wire-level smoke test against real AWS Bedrock returned HTTP 200 OK:

import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
resp = client.converse(
    modelId="us.anthropic.claude-opus-4-7",
    messages=[{"role": "user", "content": [{"text": "Say only: OK"}]}],
    inferenceConfig={"maxTokens": 8},
    additionalModelRequestFields={"anthropic_beta": ["context-1m-2025-08-07"]},
)
# → STATUS: 200 OK, output: "OK"

So the upstream gate is on Hermes' side, not on AWS's.

Patch

Branch bedrock-1m-converse-fix against a84cec61c — 2 files changed, +217 / -0:

• agent/bedrock_adapter.py — adds _BEDROCK_1M_CONTEXT_ENV, _BEDROCK_CONTEXT_1M_BETA, bedrock_1m_context_enabled(), is_anthropic_opus_4_1m_capable(); modifies build_converse_kwargs() to inject the beta when capable + opt-in; updates get_bedrock_context_length() to return 1M for capable+opt-in.
• tests/agent/test_bedrock_1m_context.py — 14 new tests (NEW FILE).

Happy to open a PR with the diff if you'd prefer that to an issue. Wanted to file the issue first since I can't tell from the outside whether the anthropic_adapter.py/bedrock_adapter.py split is intentional or whether a unified helper is the better refactor target.

Environment

• Hermes-agent at a84cec61c (current main as of 2026-05-23)
• Python 3.11, boto3 native Converse transport
• macOS 26.4.1, AWS region us-east-1
• Model: us.anthropic.claude-opus-4-7 (1M-capable)