AI model capabilities

Dynamic source of truth

The production version of this page should read from a sanitized public catalog derived from the admin provider and model settings. The admin catalog records provider configuration, discovered models, client-visible flags, model groups, capabilities, modalities, context windows, lifecycle status, and sync timestamps. The docs site should reflect those settings rather than hard-coding a model list.

Public model fields

The public catalog should show only customer-safe fields: display name, provider family, model type, capability family, input and output modalities, context window, availability status, visible-to-clients status, and last refreshed time.

• Text and reasoning: planning, implementation, review, and debugging.
• Vision: screenshot review, UI QA, diagram interpretation, and multimodal evidence.
• Voice and audio: transcription, spoken workflows, and future operator interfaces.
• Embeddings and rerank: memory search, document retrieval, code recall, and semantic routing.
• Image and video: creative, inspection, and media workflows where enabled.

Private fields

The public docs must not expose API keys, provider balances, wholesale costs, margin settings, internal admin notes, organisation-scoped identifiers, private routing logs, or unapproved provider health detail. Those belong in authenticated admin views.

Capability families

Different models unlock different opportunities. Text and reasoning models plan and implement. Vision models inspect screens, diagrams, and UI states. Voice models can support spoken workflows. Embedding models power retrieval, search, and memory.

• Reasoning and coding: planning, implementation, review, and debugging.
• Vision: UI QA, screenshot review, diagram interpretation, and multimodal evidence.
• Voice: spoken assistant workflows, transcripts, and future operator interfaces.
• Embeddings: memory search, document retrieval, code recall, and semantic routing.

What model choice means

Having multiple models to hand means the platform can choose the right tool for the job: lower-cost models for routine work, stronger reasoning models for hard tasks, vision models for visual evidence, and fallback models when a provider is degraded.

Model routing

Model routing means choosing the right model capability for the task. Kaidera should route by capability, availability, cost expectation, quality need, and customer configuration rather than treating every AI request as a generic text-model request.

Provider setup

Administrators configure which providers and model sources are available to the organisation. Depending on the customer setup, this can include platform-managed providers, customer-owned provider accounts, or enterprise-managed access paths.

BYOK

Bring your own key lets an organisation use its own supported provider account while keeping Kaidera orchestration, workers, memory, review gates, and governance in the product journey.

Model groups

Model groups let administrators organise models by capability or business use. For example, a customer may have a preferred reasoning group, a visual review group, a lower-cost routine group, and a restricted enterprise group.

Managed model programs

For specialised or regulated use cases, Kaidera can support managed model programs through partners. These can include fine-tuning, curated training data preparation, dedicated endpoints, reserved or on-demand accelerator capacity, geographic controls, and isolated deployment options.

Fine-tuning and training data

Fine-tuning should be treated as a managed business workflow, not a casual setting. Customers should define the use case, prepare approved data, review expected behaviour, test results carefully, and keep human approval around sensitive outputs.

What users configure

Most users should choose desired capability and business outcome. Customer admins should control provider access, model visibility, groups, fallback behaviour, project restrictions, worker defaults, and whether managed model programs are available.

Future live catalog behaviour

When the live catalog is wired, this docs page should show a last-updated timestamp, visible model totals, capability filters, and plain-language explanations of what each enabled model family makes possible. If the admin catalog changes, the docs should update through a sanitized export or public read API without exposing the admin API directly.

What to avoid

Do not promise a fixed list of model names on a public docs page unless it is backed by the live visible catalogue. Model availability changes quickly, and the customer-safe answer should come from current admin/provider configuration.

Read next

Read Provider setup and BYOK for administrator setup details. Read Custom AI workers when choosing model capabilities for a specific business role.