Conversation Config controls global chat behavior, including the model used for title and label generation, the global default system prompt, and the pass-through policy for user-defined model options.
Entry Point#
Open Conversation in the admin console. The page has Conversation settings and Option pass-through sections.
These settings affect later conversations for all users. Existing generated titles, labels, and messages are not rewritten automatically.
For how pass-through works with capabilities, dangerous-field blocking, and native tools, see Capabilities & Native Tools.
Task Model#
The task model is used for conversation title and label generation. It can follow the current model or use a stable, inexpensive, fast chat model.
If users often choose expensive models, do not let title and label tasks follow the current model. A dedicated internal task model lowers cost and keeps title style consistent.
Global Default System Prompt#
The global default system prompt is injected as the platform-wide behavior instruction for all chat models. Empty means no global prompt. Model-level prompts are appended after it.
Use it for general platform requirements such as accuracy, clarity, organizational safety, and sensitive-information handling. Do not put one project or one user's temporary needs into the global prompt.
Title and Label Prompts#
The title prompt controls automatic title generation. The label prompt controls automatic label generation. Both can insert conversation message content.
Keep output structure stable when editing these prompts, or titles and labels may fail to parse. Validate in a small scope before production use.
Option Pass-Through Policy#
Option pass-through controls whether user-defined model options in conversation settings can reach upstream calls. It balances flexibility and governance.
| Policy | Behavior | Best For |
|---|---|---|
| Allowlist | Only listed paths pass; everything else is dropped. | Recommended default for production. |
| Denylist | Most fields pass except listed or system-blocked paths. | Trusted users or internal debugging. |
| Disabled | User-defined options do not pass through. | Strict control, cost-sensitive, or compliance-heavy environments. |
System-dangerous fields are always blocked and cannot be allowed. This prevents users from bypassing platform model, tool, safety, or route policies.
Path Rules#
Allowlist and denylist use path notation. Top-level fields use field names; nested fields use dots. Rules can be default for all protocols or added for specific protocols.
If you are unsure about upstream options, start with a small allowlist such as temperature, output length, or service tier. Do not open unknown parameters all at once.
Preview and Guide#
The pass-through section provides a live preview showing which fields pass, which are filtered, and why. The guide explains path notation, strategy differences, protocol keys, and system-blocked fields.
Before saving, use the preview to confirm the outcome, especially when switching denylist or disabled modes.
Practical Tips#
Use allowlist policy in production and expose only necessary parameters. Keep the global system prompt short and stable; put business-specific requirements in project prompts or model prompts. After saving conversation settings, test once from a normal user perspective.