Skip to main content
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

Files per execution

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.

Combined input tokens

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.

START-node upload size

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.

General file size

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.
1

Chat attachment endpoint

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.
2

START activity gate

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. The agent retrieves the relevant passages instead of loading the whole file into context, which is both cheaper and more accurate.

​
Configuration reference

These are platform-level defaults. Adjust them for self-hosted deployments where your infrastructure and cost profile differ.

​
Next steps

Security overview

See how input limits fit into the defense-in-depth architecture

Knowledge bases

Route large documents to retrieval instead of inlining them