Early on we had to decide: do we build on one AI provider or support multiple? The easy answer was to pick Claude (which we like a lot) and move on. But we kept running into cases where a different model would've been better for a specific task.
Claude is great at reasoning through complex problems and following nuanced instructions. Codex is fast and cheap for straightforward code edits. Gemini has a huge context window for when you need to feed in an entire codebase. Each one has tradeoffs in speed, cost, and capability.
Picking one means you get its strengths everywhere and its weaknesses everywhere too. So we built a provider abstraction instead.
How it works
Each agent has a provider configuration. You can set it to Claude, Codex, Gemini, OpenRouter, or a custom CLI. The agent executor doesn't know or care which provider it's talking to — it sends a task, gets responses, handles tool calls. The provider is a pluggable layer underneath.
This means you can run your coding agent on Claude (good at complex reasoning, careful about edge cases) and your content engine on Gemini (fast, big context for ingesting reference material). Or use Codex for quick refactoring tasks where speed matters more than depth. Mix and match per agent, per task type.
Switching providers is a config change, not a rewrite. If a new model drops tomorrow that's better for your use case, you point your agent at it and everything else stays the same — permissions, tools, audit trail, task workflow.
Provider chains and fallbacks
Single-provider setups break when that provider has an outage or rate-limits you. We've all had that afternoon where the API returns 529s and everything stalls.
NRNS supports provider chains — a primary provider with fallbacks. If Claude is down, the agent falls back to Gemini. If that's slow, it tries OpenRouter. The agent keeps working. You don't have to babysit API status pages.
This also helps with cost. Some tasks don't need the most expensive model. A PR review that's checking for lint issues and obvious bugs can run on a cheaper, faster model. The complex architectural review can use the heavy one. You set this per agent or per task type.
Your keys, your choice
Agents use your API keys. You bring your own Claude key, your own Codex key, whatever you want to use. We don't proxy through our servers or add markup. Your usage, your billing, your relationship with the provider.
This is a deliberate choice. We don't want to be in the business of reselling API tokens. It also means you can use enterprise agreements, volume discounts, or whatever deal you've negotiated with your provider. NRNS is the orchestration layer, not the billing layer.
The workflow is the product, not the model
This is the thing that took us a while to figure out. The AI model is a commodity — they're getting better and cheaper every few months. What isn't a commodity is everything around it: how tasks get routed, how agents coordinate, how permissions are enforced, how results get reviewed, how the audit trail works.
If you build on one model, you're betting that model stays best forever. That's a bad bet. Models leapfrog each other constantly. Claude 3 was the best, then GPT-4o, then Claude 3.5, then Gemini got good at code, then Claude 4. Next month it'll be something else.
By keeping the model swappable, we make NRNS better every time any provider ships an improvement. New model drops? Your agents get better overnight. No migration, no rewrite, no waiting for us to add support.
What we actually use
Right now, internally, we mostly run on Claude. It's what we know best and it handles our codebase well. But we've tested agents on Codex for quick tasks and Gemini for long-context research. The point isn't that we use all of them equally — it's that we can switch without rebuilding anything.
And when the next model comes out that's meaningfully better at something, we'll plug it in and move on. That's the whole point.