> ## Documentation Index
> Fetch the complete documentation index at: https://helpcenter.magure.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Input limits
> Per-execution caps on file count, combined input size, and upload size that bound every workflow run regardless of the model it uses
Every execution is bounded before a single token reaches a model. These caps are independent of the LLM you choose: they apply whether a run uses a private model, a small model, or a large-context frontier model. Their job is to keep cost predictable and to protect the platform from oversized or runaway inputs, whether those arrive from a workflow trigger or a chat conversation.
These limits are enforced in the backend, not the UI. A scripted client, an API trigger, or a schedule is bounded by the same checks as a user uploading through the portal.
## What is capped
A single run can hand an agent at most **10 files** (`max_files_per_execution`). This counts START-node file and image inputs plus the active chat attachments for the conversation.
Across all file inputs in one run, the combined estimated size is capped at **\~1,000,000 tokens** (`max_combined_input_tokens`). The estimate is cheap: it uses each file's stored word count times a fixed factor, so no tokenizer runs on the hot path.
Files uploaded at a START node or attached to a chat are capped at **50 MB** each (`max_start_node_file_mb`). These get pulled into an agent's context on every turn, so the tighter limit keeps prompts bounded. Larger documents belong in a [Knowledge Base](/agents/knowledge-bases).
Files handled outside the START-node path (tool and file workflows) use the general cap of **100 MB** each (`max_file_size_mb`).
## How the token estimate works
The combined-token cap does not tokenize anything. Each file contributes an estimate based on its persisted metadata:
* **Text and document files** contribute `word_count * 1.35` estimated tokens once extracted. A file that has not been extracted yet falls back to a conservative size-based estimate (roughly `size_bytes / 4`), so an un-extracted file cannot slip past the cap by being checked early.
* **Tabular files** (CSV, XLSX) contribute **zero** prompt tokens. They become a SQL query tool rather than inlined text, so they are bounded by the file-count and upload-size caps instead.
* **Images** contribute **zero** prompt tokens. They are consumed as vision input and are bounded by the file-count and upload-size caps.
Duplicate file references are counted once.
## Where the limits are enforced
The same limit math runs at two independent points, so no trigger type is exempt.
When a file is attached to a conversation, the endpoint re-counts all active attachments for that conversation and rejects the upload if it would push the conversation past the file-count or combined-token cap. Attachments accumulate: every active attachment on a conversation loads into the agent on every turn, so the cap is per conversation, not per message. The per-file 50 MB size cap is checked here too.
At the start of every execution, the START activity re-evaluates the authoritative set: the union of START-node file inputs and the conversation's active chat attachments. This is the definitive per-execution check and it covers all trigger sources, in-app, API, schedule, and chat. The combined-token cap lands here, where each file's word count is known. A breach fails the run at the START node with a clear error rather than sending an oversized prompt to a model.
The START gate is fail-open by design for lookup errors only: if the gate cannot look up a file record, the execution proceeds rather than being blocked, and the event is logged for alerting. The per-file size cap and the chat attachment cap still apply as independent guards.
## Why these caps exist
* **Predictable cost** — A run's input size, and therefore its token cost, is bounded up front. No single execution can quietly consume an unbounded amount of context.
* **Denial-of-service protection** — A scripted or misbehaving client cannot flood an agent with hundreds of files or a multi-gigabyte payload. The caps hold regardless of how the execution was triggered.
* **Bounded prompts** — START-node files are inlined into the agent's context on every turn. Keeping per-file size and combined tokens in check keeps prompts within a sane envelope and pushes large documents toward retrieval instead.
When a document is too large for the START-node path, add it to a [Knowledge Base](/agents/knowledge-bases). The agent retrieves the relevant passages instead of loading the whole file into context, which is both cheaper and more accurate.
## Configuration reference
| Setting | Default | Applies to |
| --------------------------- | --------- | -------------------------------------------------------------- |
| `max_files_per_execution` | 10 | Files an agent receives in one run (inputs + chat attachments) |
| `max_combined_input_tokens` | 1,000,000 | Combined estimated tokens across all file inputs in one run |
| `max_start_node_file_mb` | 50 MB | Per-file size for START-node uploads and chat attachments |
| `max_file_size_mb` | 100 MB | Per-file size for general tool and file workflows |
These are platform-level defaults. Adjust them for self-hosted deployments where your infrastructure and cost profile differ.
## Next steps
See how input limits fit into the defense-in-depth architecture
Route large documents to retrieval instead of inlining them