Request sizes, formats, session bounds, sharding constraints, model behavior, and unsupported cases.
Limits are part of the privacy boundary. Increasing a size or lifetime expands exposure and resource risk, so change defaults only with explicit tests and operational controls.
REQUEST BOUNDS
Schemas reject unknown or oversized input
FIELD
ALPHA LIMIT
NOTES
Text / chat content
100,000 characters by production default
Operator setting supports one to 5,000,000 characters
Task
10,000 characters
Use one narrow downstream purpose
Policy identifier
100 characters
Lowercase pattern for custom policy creation
Chat messages
1–100
system, user, assistant, or tool roles
Model identifier
200 characters
No guarantee that an upstream supports the requested model
max_tokens
1–131,072
Passed to a configured upstream when supported
Receipt listing
1–200 per page
Offset must be non-negative
BROWSER DOCUMENTS
Text-first formats only
SUPPORTED
LIMIT
NOT YET SUPPORTED
TXT, Markdown, CSV, JSON
1 MB in browser memory
PDF, DOCX, images, OCR, archives
SESSIONS + SHARDS
Reversible context is temporary and bounded
Requested session TTL must be between 60 seconds and 30 days; production Compose caps it at seven days and defaults to 24 hours.
A shard request returns between two and eight compartments.
Current sharding is deterministic paragraph grouping; it is not a semantic model or provider fan-out engine.
Reconstruction requires a session id and reconstruction token and can be restricted to an explicit placeholder allowlist.
MODEL + PRIVACY LIMITS
What SHREDDAR does not guarantee
Exhaustive sensitive-data detection or zero false negatives.
Anonymity, unlinkability, differential privacy, confidential compute, or cryptographic secrecy between shards.
Automatic compliance, certification, privilege preservation, or suitability for arbitrary regulated data.
Streaming chat responses, because output inspection requires a complete response in the alpha.