This update looks like the kind of “small” change that quietly decides who gets to build the next wave of AI apps—and who gets stuck duct-taping the basics together.
Rig v0.35 isn’t flashy in the way people on social media like. It’s not a new model. It’s not a big demo. It’s plumbing. And plumbing is where most AI products either become reliable tools or stay stuck as toys.
From what’s been shared publicly, Rig v0.35 ships a few concrete improvements: better tool-calling compatibility across different model providers, more reliable streaming, dynamic model discovery (so you can list models programmatically from providers like Ollama, Anthropic, OpenAI, and Gemini), plus adding GPT Image 1.5, and fixes that keep conversation history intact during multi-turn chats.
If you build anything serious with AI, you already know why this matters. Tool calling is the difference between a chatbot that talks about doing something and a system that actually does it—safely, repeatedly, without breaking the moment a provider changes a detail. Streaming reliability is the difference between “this feels fast and alive” and “this feels broken and users bounce.” Preserving conversation history is the difference between “helpful assistant” and “confused goldfish.”
My take: Rig is making a bet that the winning AI experience won’t be defined by one model. It’ll be defined by the layer that makes models usable in the messy real world—where you switch providers, mix capabilities, and still need the whole thing to behave like a dependable product.
Dynamic model discovery sounds boring until you imagine being the person maintaining an app that supports multiple providers. Without model listing, you end up hardcoding choices, guessing what’s available, shipping updates just to keep up, and fielding user complaints because the model they want isn’t showing up. With programmatic listing, you can adapt faster. The app can reflect reality instead of yesterday’s configuration.
But there’s tension here that I don’t think people should wave away: this kind of compatibility layer can either reduce chaos or create a new kind of lock-in.
On the good side, cross-provider tool calling means you can write your “do the thing” logic once and not rewrite it every time you change models. That’s real leverage for small teams. Imagine you’re building a customer support agent that can look up an order, issue a refund, and draft a human-sounding response. If the tool-calling behavior is inconsistent across providers, you either narrow your support to one provider or you spend weeks building adapters and edge-case handling. Rig’s pitch is basically: stop wasting your life on adapters.
On the bad side, the more your app depends on one framework’s “standard way” of doing tool calls and streaming, the harder it is to move off it later. That’s not a moral failure. It’s just how software works. Abstraction layers save you time now and charge you rent later, especially when your product gets big and weird and you need to do something “non-standard.”
Streaming reliability is another one that sounds like a footnote but hits users in the face. Say you’re building an internal assistant for a sales team. If streaming stutters, repeats, or cuts off, people won’t call it “streaming reliability.” They’ll call it “this thing is flaky” and go back to their old workflow. You don’t get a second chance with trust. So yes, I care about streaming fixes more than yet another model benchmark graph.
The conversation history preservation fix is quietly huge too, because multi-turn is where real work happens. In a single turn, almost any system can look smart. In five turns, you find out whether it’s actually tracking what matters or just improvising. If history gets dropped or mangled, you don’t just get a worse answer—you get a user who starts babysitting the machine. And the moment your tool needs babysitting, it stops being a tool.
Adding GPT Image 1.5 is interesting, but I’m more focused on what it signals: Rig is treating “models” as a changing catalog of capabilities, not a single lane. Text, images, different providers—more options, more complexity. People love to say “just use the best model,” but in practice “best” depends on cost, speed, policy constraints, and what your users will tolerate.
Here’s the part people may disagree with: I think frameworks like this are going to matter more than model choice for most products. Not because models aren’t important, but because reliability, integration, and maintenance decide whether something survives past a demo. The winners won’t be the teams that pick the perfect model in April. They’ll be the teams that can swap models in October without their whole product falling apart.
Still, dynamic discovery and broad compatibility can also encourage a kind of sloppy “model shopping,” where teams constantly switch providers chasing minor gains and never build deep understanding of failure modes. If your system can easily rotate models, you might do it too often, and your users will feel the personality drift, the inconsistent behavior, the weird regressions. Convenience cuts both ways.
So yeah, Rig v0.35 sounds like a practical release: make tool calling work across providers, make streaming less fragile, stop losing chat history, and make it easier to see what models are available. I’m bullish on that direction. But I also think the industry is sleepwalking into a world where the framework layer becomes the real platform—and the platform owners get to decide what “compatible” means.
If frameworks end up being the real gatekeepers between builders and models, who do you actually want holding that power?