This guide first explains why DEEIX Chat separates model capabilities, parameter pass-through, provider-native tools, and native tool billing, then shows where to configure each part and how to verify it.
What It Solves#
Model providers keep adding new abilities, parameters, and tools. If the platform can only support fixed built-in features, administrators cannot expose new capabilities quickly. If users can freely write advanced options, they may bypass model, routing, tool, safety, or billing controls.
DEEIX Chat solves this by splitting capability exposure into layers. Administrators declare what a model supports, decide which parameters users may adjust, enable specific official tools, and configure separate tool billing. Users can use allowed abilities, while dangerous fields, unknown tools, and unauthorized tools are filtered.
Four Layers#
| Layer | Managed In | Purpose |
|---|---|---|
| Model capabilities | Model Management | Declare supported inputs, outputs, default options, parameter controls, and native abilities. |
| Parameter pass-through | Conversation Config | Decide which user-defined model options may reach upstream calls. |
| Provider-native tools | Model Management | Decide which official provider tools a model may use. |
| Tool billing | Usage Billing | Decide whether official native tools are billed per call. |
These layers are independent but constrained. Enabling a capability does not allow every parameter. Showing a control does not guarantee the option is effective. A tool existing does not mean users can use it. A usable tool does not mean it is separately billed.
What Pass-Through Means#
Pass-through is not a raw copy of user input. It passes necessary model options and official abilities to the real model only within administrator-approved rules.
For example, administrators can expose low-risk options such as temperature, output length, or service tier in the chat parameter panel, while still blocking model selection, routing, tool injection, safety-related fields, and other sensitive controls. This keeps advanced flexibility without handing platform control to user input.
What Provider-Native Tools Are#
Provider-native tools are built-in or hosted tool abilities from model providers, such as web search, code execution, image generation, or URL context. They differ from MCP tools: MCP tools are external services connected by the platform, while native tools are abilities supported by the provider model itself.
DEEIX Chat manages provider-native tools inside model capabilities. Only tools enabled by administrators for a model can become available user-side. If users hand-write tool configuration, the platform keeps only administrator-allowed native tools and filters unknown or unauthorized tools.
When to Configure This#
| Scenario | What to Configure |
|---|---|
| You want the model to use default options | Configure Default Value in model capabilities. If users should not adjust it, do not add a visible user control. |
| Adding a model with special options | Configure defaults and parameter controls in model capabilities; if users need to adjust them, allow the paths in pass-through. |
| Users need to adjust parameters in chat | Add visible controls in model capabilities and confirm pass-through allows those paths. |
| A provider adds a native tool | Enable a catalog tool or add a custom native tool in model capabilities. |
| A tool has separate provider cost | Enable native tool billing and set tool prices in Usage Billing. |
| You want to prevent advanced options from bypassing policy | Use allowlist pass-through plus system blocking and native tool filtering. |
Entry Map#
| What to Configure | Admin Entry | Purpose |
|---|---|---|
| Model defaults and parameter panel | Model Management > create or edit model > Capabilities | Set default model options and decide which controls users see. |
| Provider-native tools | Model Management > create or edit model > Capabilities > Native Tools | Decide which official provider tools a model may use. |
| Parameter pass-through | Conversation Config > Option Pass-Through | Decide which user-defined model options may reach upstream calls. |
| Native tool billing | Usage Billing > Tool Pricing | Decide whether official native tools are billed per call. |
Configure in this order: declare model capabilities and tools first, allow the necessary parameter paths in Conversation Config, then confirm tool prices in Billing.
Step 1: Open Model Capabilities#
Open the admin console, go to Model Management, then create a model or edit an existing model. In the model form, find Capabilities.
Use Visual Configuration first. It opens Model Capability Configuration, where you can configure parameters and native tools with forms. Use Advanced JSON only when you need to paste a full configuration, edit in bulk, or handle a special structure.
If the model generates images and the upstream source supports streaming image generation, enable Image Streaming. This only allows the platform to use the streaming image flow; the actual upstream source still needs to support it.
Step 2: Configure Parameter Controls and Defaults#
In Model Capability Configuration, open the Parameters tab. This configures the controls users see in the chat parameter panel and the model's default options.
| Field | How to Fill It | Purpose |
|---|---|---|
| Parameter | Use the real option path. Use dots for nested fields. | Decides where the default value is written and which option the control maps to. |
| Default Value | Enter the default value. | Used when the user has not saved their own value. |
| Name | Enter a user-readable label. | Shown in the chat parameter panel. |
| Description | Explain the effect briefly. | Helps users decide when to adjust it. |
| Type | Choose text, select, number, or boolean. | Controls the user-side input style. |
| Options | For select controls, provide comma-separated values. | Limits users to known values. |
Default values are written into model defaults. If you only want the model to always carry certain defaults, fill the default value and do not add a visible user control. Parameter controls define the user-side panel. A visible control does not guarantee pass-through; the final decision is still made by Conversation Config.
Step 3: Configure Provider-Native Tools#
Go back to Model Management, edit the target model, open Capabilities, then open the Native Tools tab.
If the tool already exists in the catalog, select and enable it. The built-in catalog covers common provider tools such as OpenAI web search, image generation, and code interpreter; Anthropic search, fetch, and code execution; xAI search and code interpreter; and Google search, code execution, and URL context.
If a provider adds a new official tool, choose Custom Native Tool and add it manually.
| Field | How to Fill It | Purpose |
|---|---|---|
| Tool Key | Enter the unique tool identifier. | Identifies which official tool is selected. |
| Applicable Protocols | Select the protocols this tool supports. | One row can cover multiple protocols. |
| Type | Enter the tool type. | Used for display and upstream tool structure. |
| Payload JSON | Enter the provider-required tool object. | Stores the concrete tool configuration. |
| Default Enabled | Enable when needed. | Adds the tool to user defaults. |
| Configure | Expand and edit details. | Useful for payload adjustments. |
If the page warns that the current route protocol is not adapted, the tool may not fit the current model source protocol. Forced enablement passes the administrator configuration, so test before release.
When users hand-write tool options, the platform keeps only administrator-allowed native tools. Unknown tools, disallowed tools, and MCP/function-style injection do not pass through this native tool configuration.
Step 4: Configure Parameter Pass-Through#
Open Conversation Config in the admin console and find Option Pass-Through. This decides which user-defined model options may reach upstream calls.
| Policy | Behavior | Recommended Use |
|---|---|---|
| Allowlist | Only listed paths pass; all others are filtered. | Recommended production default. |
| Denylist | Most paths pass except denied or system-blocked paths. | Trusted internal users or debugging. |
| Disabled | User-defined options do not pass. | Strict control, cost sensitivity, or compliance. |
For production, start with Allowlist. Add the parameter paths from Step 2 to Model Parameter Allowlist. If a path applies only to a specific protocol, add it under that protocol; otherwise use default.
Before saving, check Live Preview. It shows what passes, what is filtered, and why, such as allowlist hit, denylist hit, or system block. System-dangerous fields are always blocked.
Step 5: Configure Native Tool Billing#
Open Usage Billing in the admin console and find Tool Pricing.
Enable Native Tool Billing to bill administrator-enabled native tools by the prices below. In self mode, usage is recorded only and users are not charged.
Tool prices are per call. A price of 0 means no separate tool charge. Model input and output produced around tool usage still follow model pricing. If upstream does not return a tool call count, the platform will not create a separate tool bill item for that tool.
Start by pricing tools with clear provider cost, such as search, code execution, or image-related tools, then verify the result with real conversations.
Step 6: Use Model Configuration in Chat#
After administrators configure defaults, parameter controls, and pass-through rules, users select the model in the chat page and open Model Configuration. The page provides both JSON configuration and visual configuration.
Visual configuration shows the parameter controls defined in model capabilities. Parameters marked as pass-through are allowed by the current pass-through policy; fields that are not allowed will not take effect even if users fill them in.
Before release, sign in as a normal user and confirm that defaults, labels, descriptions, options, and pass-through markers match expectations.
Step 7: Test and Verify#
After configuration, verify the full flow instead of only checking forms:
- Run model tests in Model Management to confirm the platform model and upstream sources work.
- Sign in as a normal user, create a conversation, select the model, and confirm the parameter panel looks correct.
- Change an allowed parameter and send a message to confirm behavior.
- Open Model Configuration and confirm defaults, controls, and pass-through markers look correct.
- Enable a native tool and send a message to confirm the model can actually use it.
- Check logs and Usage Billing for model usage, tool usage, and cost records.
For team rollout, open a small set of low-risk parameters and tools first, then expand after the records look stable.
Troubleshooting#
| Symptom | Common Cause | Fix |
|---|---|---|
| User cannot see a parameter | The model has no parameter control, or the model is not exposed to the user. | Add the control in the Parameters tab and check model status and access scope. |
| Parameter is visible but has no effect | The parameter path is not allowed by pass-through. | Check allowlist or denylist rules and confirm with Live Preview. |
| Native tool does not appear user-side | The tool is not enabled, not default enabled, or protocol does not match. | Check the Native Tools tab, applicable protocols, and default enabled state. |
| Native tool works but is not separately billed | Native tool billing is off, price is 0, or no tool call count was returned. | Enable billing, set a price, and check usage records. |
| User-written tool option is ignored | It is not an administrator-allowed native tool, or it is MCP/function-style injection. | Enable the official tool in model capabilities; external tools should use MCP configuration. |
Practical Tips#
Use allowlist pass-through in production. Expose only parameter controls users can understand and safely adjust. Open native tools gradually, starting with low-risk, explainable, cost-controlled tools. Keep support, permission, and billing as separate decisions so new provider abilities can be adopted without weakening platform governance.