One million downloads special 🥳

Rig has reached more than one MILLION downloads on crates.io!! Yayyy!! First of all, a giant THANK YOU to all our users, contributors, and community members who have kept Rig active and in motion, you’re all awesome!

Wait, but who am I? You may be asking, as many of you have grown accustomed to Josh being the lead maintainer of Rig. Well let me introduce myself, I am gold-silver-copper, an AI and open source aficionado, and 2 months ago I inherited the position of lead Rig maintainer from Josh, thanks Josh!!

As someone who loves Rust, open source, and AI, getting the chance to work on Rig professionally is an absolute dream. A great big THANK YOU to 0xPlaygrounds for giving me this opportunity of a lifetime. Oh and a bit about the 0xPlaygrounds team, everyone there is truly phenomenal. They are all extremely knowledgeable not just about AI, but have expertise in a wide array of domains (just to give you a taste of what I mean, our CEO is a Nuclear Physics researcher, our CPO is an Ontologist, and our CTO plays Dwarf Fortress). I really don’t think I could have asked for better coworkers.

Taking Over Maintenance

Now back to Rig. When I first became the lead maintainer, I had used Rig before for a few projects, but I was by no means an expert on the codebase. According to tokei Rig currently has 150k lines of code, which is a fairly large codebase, so where to start? Modifying any of the code worried me a bit as it could have unforeseen consequences, and Rig at the time didn’t have an easy way to test behavior against providers other than through running examples. So for my first major task, I decided to completely overhaul the testing system!

Better Testing

The first step in this process was fairly easy, moving examples to be live tests, duplicated for each provider. This was already a big help, as I could now run dozens of live regression tests with just a single console command, but it was not ideal. Each run cost tokens, and well, in this economy, tokens ain’t cheap. Secondly, running live tests in parallel would instantly rate limit me, but running them serially could take multiple minutes — not fun when you’re trying to iterate quickly.

The solution to this problem is a VCR-style recording system. It’s simple but very powerful: instead of running a test against a live provider each time, we can just run it once, record all the HTTP traffic, and subsequent runs can be tested against the recordings. Genius!!! Sadly, none of the existing Rust VCR solutions fit our needs exactly, but no problem, we just wrote our own!

Rig now has more than 300 such VCR tests (with more on the way), and they can run in CI for every pull request. Needless to say, this is a major boon for stability: it gives us much wider regression coverage, better testing in CI, and much safer refactoring. Personally, having the VCR system implemented in CI has dropped my cortisol levels noticeably!

Cleaning Up the Repository

The next major improvement that I made to Rig is less impactful in terms of code, but is important in terms of aesthetics. Having been involved with open source for quite a while now, I’ve seen my fair share of projects. Somewhat subconsciously, I’m always more drawn to projects which have a neat repository, a standardized structure, and good docs.

Rust has a reputation for having one of the best open source communities and very high standards for open source projects, so the bar is quite high. One of the best exemplars of a Rust project that easily jumps over that bar is bevy, an open-source game engine written in Rust. So when I began properly creating the Rig facade crate, of course I pretty much copied the structure of bevy wholesale. For comparison here is a before and after:

Ahh, now that’s much easier on the eyes. So this ticks the neat repo and standardized structure boxes for me, but what’s next? While Rig does have a lot of good documentation, some of it is outdated, and other parts are scattered across various sources (blog posts, docs.rs, the docs, the book). Part of what I will be doing in the upcoming weeks is centralizing and updating as many of these resources as possible. After all that is done, I think I could call Rig truly beautiful.

While all this polish matters, it’s not as important as the cold hard code that makes up the project, and the functionality that it provides. So what is the future direction of Rig?

Local Models

Rig actually already supports local models through Ollama! But that still requires you to have an inference server running, which is not ideal, especially for WASM and edge devices. The Rust ecosystem has a fantastic crate called candle, which was created by the wonderful team at Hugging Face. This crate allows you to run inference on models directly, and has great WASM support. We plan to create a rig-candle integration crate which will finally allow you to use local models in Rig without requiring a server.

This unlocks a whole new deployment dimension for Rig. Local and smaller models have improved greatly over the last few years, and you can do quite a number of impressive things with them now. Coupled with Rig, this allows for truly serverless deployment of AI agents, which don’t need an API key or external server to communicate with. AI agents that will work forever, in the browser or on an edge device, for no cost other than electricity. Pretty awesome and made possible by the amazing Rust ecosystem, great!

Harnesses

Harnesses have been a hot topic in the AI space recently. Code and computer assistants are one of the areas in which LLMs have been really successful. While there is no solid definition as to what a harness is, it can be thought of as the interface between an LLM and a computer, the layer that provides the tools for accessing the internet, running scripts, managing context, and everything else that tools like Codex or OpenClaw do. In particular, projects like Pi have given harnesses extra attention by showing that a minimal but hackable harness can be very effective.

Rig is already a great choice for integrating into a harness. It has support for tool calls, vector search, many providers, streaming, telemetry, and more. In fact, there’s already a number of projects that use Rig as part of their harness stack such as VT Code, IronClaw, and Con. We even have our own proprietary harness that powers Ryzome.

But as always, we can be even better! We are planning a number of improvements that can make harnesses built with Rig even more powerful. We will expand the current prompt hook system so that you can observe and modify execution at every single step of the agent and tool-call loop. We will improve the internal RAG dynamic context system so that users can have full control over their inputs and outputs, fine-tuned to their exact needs. The tool server system will be migrated completely to rmcp, so that it becomes completely standards-compliant (the Rig tool server system was originally implemented before MCP was even a thing). Rig’s goal is to give total control and ultimate flexibility to its users, while managing all the annoying and bug-prone boilerplate for them.

Closing Thoughts

These two months of working on Rig have absolutely flown by. The AI scene is crazy and I love it. There’s A LOT more that is in the works but I can’t share quite yet. Wanna chat? Join our Discord.

We build Rig, Rig builds us!

Yours truly,
gold-silver-copper