Bedrock Claude "Input is too long" error with Thinking enabled & heavy context - Context window not pruning correctly

[jorgerodriguez93]

What happened?

We are opening this issue as a follow-up to Discussion #11334. While a solution was suggested there, it has not resolved the problem in our production environment.

We are consistently encountering the Input is too long for requested model error when conversations become lengthy. This indicates that LibreChat is not correctly calculating the available context window to determine when to truncate or drop older messages/context.

It seems the current context management logic does not account for the combined overhead of:

• Thinking Budget: We reserve a large portion for reasoning.
• File Context & Search: We use multiple files attached directly to context.
• Artifacts: We generate React artifacts, which add significant token load to the history.

Instead of pruning the conversation history to fit within the model's limit, LibreChat attempts to send a payload that exceeds the Bedrock limit.

Previous Attempts
As suggested in Discussion #11334, we attempted to adjust standard parameters maxContextTokens, but the issue persists. The logic seems to fail, suggesting the token counting/subtraction logic might be off for this specific configuration.

Version Information

[LibreChat v0.8.2]

Steps to Reproduce

1. Configure a Bedrock model (Claude family) with "Thinking" enabled.
2. Attach approximately 10 small files using file_context and 8 using file_search.
3. Enable a Clickhouse MCP.
4. Start a conversation requesting React Artifact generation (heavy code output).
5. Continue the conversation until the context fills up.
6. Actual Result: The conversation crashes with "Input is too long" instead of dropping old messages.
7. Expected Result: LibreChat should handle context truncation automatically, ensuring the prompt sent to Bedrock fits within the limit (Total Limit - Thinking Budget - Max Output - Safety Buffer).

Model & Configuration
Model: global.anthropic.claude-opus-4-5-20251101-v1:0
Max Output Tokens: 64000
Thinking Budget: 10000

Attachments:
file_context: ~10 files
file_search: ~8 files
Tools/MCP: Clickhouse MCP active.

What browsers are you seeing the problem on?

No response

Relevant log output

Something went wrong. Here's the specific error message we encountered: An error occurred while processing the request: The model returned the following errors: Input is too long for requested model.

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Can you export the conversation from the top right? Using these options:

Is this happening "mid-run" or as soon as you send a message?

[jorgerodriguez93]

sorry but we cannot export the conversation, our data is confidential. The issue happens in a mid-run. If you need another type of information that we can share, please tell us.

[danny-avila]

No worries, I'll merge something soon that should help. Will post back here when done, and possibly you can share non-sensitive parts of logs after updating:

Log locations:

• Docker: Project root directory ./logs
• npm: ./api/logs

There are two types of logs that can help diagnose the issue:

• debug logs (debug-YYYY-MM-DD.log)
• error logs (error-YYYY-MM-DD.log)

[danny-avila]

Improvements to mid-run pruning made here: #11757

[danny-avila]

Later this week, I'm making improvements in this area including summarization, so hopefully that will help beyond the current state of the code.

[ethanlaj]

@danny-avila We're on 0.8.2 currently, and working to debug a similar (if not the same) issue, and these were Claude's findings - could you take a look to see if this make sense? Unlike jorgerodriguez93's, ours happens as soon as you send a message, following a lot of file_search queries

Something went wrong. Here's the specific error message we encountered: An error occurred while processing the request: The model returned the following errors: prompt is too long: 200424 tokens > 200000 maximum

Commit 24aa9c946 — "Multi-Agent Instructions Handling (#11484)" from Jan 22, 2026 — completely restructured how agent instructions and context are applied. Here's what changed:

Before this commit, the buildMessages() method:

Received instructions as a parameter from getBuildMessagesOptions()
Built systemContent by combining instructions + file context + RAG + MCP + memory
Passed systemContent as instructions into handleContextStrategy(), which counted its tokens against maxContextTokens (see BaseClient.js:402-407 — instructionsTokenCount is subtracted from the budget)
After this commit (current code):

getBuildMessagesOptions() returns {} (empty — no instructions passed to handleContextStrategy)
All context (file, RAG, memory, MCP) is built as sharedRunContext and injected into agent instructions via applyContextToAgent() AFTER truncation
handleContextStrategy receives no instructions, so instructionsTokenCount = 0 — it doesn't reserve any space for them

[ethanlaj]

Update: 0.8.2 there appears to be an issue where the token counts are inaccurate when stored in MongoDB so the app is over-including messages.

In addition, it seems like the @librechat/agents package isn't counting tokens that get added by tool calls

[danny-avila]

handleContextStrategy receives no instructions, so instructionsTokenCount = 0 — it doesn't reserve any space for them

This is already fixed on latest.

In addition, it seems like the @librechat/agents package isn't counting tokens that get added by tool calls

These are accounted from output token counts.

Try v0.8.3-rc1

[ethanlaj]

Confirming that v0.8.3-rc1 resolved the issues