Skip to content
Get Started

Integrations

Rig connects to the outside world through two kinds of integrations: model providers (LLM and embedding APIs) and vector stores (databases for semantic search and RAG). Both follow the same design goal — keep rig small and dependency-light, and push heavier integrations into optional modules or companion crates.

rig contains the foundational abstractions for building with LLMs and deliberately avoids pulling in large dependency trees. Integrations are layered on top:

  • Model providers live inside rig under the providers module. They are thin clients over each vendor’s HTTP API, so they add few dependencies and ship with the core crate.
  • Vector stores live in separate companion crates (for example rig-mongodb, rig-qdrant). Each manages its own database driver and dependencies, so you only pay for the ones you use. The in-memory store is the exception — it ships in rig as a default implementation.

Every provider exposes a Client that builds completion models, embedding models, and higher-level constructs like agents and extractors. A minimal example with OpenAI:

use rig::prelude::*;
use rig::providers::openai;
// Read OPENAI_API_KEY from the environment
let client = openai::Client::from_env()?;
// Build an agent directly from the client
let agent = client
.agent("gpt-5.5")
.preamble("You are a helpful assistant.")
.build();

Rig ships clients for a wide range of providers:

  • Anthropic
  • OpenAI
  • Azure OpenAI
  • Cohere
  • DeepSeek
  • EternalAI
  • Google Gemini
  • Galadriel
  • Groq
  • HuggingFace
  • Hyperbolic
  • Mira
  • Moonshot
  • Ollama
  • OpenRouter
  • Perplexity
  • TogetherAI
  • xAI

Because many of these expose OpenAI-compatible APIs, the same client patterns apply across most of them. See Model Providers for the shared vocabulary (model vs. provider vs. client), how to configure any provider, and links to per-provider pages.

Vector stores implement the VectorStoreIndex trait from rig, so RAG pipelines and dynamic-context agents work the same regardless of which database backs them. Each store is a companion crate:

An in-memory store is included in rig for prototyping and tests — no extra crate required.

Each companion crate:

  • Implements the VectorStoreIndex trait from rig
  • Manages its own database driver and dependencies
  • Provides store-specific configuration and index options
  • Ships its own examples and documentation

See Vector Stores for the shared concepts (VectorStoreIndex, InsertDocuments, VectorSearchRequest, EmbeddingsBuilder) and a comparison of the available stores.