# Rig: A Rust Library for LLM Applications with a Unified Provider Interface > Rig is a Rust crate that abstracts over 20 model providers and 10 vector stores behind a single interface, supporting multi-turn agentic workflows and WebAssembly targets. The project ships breaking changes frequently and documents migration paths, a trade-off teams should weigh before adopting it in long-lived services. **0xPlaygrounds/rig** — ⚙️🦀 Build modular and scalable LLM Applications in Rust - Repository: https://github.com/0xPlaygrounds/rig - Website: https://rig.rs - Stars: 8,761 · Forks: 979 - Language: Rust - License: MIT - Published: 2026-09-09 · Updated: 2026-09-09 · Language: en - Canonical page: https://hysenlabs.com/projects/0xplaygrounds-rig ## What Rig Solves and Who Uses It Writing Rust code that calls language models without a unifying library means authoring separate HTTP clients for each provider, managing retries and streaming protocols by hand, and rebuilding vector-store connectivity from scratch whenever the integration list changes. Rig addresses exactly that gap. It targets Rust engineers building services where compile-time safety, low runtime overhead, and native Rust interop are requirements rather than preferences. The repository documents a broad user list. St Jude uses Rig for a chatbot inside proteinpaint, a genomics visualisation tool. VT Code, a Rust terminal coding agent with Tree-sitter and ast-grep for code intelligence, uses Rig to simplify LLM calls and implement a model picker. Con, a GPU-accelerated terminal emulator, relies on Rig as the provider abstraction layer for its integrated coding agents. On the infrastructure side, Dria uses Rig in a decentralised AI network compute node, and ilert uses it as the multi-provider abstraction in an agentic LLM proxy for incident management. These are not toy examples: they represent production deployments with domain-specific requirements that Rig's uniform interface handles. ## The rig-core and rig-agent Architecture Rig separates portable provider contracts from agent orchestration, a design choice that matters when you want to embed the provider layer in a WASM target but keep full orchestration logic server-side. rig-core contains the provider-neutral foundation: completion model traits, embedding model traits, portable and contextual tool contracts, memory and vector-store contracts, and built-in provider mappings. Nothing in rig-core depends on a specific runtime. rig-agent contains the orchestration layer: the classic builder pattern, prompt and streaming traits, typed lifecycle hooks, the live tool registry, extraction, and the serialisable AgentRun state machine. The AgentRun machine supports ECS-style checkpointing. The ECS checkpoint stores execution state and handler descriptors, not provider launch recipes. Restoration explicitly validates the complete handler set against the saved contracts, and effect replay uses recorded handlers without requiring a live provider connection. This makes it possible to debug or replay partially executed agent runs without re-establishing provider credentials. The root rig crate re-exports both layers under their familiar paths, so most application code adds a single dependency and sees a coherent API surface. ## Installing Rig and Navigating the Examples Directory Rig is published on crates.io under the name rig and is distributed under the MIT license. Add it as a dependency in the [dependencies] section of your Cargo.toml, then run cargo build. The README does not document a standalone quickstart code block. It references the official docs at rig.rs/docs and the crate API reference at docs.rs for step-by-step guidance. The examples/ directory in the repository contains independent Cargo packages covering specific patterns: - examples/agent/ and examples/agent_autonomous/ for basic and autonomous agent setups - examples/agent_with_tools/ and examples/agent_with_tools_otel/ for tool use with and without OpenTelemetry tracing - examples/agent_with_memory/ and examples/agent_with_memory_streaming/ for persistent memory - examples/agent_stream_chat/ for streaming responses - examples/agent_with_human_in_the_loop/ and examples/agent_with_approval_policy/ for approval workflows - examples/agent_with_retry_hook/ for configuring retry behaviour - examples/agent_prompt_chaining/, examples/agent_parallelization/, and examples/agent_routing/ for multi-step orchestration patterns Each example is a self-contained Cargo project. Clone the repository, enter the relevant example directory, and run cargo run to start. This is the fastest path from a fresh checkout to a working agent. ## Provider Coverage, Vector Stores, and Additional Capabilities Rig advertises more than 20 model providers accessible through a single completion model trait and more than 10 vector store integrations accessible through a single vector-store contract. Because both are interface-based, swapping a provider requires changing the model construction call rather than restructuring agent logic. Beyond text completion and embedding, the README documents support for transcription, audio generation, and image generation model capabilities, all under the same unified interface. Rig also claims full GenAI Semantic Convention compatibility, meaning its traces and spans follow the OpenTelemetry specification for generative AI workloads, which matters if your observability pipeline expects standard attribute names. The examples/agent_with_tools_otel/ directory covers the practical integration of OTel tracing into an agent that uses tools, giving a concrete starting point for teams that need distributed traces across LLM calls. ## WebAssembly Support and Target Constraints Rig supports the wasm32-unknown-unknown target for the portable core and the classic agent runtime. This makes it possible to run the provider and basic orchestration layers inside a browser or an embedded WASM environment. The README notes that the full target support matrix is in crates/rig-agent/README.md under the target support heading. Two constraints are stated explicitly. WASI (the WebAssembly System Interface) is not supported. The rig-rmcp component, which handles MCP (Model Context Protocol) connectivity, is native-only and will not compile to any WASM target. Teams building browser-based LLM tooling should confirm which Rig crates are included in their dependency graph before targeting WASM, since a transitive dependency on rig-rmcp will break the build. ## Limitations: Breaking Changes and the Migration Cost The README opens with an explicit warning: future updates will contain breaking changes. This is not a vague disclaimer. Looking at the release history, v0.40.0 shipped on 2026-07-11, v0.41.0 on 2026-07-28, and v0.42.0 on 2026-08-17. Three major version increments in just over five weeks is a fast cadence for a library with a complex API surface. The repository includes a MIGRATING.md file and promises to annotate changes with migration paths, but following those paths on every minor update is a real ongoing cost. Rig is also a pure Rust library. Engineers working in Python, Go, or any other language cannot use it directly. If the requirement is Python-based LLM orchestration, LangChain provides a Python framework with a large integration ecosystem and a significantly slower breaking-change cadence. LangChain targets Python workflows and does not compile to Rust; the two tools occupy different language environments entirely. A second practical limitation is documentation depth. The README points to rig.rs/docs and docs.rs for detailed guidance, and the examples/ directory fills in patterns that the written documentation does not cover. If you hit an edge case not addressed by either, the GitHub issue tracker and Discord are the primary support channels. ## Maintenance Status and License The last push to the repository was on 2026-09-28, confirming active development. The three most recent releases shipped in July and August 2026, showing a roughly bi-weekly release rhythm. The CHANGELOG.md documents per-release changes, and the awesome-rig repository on GitHub aggregates community projects, integrations, and production deployments. Rig is licensed under the MIT license, which permits commercial use, modification, distribution, and private use without requiring source disclosure. The MIT license imposes no restrictions on the providers or vector stores you connect through Rig, though each provider's API terms of service govern usage independently of the library license. ## Conclusion Rig suits Rust teams that need a production-grade LLM abstraction and are willing to track a fast-moving library with announced breaking changes. Teams that need a stable API for a long-lived service should consult MIGRATING.md before committing to a version. Engineers working outside Rust should look elsewhere: Rig offers no Python bindings and does not target WASI. The right first step is to clone the repository, read MIGRATING.md alongside the CHANGELOG.md, and confirm that your target runtime appears in the crates/rig-agent/README.md target support matrix. ## FAQ ### How does Rig differ from LangChain for building LLM applications? Rig is a Rust library and compiles to native code or WebAssembly. LangChain is a Python framework. The two do not overlap in language environment. Rig's unified interface covers more than 20 providers under a single Rust trait, while LangChain targets Python workflows and has a different integration model. ### Does Rig support WebAssembly targets? Rig supports the wasm32-unknown-unknown target for the portable core and the classic agent runtime. WASI is not supported, and the rig-rmcp MCP component is native-only. The full target support matrix is documented in crates/rig-agent/README.md. ### How should teams handle Rig's breaking changes between versions? The repository includes a MIGRATING.md file that documents upgrade paths. The README warns explicitly that future updates will contain breaking changes, and the project annotates each breaking change with migration guidance. Teams should read MIGRATING.md before upgrading and pin to a specific version in production until they have verified the migration path. ## Sources - [0xPlaygrounds/rig on GitHub](https://github.com/0xPlaygrounds/rig) - [License: MIT](https://github.com/0xPlaygrounds/rig/blob/main/LICENSE) - [Project website](https://rig.rs) - [README](https://github.com/0xPlaygrounds/rig/blob/main/README.md) - [Releases](https://github.com/0xPlaygrounds/rig/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xplaygrounds-rig