Skip to main content

Sorter model defaults and limits

Sorter defaults control passive sorting separately from the general chat model. Read sorting and model access first.

Administrator and user choices​

In Administration → LLM models → Sorter defaults, select an active model from an active provider. Save its reasoning choice and optional context limit. The limit is a positive integer token count. An empty limit uses the model and permitted grant bounds.

Users inherit the tenant value. mail.sorting.overrideModel allows a personal override and depends on mail.sorting.manage. Normal and moderator defaults do not grant it automatically. With that permission, Sorting → Override tenant model exposes personal model, reasoning, and context choices. Revocation returns new work to tenant defaults.

A default model does not bypass model grants. One allowed tuple must cover model, reasoning, and context together. Grants from different groups cannot combine into a wider tuple. An unavailable default causes a visible admission error.

default means the provider default, with no explicit reasoning parameter. Empty sorter reasoning selects the first permitted grant value. Choose an explicit level for repeatable behavior. Personal choices come from the user's allowed model grants.

The context limit covers the full prompt and reserved output. It is not message truncation. Runtime uses a conservative UTF-8 byte bound instead of a tokenizer. A large body can fail before its actual token count reaches the limit. MailGen does not silently remove content needed for negative conditions. Output tokens and thinking budget remain separate limits.

Storage and admission​

Tenant defaults use authorization.policies, key sorter.defaults, with empty subject_id. GET/PUT /api/admin/sorting-defaults check tenant ownership and administrator read/manage access. The server audits saves. The body contains modelId (authorization UUID or null), reasoningLevel, and contextTokens.

sorting_settings.override_model defaults to false. Settings and runs retain nullable reasoning_level and context_tokens. Admission snapshots the resolved values. Later administrator edits cannot change prepared work. The signed intent protects these values, including compatibility for older null-valued runs.