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

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.

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.

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

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.