Mozilla Thunderbolt Lets You Swap Between GPT and Claude Like Tools. That’s a Big Deal.

Every major enterprise AI rollout in the last two years has subtly asked companies to accept the same tradeoff: hand your internal data to OpenAI, Microsoft, or Anthropic, and get a very good assistant in return. The assistant is real. The tradeoff is also real. Proprietary source code, client records, internal strategy docs, half-finished product plans. All of it routes through infrastructure you don’t own, governed by terms you don’t write, priced on a meter you can’t read.

That model is starting to break.

Right now, buying enterprise AI is like buying a car where the manufacturer solders the hood shut and dictates what gas you can use. You get the keys, you get the steering wheel, you get a very fast vehicle. You don’t get to swap the engine, inspect the wiring, or refuel at a competitor’s station.

On April 16, Mozilla’s MZLA Technologies, the subsidiary behind Thunderbird, shipped something called Thunderbolt ( github repo thunderbolt). Yes, the name collides with Intel and Apple’s hardware standard. Yes, that’s going to cause search and SEO headaches for a while. Set that aside, because what they actually built is an open-source attempt to open the hood on enterprise AI.

And what they built is a different way of thinking about AI systems entirely.

Thunderbolt doesn’t try to compete with GPT-5 or Claude Opus at the model layer. It competes one layer up, at the interface and orchestration layer, and it does something genuinely new there: it treats every large language model, frontier or local, as an interchangeable backend you can swap at will. Same workspace, same search bar, same workflows, different engine underneath whenever you want a different engine.

That’s the part worth paying attention to.

What Thunderbolt actually is (and isn’t)

Thunderbolt is not a model. It has no brain of its own. It’s a self-hosted workspace, with desktop apps for macOS, Linux, and Windows plus iOS, Android, and web, that sits in front of whatever AI model you point it at. Chat, search, research workflows, and scheduled tasks all happen inside Thunderbolt. The actual inference happens wherever you decide, routed through a backend proxy your team runs.

Think of it this way. Right now, most enterprise AI tools are vertically integrated. ChatGPT Enterprise is the interface and the model and the data plane, all owned by OpenAI. Copilot is the same, owned by Microsoft. If you want to switch models, you switch products, and your team has to learn a new tool and your integrations break.

Thunderbolt pries those layers apart. The interface stays the same. The model underneath becomes a config value.

In practice, that means an admin can route reasoning-heavy work (architecture planning, long-context code review, strategic drafting) to Claude or GPT via API, while routing anything touching proprietary data to a local Ollama instance running on the company’s own hardware. Same chat window. Same search bar. The user doesn’t know, and doesn’t need to know, which model answered.

Why the architecture matters more than the feature list

The technical stack is where Thunderbolt gets interesting, and it tells you who MZLA was thinking about when they built it. If you’re not a developer, don’t skip this section. Each choice maps directly to something your compliance team or your CFO actually cares about.

The desktop apps are built on Tauri, which means they’re lightweight native clients instead of the memory-hogging Electron wrappers most modern apps ship with. Translation: your users get a fast app that doesn’t eat 2GB of RAM to display a chat window. The client runs the same React codebase on macOS, Linux, Windows, iOS, and Android, so there’s one codebase to audit instead of five.

On each device, chat history and local state live in SQLite, a file-based database that runs on the user’s machine. That gets you offline-first reads and instant response times for anything cached locally. No round trip to a server just to scroll back through yesterday’s conversation. That local database syncs to a central PostgreSQL server through PowerSync, a real-time sync engine that handles the messy parts of multi-device conflict resolution. If a user edits on their laptop and their phone at the same time, PowerSync sorts out the conflict instead of your engineers writing that logic from scratch.

The backend runs on Elysia on top of Bun, which are both fast JavaScript runtimes optimized for API work. The practical effect is that a small server can handle a lot of concurrent users. But the piece that matters most is the inference proxy. Every LLM call from every client passes through this proxy before it leaves your network. That’s where Anthropic, OpenAI, Mistral, OpenRouter, and any OpenAI-compatible endpoint plug in. Ollama and llama.cpp handle local inference on the same interface. The proxy is what makes model-swapping a config change instead of a migration.

The whole server stack runs via Docker Compose. One command, and you have PostgreSQL, Keycloak (for enterprise single sign-on), PowerSync, and the backend API running on your own infrastructure. For larger deployments there’s a Kubernetes path and a Pulumi path for AWS.

Optional end-to-end encryption uses AES-256-GCM for data at rest, ECDH P-256 for key exchange, and ML-KEM-768 (formerly called Kyber) for post-quantum resistance. The last one matters more than it sounds: it’s designed to resist attacks from future quantum computers that don’t exist yet but will. When end-to-end encryption is turned on, the server only ever sees scrambled data. Even a full server breach wouldn’t expose conversation content.

All of this is open source under MPL 2.0. You can read the code. You can audit it. You can fork it. That last point is what turns this from a product into infrastructure.

The honest tradeoffs, because they matter

This is where most breathless coverage of Thunderbolt falls apart, and where you should pay extra attention if you’re thinking about deploying it.

It’s not production-ready yet. The GitHub repo says this directly. The security audit is still in progress. MZLA is explicit that current deployment paths are for evaluation only, not live production. If you’re in a regulated industry, procurement isn’t signing anything until that audit closes.

“Offline-first” is aspirational right now. The marketing says offline-first. The architecture is built for offline-first. But today, the client still needs a live connection to its identity provider (Keycloak, Google Workspace, Azure AD) to validate tokens, and search mode still needs to hit the server to run semantic queries against your corpus. You can disable search to work offline, but that kneecaps most of the value. Full offline is on the roadmap, not in the box.

Local models are not frontier models. This is the one I’d underline twice. If your team is used to Claude Opus thinking through a complex refactor in one shot, a 30-billion-parameter local model running on a workstation will disappoint them. Local models handle maybe 80% of routine work, like formatting, simple refactors, structured extraction, and summarization, well enough. They fall apart on multi-step reasoning, long contexts past roughly 100k tokens, and anything requiring the model to infer across gaps. You will need to train your team to route requests appropriately, because the system won’t do it perfectly for you.

Telemetry ships enabled by default. PostHog analytics collect usage patterns, model preferences, settings changes, and generalized location. No PII, per the project, but if your compliance team has opinions about default-on telemetry (and they will), flipping that off is your first configuration change.

The five-step playbook for actually trying this

If you work in a small team or at a company where you have any say in tooling, here’s a realistic path to trying Thunderbolt without overcommitting.

1. Start with a single-machine deployment. The Docker Compose path is the fastest way in. Clone the repo thunderbolt, copy the example .env file, and run docker compose up. You'll get the whole stack (PostgreSQL, Keycloak, PowerSync, the backend) running locally. Point a desktop client at it. Give yourself an API key for Anthropic or OpenAI. You now have a working sovereign AI client you can poke at. Time cost: an afternoon.

2. Test the two-model routing story honestly. This is the pitch, so test it. Pick a task your team does weekly: code review, writing first-draft docs, summarizing meeting notes. Run it through Claude via Thunderbolt. Then install Ollama on the same machine, pull down a model like Qwen2.5-Coder or Llama 3.3, and run the same task locally. The quality delta will tell you where the honest line is between “good enough to keep data internal” and “I need the frontier model.” Don’t skip this step. It’s the single most important data point for deciding whether Thunderbolt fits your team.

3. Identify one real use case where data sovereignty is non-negotiable. Not a theoretical one. A real one. Maybe it’s customer support tickets that contain PII you shouldn’t be sending to a US hyperscaler. Maybe it’s source code for a product you don’t want indexed by a training pipeline. Build that one workflow in Thunderbolt, routed to a local model, and measure whether it works. If it does, you have the beginning of a real argument for wider deployment. If it doesn’t, you’ve learned something important about the current state of local inference before staking a roadmap on it.

4. Wire up Haystack if you have internal knowledge to search. Thunderbolt on its own is a good chat interface. Paired with Haystack, deepset’s open-source orchestration framework that Thunderbolt integrates with natively, it becomes a real enterprise system that can retrieve from internal documents, run agentic workflows, and augment prompts with context. This is where the sovereignty story gets most compelling, because you’re now replacing the entire proprietary stack, not just the chat window.

5. Don’t deploy to production yet. Wait for the audit. Use this period to figure out your routing policies, train your team on when to send what to which model, and build up internal knowledge about how the system behaves. When the audit closes, you’ll be ready to move fast. Teams that are still debating whether to try it will be six months behind.

The bigger question worth asking

Set Thunderbolt itself aside for a moment. The deeper question it surfaces is whether the current proprietary-stack model of enterprise AI is going to hold.

Right now, every major AI vendor is betting it will. They’re building deeper integrations, stickier workflows, proprietary agent frameworks that only work on their stack. The business logic is obvious: once your workflows are expressed in Copilot or ChatGPT’s particular shape, switching costs become prohibitive.

Thunderbolt is the first serious, well-funded attempt to bet the other way. Not that the models will become commodities (they won’t, for a long time) but that the interface to them will. That teams will want one place to work, one set of automations, one permissions model, one search bar, with the model underneath treated as a swappable utility.

If that bet is right, the future of enterprise AI looks a lot more like how we treat cloud compute today: multiple providers, workload-aware routing, and serious negotiating power for the customer. If it’s wrong, Thunderbolt becomes another interesting open-source project that didn’t quite escape gravity.

Either way, it’s the most architecturally honest attempt anyone has made to give organizations real AI sovereignty. The security audit isn’t done, the offline story isn’t ready, and the local models aren’t as smart as the frontier ones. And it’s still worth your attention, because the pattern it’s proposing (decouple the interface from the model, put the orchestration in your own hands, treat vendors as interchangeable) is the pattern every serious enterprise AI stack is going to need eventually.

Start small. Spin it up on one machine. Route a real workflow through it. See what breaks. That’s how you find out whether sovereign AI is a marketing phrase or an actual operating principle you want to build on.