Skip to main content
The Models Service provides programmatic control over the lifecycle and configuration of Large Language Models (LLMs) within the Kubiya platform. It serves as the main interface for discovering, configuring, and managing both standard and custom LLMs, allowing teams to optimize their AI-powered workflows for performance, cost, and compliance. The Models Service makes it easy to:
  • List and filter available models by provider, runtime compatibility, and recommendation status.
  • Retrieve detailed model metadata such as capabilities, pricing, and context window.
  • Create and update custom model configurations for private, fine-tuned, or organization-specific models.
  • Manage the model lifecycle (enable/disable, recommend, update, or delete) so only approved models are available for use by agents and workflows.
  • Audit and report on model availability, usage, and provider coverage.
This service is especially valuable for platform administrators and advanced users who need to balance innovation with governance, cost control, and security. By using the Models Service, you can ensure that your agents and workflows always use the most appropriate, cost-effective, and compliant LLMs for your business needs.
For conceptual information about models and how they’re used in agents, see Agents Core Concepts.

Overview

The Models Service provides a set of high-level methods designed to be intuitive and flexible, supporting a wide range of operational and administrative tasks:
  • list(): Retrieve all available LLM models, with filtering options for provider, runtime, recommendation status, and pagination. This is the primary entry point for discovering which models are available in your environment.
  • get(model_id): Fetch detailed metadata for a specific model, using either its unique identifier (UUID) or its value string (e.g., “kubiya/claude-sonnet-4”). This is useful for inspecting model capabilities, pricing, and configuration before use.
  • create(model_data): Register a new custom model configuration. This is typically used for private or fine-tuned models that are not available from public providers, and requires admin privileges.
  • update(model_id, model_data): Modify the configuration of an existing model, such as updating its description, pricing, or enabled status. This allows organizations to keep model metadata up to date as providers change their offerings.
  • delete(model_id): Remove a model from the registry. This operation is restricted to ensure that no active agents are using the model at the time of deletion.
  • get_default(): Retrieve the default recommended model for general-purpose use. This is especially useful for agents or workflows that do not have strict model requirements and should use the platform’s best-practice recommendation.
  • list_providers(): List all unique LLM providers currently available in your environment. This helps with auditing, reporting, and provider-specific filtering.
By using these methods, you can build robust, dynamic workflows that adapt to changes in the LLM landscape, enforce organizational policies, and provide a seamless experience for both developers and end-users. The following sections provide practical guidance, detailed examples, and best practices for leveraging the Models Service effectively in your own projects.

Quick Start

List Models

List all available LLM models with optional filtering.

Basic Listing

Filter by Provider

Filter by Runtime

Filter by Recommendation

Include Disabled Models

Pagination

Get Model Details

Retrieve detailed information about a specific model.

By Model ID

By Model Value

Extract Model Information

Get Default Model

Get the default recommended LLM model.

List Providers

Get all available LLM providers.

Create Custom Model

Create a new custom LLM model configuration.
Creating models requires organization admin privileges. This operation is typically used for custom/private model deployments.

Update Model

Update an existing model configuration.

Delete Model

Delete a custom model configuration.
Deleting a model affects any agents configured to use it. Ensure no active agents depend on the model before deletion.

Practical Examples

1. Find Best Model for Use Case

Use this approach when you want to programmatically select the most suitable LLM for a specific task type, such as code generation, cost-sensitive operations, or handling large context windows. This is helpful for dynamic agent workflows that need to adapt to different requirements on the fly.

2. Compare Model Capabilities

This example is useful when you need to evaluate and compare multiple models side by side, such as when deciding which model to standardize on for your team or when presenting options to stakeholders. It helps you quickly assess differences in context window, provider, and cost.

3. Model Cost Calculator

Use this pattern to estimate the cost of running a specific workload on a given model. This is valuable for budgeting, cost tracking, or when you want to compare the financial impact of different model choices before running large jobs.

4. Audit Model Usage

This example demonstrates how to generate a summary report of all available models, including how many are enabled, recommended, or available from each provider. It’s helpful for platform administrators who need to audit model inventory or prepare usage reports.

Error Handling

When working with models, you may encounter errors such as requesting a non-existent model or losing access to a provider. This example shows how to handle such errors gracefully, ensuring your application can recover or provide fallback behavior if a model is unavailable.

Best Practices

Follow these best practices to make your use of the Models Service more robust, efficient, and maintainable. These patterns help you avoid common pitfalls and ensure your code is resilient to changes in model availability or configuration.

1. Cache Model Information

To reduce API calls and improve performance, cache model information locally after the first retrieval. This is especially useful in applications that repeatedly access the same model details.
Unless you have a specific requirement, always use the recommended model. This ensures you benefit from the platform’s best-practice guidance and reduces the risk of using deprecated or suboptimal models.

3. Validate Model Before Use

Before using a model, check that it is enabled and supports the capabilities you need. This prevents runtime errors and ensures your workflow only uses models that meet your requirements.

4. Handle Model Unavailability

Always provide a fallback mechanism in case your preferred model is unavailable. This keeps your application resilient and ensures continuity of service even if a model is removed or temporarily inaccessible.

API Reference

Methods

Model Object Structure

Next Steps

Runtimes Service

Manage agent runtime environments

Agents Service

Create and manage agents

Best Practices

SDK best practices guide