Multiple attachments can overflow the context window, error message is unclear

[casewalker]

What happened?

When attaching files to a chat, each file can get correctly truncated to respect the fileTokenLimit, but a user may be allowed to upload enough files to overflow the available context for the current chat. For example, on Sonnet 4.5 the entire context window is just 200k tokens, and with the default fileTokenLimit at 100k, it can take just two files to overflow the entire context window.

Rather than reporting an issue related to the files, LibreChat reports an error of type empty_messages:

Message pruning removed all messages as none fit in the context window. Please increase the context window size or make your message shorter.

To me, it seems like it would be very unclear to a user that this error might be related to their uploaded files, it seems to point to the user's chat message instead, but in this scenario, the size of the message can be arbitrarily small while still triggering the issue.

LibreChat already has size controls for file uploads (fileSizeLimit, totalSizeLimit) and those have clear and helpful error messages when they are broken, but:

• those limits are sized in bytes which doesn't correlate with tokens / token limits
• the available token-budget is a dynamic value depending on the remaining window, system prompt, tools, and chat history
• different file types may expand differently during text extraction (document parsing, RAG restructuring), so byte size may not be a good predictor of token count
• this edge case of cumulatively overflowing the context window doesn't seem to be covered right now

Short term, perhaps error messaging could be updated to catch this case, but long term, I would propose some kind of cumulative token-budget check on every uploaded file, and then throwing an error when a file currently being uploaded would overflow the chat's remaining token-budget.

Version Information

LibreChat version: v0.8.8-rc1
Commit: eaef87f
Branch: main
Build date: 2026-08-14 07:28:58 UTC
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36

Steps to Reproduce

1. Set fileTokenLimit to some value less than your model's context window
2. Upload enough large files such that N * fileTokenLimit approaches or goes over the context window size
3. Send some small message in chat with this file-upload setup

What browsers are you seeing the problem on?

No response

Relevant log output

{
  "level": "warn",
  "message": "[textTokenLimiter] Text truncated from 3375285 to 97958 tokens (limit: 100000)",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "timestamp": "2026-08-18T05:04:43.487Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "level": "warn",
  "message": "[textTokenLimiter] Text truncated from 4999355 to 97963 tokens (limit: 100000)",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "timestamp": "2026-08-18T05:04:46.292Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "level": "info",
  "message": "[agents:graph] Summarization triggered",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.789Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "level": "info",
  "message": "[agents:prune] Emergency truncation complete",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.789Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "effectiveMax": 122657,
  "emergencyMaxChars": 490628,
  "level": "warn",
  "message": "[agents:prune] Empty context, entering emergency truncation",
  "messageCount": 1,
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.788Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "level": "info",
  "message": "[agents:prune] Emergency truncation complete",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.811Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "effectiveMax": 122657,
  "emergencyMaxChars": 490628,
  "level": "warn",
  "message": "[agents:prune] Empty context, entering emergency truncation",
  "messageCount": 1,
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.811Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "agentId": "bedrock__us.anthropic.claude-sonnet-4-5-20250929-v1__0___Claude Sonnet 4.5",
  "breakdown": "Token budget breakdown:\n maxContextTokens: 129200\n instructionTokens: 83 (system: 83, dynamic: 0, tools: 0 [0 tools])\n summaryTokens: 0\n messageTokens: 196113 (1 messages)\n availableForMessages: 122657",
  "instructionsExceedBudget": false,
  "level": "error",
  "message": "[agents:graph] Empty messages after pruning",
  "messageCount": 1,
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "runId": "83f56351-e002-4cf4-994f-c91f8e2d648d",
  "timestamp": "2026-08-18T05:04:47.813Z",
  "userId": "69fdf0af9055e092ab88622f"
}
{
  "level": "error",
  "message": "{\"type\":\"empty_messages\",\"info\":\"Message pruning removed all messages as none fit in the context window. Please increase the context window size or make your message shorter.\\nToken budget breakdown:\\n maxContextTokens: 129200\\n instructionTokens: ...",
  "name": "Error",
  "pregelTaskId": "f42a0e29-3f93-59d5-9fae-3c9afaf663c5",
  "requestId": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_id": "4113a72a-54d4-441d-8df3-b98e197df67d",
  "request_method": "POST",
  "request_path": "/api/agents",
  "stack": "Error: {\"type\":\"empty_messages\",\"info\":\"Message pruning removed all messages as none fit in the context window. Please increase the context window size or make your message shorter.\\nToken budget breakdown:\\n maxContextTokens: 129200\\n instructionTok...",
  "timestamp": "2026-08-18T05:04:47.818Z",
  "userId": "69fdf0af9055e092ab88622f"
}

Screenshots

Code of Conduct

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

[danny-avila]

Thanks for the detailed report and reproduction details. The underlying behavior is understood, but the appropriate fix, especially a dynamic cumulative token-budget check, needs product and implementation discussion before it can be scoped as an issue.

I’m moving this to Discussions so we can settle the intended behavior. Once there’s a concrete direction, we can open a focused implementation issue.

[GioiaZheng]

I think this is worth treating as a budget-accounting problem rather than only an error-message problem.

The current failure is confusing because the user sees an empty_messages error, but the limiting object is not necessarily the visible user message. In this case the files have already expanded into a single message payload that is larger than effectiveMax, so pruning has no smaller unit it can keep.

A useful contract would be:

per-file token limit
  -> prevents one extracted file from consuming the whole budget

cumulative attachment budget
  -> prevents N individually valid files from exceeding the remaining model context

final prompt budget
  -> reserves tokens for instructions, chat history, tool definitions, and output

For short-term behavior, I would make the error identify the oversized budget class explicitly. Something like:

The attached files exceed the remaining context budget for this model. Remove one or more files, lower the file token limit, or start a new chat with a larger context window.

For longer-term behavior, the check probably has to happen after extraction/tokenization, not only at upload time. Byte limits are still useful for storage and abuse prevention, but they cannot reliably predict model tokens across PDF/doc parsing, OCR, markdown conversion, or structured file expansion.

The regression test I would want is:

• model context: fixed small test value;
• fileTokenLimit: each file individually below the limit;
• two or more attachments whose combined extracted tokens exceed the available prompt budget;
• tiny user message;
• expected result: attachment-budget error, not empty_messages / "make your message shorter".

That keeps the current pruning logic honest: if no unit fits after pruning, the system should report which unit overflowed. In this case, the unit is the cumulative attachment payload, not the user's typed message.

[kimnamu]

Thanks for the detailed report with the full token-budget breakdown, and for the design notes above. Two details I checked against main (12d7890, v0.8.8-rc3) may help settle the short-term wording.

The maxContextTokens: 129200 in the log is not the model's 200k window. When the request sets no maxTokens, the Bedrock parser defaults it to Sonnet 4.5's max output (64,000), and the agent budget becomes (200,000 - 64,000) x 0.95. Two files truncated to ~98k tokens each (196,113 total) therefore cannot fit before instructions are even counted. The same formula gives 182,218 with maxTokens 8,192.

# packages/api jest probe, model us.anthropic.claude-sonnet-4-5-20250929-v1:0
{"input":{"model":"..."},"getModelMaxTokens":200000,"llmConfig_maxTokens":64000,"baseContextTokens":136000,"maxContextTokens":129200}
{"input":{"model":"...","maxTokens":8192},"getModelMaxTokens":200000,"llmConfig_maxTokens":8192,"baseContextTokens":191808,"maxContextTokens":182218}

Where this comes from on main

• Default output reservation: packages/data-provider/src/bedrock.ts resolveThinkingMaxTokens falls back to anthropicSettings.maxOutputTokens.reset(model), which is 64,000 for claude-sonnet-4-5 (schemas.ts CLAUDE_4_64K_MAX_OUTPUT).
• Budget: packages/api/src/agents/initialize.ts reads maxOutputTokens = llmConfig.maxOutputTokens ?? llmConfig.maxTokens (l.1339), baseContextTokens = agentMaxContextNum - maxOutputTokensNum (l.2388), and maxContextTokens = round(baseContextTokens x (1 - 0.05)) unless an explicit maxContextTokens is set (l.2526-2529).
• Per-file only: packages/api/src/files/context.ts (l.67-86) truncates each attachment to fileTokenLimit independently. There is no cumulative check on main, so the report still reproduces as described.
• Error rendering changed after this thread was opened: 🗯️ fix: Give Failed Turns Actionable Guidance #15896 (merged 2026-09-14, in v0.8.8-rc3) renders empty_messages with the "Token budget" breakdown inside a disclosure (client/src/components/Messages/Content/Error/ContextError.tsx, l.141-157) plus the com_error_context_next_steps text. Neither the copy nor the breakdown mentions attachments yet, so the attachment-specific wording proposed above remains open.