- 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.
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.
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.Update Model
Update an existing model configuration.Delete Model
Delete a custom model configuration.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.2. Use Recommended Models by Default
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