Models
Models generate test data for LLM applications and act as LLM judges during evaluation. A single function, get_model, creates instances across every supported provider.
Using the get_model function
Call get_model to create a model instance. With no arguments it returns the default Rhesis model.
To use a different provider, you can pass the provider name as an argument. This will use the default model for that provider.
Supported providers (highlights):
rhesis- Rhesis-hosted default modelsopenai,anthropic,gemini,vertex_ai- major hosted providersazure_ai- Azure AI Studio deployments via LiteLLMazure- Azure OpenAI deployments via LiteLLMlitellm_proxy- OpenAI-compatible LiteLLM Proxy endpointopenrouter,mistral,cohere,groq,perplexity,replicate,together_ai,meta_llamaollama,huggingface,vllm- local/self-hosted options
To use a specific model, provide its name in the format provider/model_name:
The above code is equivalent to:
Provider-specific connection options
Some providers accept extra connection parameters:
| Provider | Required fields | Optional fields | Notes |
|---|---|---|---|
litellm_proxy | model_name | api_base, api_key | api_base defaults to LITELLM_PROXY_BASE_URL env var or http://0.0.0.0:4000 |
azure_ai | model_name, api_base, api_key | — | api_base/api_key can be supplied via AZURE_AI_API_BASE/AZURE_AI_API_KEY env vars |
azure | model_name, api_base, api_key | api_version | api_base/api_key/api_version can be supplied via AZURE_API_BASE/AZURE_API_KEY/AZURE_API_VERSION env vars |
Direct import
Alternatively, you can access models by importing the model class directly. When you provide a model name as an argument, that specific model will be used. If no model name is provided, the default model for that provider will be used.
Generating text
All models share the same interface. The core method is generate, which takes a prompt and an optional Pydantic schema for structured output. Language-model providers are async-first:
| Method | Execution style | Typical use |
|---|---|---|
generate(...) | Synchronous wrapper (bridges to a_generate) | Scripts and notebooks |
a_generate(...) | Native async call | Async services, workers, concurrent pipelines |
generate_batch(...) | Multi-prompt batch call | High-throughput generation |
If your application is already async, call a_generate(...) directly.
a_generate(...) retries transient failures — connection errors, timeouts, and HTTP 429/500/502/503/504 from either requests or the provider SDK — with one initial attempt plus three retries and exponential backoff with jitter. Client errors (400, 401, 403, 404) are never retried.
Pass provider-specific keyword arguments through generate(...) or a_generate(...): stream=True enables token streaming on providers that support it, and schema requests structured output.
Multi-turn messages
Pass a pre-built messages list to a_generate(...) when you already have
conversation history. When messages is provided, prompt and system_prompt
are ignored because the full chat payload is supplied by the caller.
Use either messages or prompt plus system_prompt for a single call. Keeping
the two modes separate avoids accidentally dropping system instructions when a
multi-turn history is already assembled.
Generate text using prompt only:
Generate structured output using schemas:
Batch Processing
generate_batch processes multiple prompts in parallel.
Basic batch generation:
Batch generation with structured output:
Generate multiple completions per prompt:
Use batch generation for large test sets, multi-input evaluations, or generating variations. It runs on LiteLLM-based providers and rhesis language models.
Using models with synthesizers and metrics
Pass a model to a synthesizer or metric to control which LLM does the work:
Saving models to the platform
You can save an LLM configuration to the Rhesis platform as a Model entity. This allows you to:
- Store model configurations centrally for team sharing
- Set default models for test generation and evaluation
- Retrieve configurations across different scripts
You can also retrieve saved configurations and convert them back to LLM instances:
Tracking token usage
Every provider reports token counts after each call. Counts are normalized across providers into
three keys — input_tokens, output_tokens, total_tokens — so you never have to know whether a
given API calls them prompt_tokens, promptTokenCount, or something else.
Pass on_usage to watch one model:
To count tokens across an application, register a process-wide sink instead. It receives usage from every model in the process, including models built by code that knows nothing about usage tracking, so there is no per-call-site wiring to forget:
The sink fires in addition to any on_usage, not instead of it, so attaching a listener to one
model does not detach it from your accounting. Batch calls report one summed total rather than one
emission per prompt. Both callbacks run inside the generate call, and anything they raise is logged
and swallowed — a broken counter never breaks the LLM call that produced the count.
BaseLLM.usage_metered is an optional flag for applications that bill for tokens. The SDK never
sets or reads it; stamp it where you resolve models to record whose credentials paid for a given
call, since the same provider can be billable or not depending on whose API key it uses.
Writing a custom provider? Call self._emit_usage(raw_usage) wherever you parse the provider’s
response, passing the payload unchanged — normalization happens for you. Use
self._emit_usage_batch(...) for batch methods. A provider that skips this reports zero tokens
forever, and nothing else will fail to tell you.
Embedders
Embedders generate vector representations (embeddings) of text, which are useful for semantic search, similarity comparison, and clustering tasks.
Using the get_model function
Call get_model with an embedding model name; it detects the type and returns an embedder.
To use a specific model, provide the model name:
The above code is equivalent to:
Direct import
You can also import the embedder class directly:
Generate embeddings
All embedders share a consistent interface with two main methods:
Generate embedding for a single text:
Generate embeddings for multiple texts:
Configuring embedding dimensions
Some embedding models (like OpenAI’s text-embedding-3 family) support configurable output dimensions. Smaller dimensions reduce storage and computation costs while maintaining most of the semantic information.
See the Model entity documentation for more details on managing model configurations.