GrokRouter Lets You Run Any AI Model Inside

GrokBot has a genuinely loyal following. People love the interface, the persistent context, the way it manages files and screen-control history across conversations. What some of them don't love is being locked into Grok's underlying model for everything. Developer Mark Kashef decided to do something about that, and the result is GrokRouter: a free, unofficial, highly experimental tool that lets you route your GrokBot messages to whatever model you actually want to use.

The demo Kashef walks through is straightforward enough that it doesn't feel like a magic trick, which is part of what makes it interesting. He types /provider followed by a model name, and GrokBot starts responding through that model instead of Grok. To prove it isn't theater, he pulls up his OpenRouter account balance on one side of the screen while running a research query on the other. The balance drops. The request went where he said it would.

"I kept everything that people love about GrokBot," Kashef explains, "but just swapped the model behind the main chat."

He's not rebuilding GrokBot or replacing it. He's keeping the operating layer (the files, the permissions, the conversation history, the screen control) completely intact while redirecting the decision layer to a provider of his choice. Codex, Claude via OpenRouter, Kimi K3, free models from OpenRouter's catalog: anything with an accessible API becomes a candidate.

How the routing actually works

When you send a message with GrokRouter installed, the message hits a saved providers file before it ever touches Grok. That file checks your configured preference and routes accordingly. If you've set OpenRouter, your message goes to OpenRouter. If you've set Codex, it goes to Codex. Grok steps aside entirely for the main conversation.

The context-preservation piece is what Kashef describes as one of the trickier problems to solve. Each GrokBot has its own sandboxed computer environment, and that computer has a terminal. Kashef's first instinct was to open that terminal and log into Claude Code directly. It worked in under two minutes. But there was a catch: even with another model answering, the request still burned Grok credits on the round trip. So the goal shifted to intercepting the message before it reaches Grok at all, which is what GrokRouter does.

The whole thing requires a $20/month GrokBot subscription to authenticate. Once you have that, the router source repo is available for free on Gumroad.

The Frankenstein caveat (and why it matters here)

Kashef is upfront about what this is: "I've frankensteined this together, meaning it's not a native functionality of GrokBot, and it hasn't stood the test of time to see another update of the app."

There's a particular optimism in that sentence, the optimism of someone who just finished building a thing and hasn't watched it break yet. It's not cynicism to notice it; it's just honesty about the category. Unofficial modifications to applications that update regularly are maintenance obligations, not set-and-forget solutions. Kashef acknowledges this directly, noting that future GrokBot updates may require corresponding updates to the router, and that users should expect to work with their language model of choice to keep things running.

The architecture is documented in an agents.mmd file in the repo, which walks through both the system design and a set of non-negotiable rules for keeping the setup stable. Kashef suggests feeding the entire repo to whatever model you prefer and asking it to adapt the installation to your machine, which is a genuinely sensible approach for something this experimental.

Where Grok still runs the show

Two significant limitations are worth understanding before you commit the setup time.

First: file access. When a routed model needs to open a file, it can't just open it. That file has to be whitelisted in Grok's approval layer first, and Grok has to pass the information off to the external model. Kashef's analogy is a "brain in a jar": the brain (the model doing the reasoning) is swappable, but the limbs (the computer actions, the file system permissions) are still managed by Grok. The external model informs; Grok executes.

Second: sub-agents. When GrokBot decides a task warrants spinning up parallel research agents, those agents inherit Grok and Grok's capabilities, not the routed model's. The workaround is reasonable: let the sub-agents do the legwork and gather information, then hand the synthesis back to your preferred model for the main conversation. Grok does the fetching; Claude (or whoever) does the thinking. Whether that's an acceptable tradeoff depends entirely on what you're trying to do.

One model for everything is the wrong tool for everything

Here's the thing I keep coming back to when I look at GrokRouter's per-bot configuration feature. You can assign a different model to each bot you've set up in GrokBot: one model for research, a different one for building, another for quick queries.

Most people running AI workflows right now are using whatever model they subscribed to last for absolutely everything, like cooking every meal on the same burner regardless of what's on the pan. The moment you can actually route differently by task, you start noticing how much you've been asking a single model to be all things. A fast, low-latency model that's mediocre at synthesis is still the right tool for a quick one-liner. A slower, more thorough model is worth the wait when you need it to actually think. The realization isn't that one model is better than another. It's that you've been making every cut with the same knife.

GrokRouter makes that granularity possible within a single GrokBot environment. Per-bot configuration, as documented in the video, means the assignment persists across sessions without re-specifying it every time.

The honest version of the cost calculation

Kashef built this because stacking another high-priced subscription on top of an existing GrokBot subscription wasn't something he wanted to justify. GrokRouter's pitch is that you keep the $20/month GrokBot baseline and supplement it with whatever model costs you're already paying elsewhere, rather than paying again for a whole separate agentic environment. Whether that math works for you hinges on one specific question: do you already have an OpenRouter or Codex subscription you're underusing? If yes, GrokRouter is a way to get more out of money you're already spending. If no, the economics look different.

Free models via OpenRouter are technically available, though Kashef flags that reliability is variable and timeouts happen. For genuinely simple requests, they might be fine. For anything you actually care about, probably not the move.

This is Mac-first, and experimental by design

Windows users aren't excluded, but Kashef built on Mac and the out-of-box experience reflects that. The repo includes documentation aimed at helping non-Mac users adapt it, but treat that as a project, not a quick install.

Experimental here isn't false modesty. It means: this works right now, under these conditions, at this version of GrokBot, and may need maintenance after the next update. Kashef is committing to keeping the repo updated, but he's one person who built this over a few days for his own use and is sharing it because other people asked.

That context matters. GrokRouter is interesting as a proof of concept and potentially useful as a daily tool, but the threshold for adopting it should be: am I willing to occasionally debug this when something changes? If the answer is yes, the free repo is there. If the answer is no, it's still a useful window into what becomes possible when applications expose enough of their own internals.

The question GrokRouter is really asking isn't "which model should I use?" It's whether the walled-garden approach to AI tooling (one app, one model, take it or leave it) is actually what users want, or just what they've been offered.

Yuki Okonkwo covers AI and machine learning for Buzzrag.