Skip to main content

Model catalog

Model Catalog maintains models offered by the enterprise.

Model Catalog maintains models offered by the enterprise. Primary models are selected for everyday work. Specialized models serve vision, speech, and multimedia tasks. After configuring a connection, check whether model policies allow the intended members to use it. Only enterprises with BYOK (bring your own key) enabled can add custom models. Otherwise, Catalog provides official models without the custom-model add capability. Check QwenWork credits separately from external model charges; external usage and costs are recorded by the model provider.

View and configure primary models

  1. Open AI → Models → Catalog and select Main models.
  2. Find a model and check its source, maximum context size, description, and enabled state. Official primary models are provided by the platform; some state actions cannot be changed.
  3. Open Configure and edit the display name, description, and context limit where permitted.
  4. Save, check the list, then verify the name and description in the client.
 Admin console: check model sources, context limits, and enabled states.

Add a custom primary model

Prerequisites: enterprise BYOK is enabled and the current administrator has model management permission. Obtain the complete endpoint, API Key, model key, and supported capabilities from the provider. The API Key is the calling credential. The server-side model key identifies the model in requests and is different from its display name.
  1. In Main models, click Add custom model.
  2. Enter the Full endpoint that directly accepts Chat Completions requests, such as https://api.example.com/v1/chat/completions. A website home page or base URL may not work.
  3. Enter the API Key, enterprise display name, and server-side model key. Select a context limit supported by the service.
  4. Configure reasoning, vision, and other capabilities to match the model. Do not enable capabilities the provider does not support merely to show an entry.
  5. If passing third-party user IDs to the model, first confirm that the enterprise needs to transmit that identifier.
  6. Click Test and save. Correct connection or credential errors and retest. After success, check the enabled state and access policies.
Private HTTP(S) endpoints, IP addresses, and custom ports may be entered as provided by the service, but the calling network must be able to reach them. A newly saved custom model starts disabled; enable it manually in the list. An enabled custom model permits display-information changes only. Disable it before changing its endpoint, API Key, upstream model name, or retesting its connection. When changing the endpoint:
  • Changing the scheme, host, or port requires reentering the API Key.
  • Changing only the path under the same scheme, host, and port may retain the stored credential.
Do not submit the displayed mask as an actual key.
Admin console: distinguish the endpoint, display name, and server-side model key.

Configure specialized models

  1. Switch to Specialized models and select vision, speech input, speech polishing, image generation, video generation, or music generation.
  2. Check the current official or enterprise model. Enterprises with BYOK enabled can add custom specialized models using the group's add action, required fields, and test.
  3. After switching the effective model, run a relevant task. For vision, upload an image; a plain-text question does not test vision capability.
 Admin console: configure the model for each specialized capability.

Update credentials or remove a model

After changing credentials, retest, save, and check an actual call. Deleting a custom primary model also removes its references from policies. Verify that affected members have another usable model. For a specialized model currently in use or restricted from deletion, switch to an available replacement as the page instructs.

If a model is missing in the client

Check that the model is enabled, the member's matching policies allow it, and no blocklist excludes it. A successful connection test covers that configuration test, not every member's access. Return to: Models overview