Skip to main content

Model Capabilities and Admin Configuration

ZaiDrama is operated as a unified platform. Regular users do not request, paste, or rotate third-party API keys. Platform administrators maintain provider credentials, model routing, capability declarations, concurrency, and recovery policy. Users select the capabilities currently exposed for their project or task.

1. Choosing capabilities as a user​

The settings and generation steps show currently available text, image, video, and TTS capabilities, including supported aspect ratios, durations, reference images, first/last frames, and audio options. Use the runtime capability registry as the source of truth; do not infer support from a model name or old screenshot.

For a first project, validate style and capability with a few shots before expanding the scope. Confirm a proposal or credit notice before starting generation.

2. Capability boundaries​

Capabilities are declared per model rather than inferred from a provider as a whole:

  • text and structured output;
  • image generation, editing, and multiple references;
  • text-to-video, image-to-video, and reference video;
  • first/last frames, extension, fixed seeds, and native audio;
  • TTS voices, speed, and output formats;
  • supported duration, resolution, aspect ratio, concurrency, and task queries.

Request construction and execution-time allowlists belong to the corresponding backend. Undeclared capabilities fail clearly instead of silently selecting a different model.

3. Platform administrator configuration​

Administrators maintain credentials and key rotation, model IDs and endpoints, capability flags, limits, defaults, failover, regional policy, credit mappings, and call audits. After saving a configuration, verify connectivity, structured output, image generation, video creation/query, TTS, errors, cancellation, and retries with a small task.

4. Custom providers​

Custom endpoints are not exposed to regular users. When the platform adds a provider or internal gateway, administrators perform security review, protocol adaptation, capability registration, and real-task validation. Never put provider keys, internal addresses, or unredacted responses in frontend code, documentation, issues, or chat.

5. Credits and usage​

Users rely on the account center for subscription, credits, and usage. The platform records task capabilities, states, and call audits; provider settlement, credit deduction, and failure rollback are operated centrally. Keep a project/task ID and contact support for credit issues instead of repeatedly submitting work.

6. Troubleshooting​

User troubleshooting​

Check the task error, selected model, reference inputs, and account credits. A missing model may be temporarily unavailable or incompatible with the route; a long queue is centrally scheduled; a failure should be retried only for the affected work.

Administrator troubleshooting​

  • 401/403: check service credentials, region, model permissions, and bridge authentication.
  • 429: check upstream limits, worker concurrency, and the platform queue.
  • Timeout: check DNS, TLS, proxy, task queries, and result downloads.
  • Connection succeeds but generation fails: run a real small task and verify media capability and endpoint.
  • Capability validation fails: synchronize model declarations, backend allowlists, request construction, and admin UI.

An upstream read timeout can mean a task was already created. Check the task ID before recovering or retrying to avoid duplicate charges.

7. Maintenance principles​

  • Keep current model lists in the platform settings, not a static public matrix.
  • When capabilities, parameter limits, or credit mappings change, update the registry, backend, admin UI, tests, and documentation together.
  • Public docs explain user-visible capabilities and support paths; credentials, hosts, and provider contracts belong in restricted operational runbooks.