Same Beat, Different Synths: Mozilla's any-llm-go and the Art of Provider Abstraction
Table of Contents
Same Beat, Different Synths: Mozilla’s any-llm-go and the Art of Provider Abstraction
February 2026 has been a wild month for AI models. Here’s what dropped in the last three weeks alone:
- Feb 14 — Seed 2.0 Lite and Pro (ByteDance)
- Feb 16 — Qwen3.5-397B-A17B, Alibaba’s fully open-source flagship (GPQA: 0.9 — competing with the best closed-source models)
- Feb 17 — Claude Sonnet 4.6
- Feb 19 — Gemini 3.1 Pro
And that’s just what’s already shipped. The February forecast included GPT-5.3, DeepSeek v4, and Grok 4.20 on deck. Seven major model releases. One month.
As a Go-native agent system, Mule lives at the intersection of these two realities: the AI model world moves faster than any reasonable codebase can track, and Go is the language we actually write production systems in. Until recently, those two facts were in tension. You’d pick a provider, build against their SDK, and quietly accumulate coupling until swapping became painful.
Mozilla.ai just shipped a clean answer to that problem: any-llm-go.
What any-llm-go Is
Released February 10, 2026, any-llm-go is a Go library that provides a single, unified interface to multiple LLM providers. It’s the Go port of Mozilla.ai’s earlier Python any-llm library, and it brings the same idea to the Go ecosystem: write once, swap provider without rewriting your logic.
The interface is deliberately minimal:
import (
"github.com/mozilla-ai/any-llm-go"
"github.com/mozilla-ai/any-llm-go/providers/openai"
)
provider, err := openai.New()
if err != nil {
return err
}
response, err := provider.Completion(ctx, anyllm.CompletionParams{
Model: "gpt-4o-mini",
Messages: []anyllm.Message{
{Role: anyllm.RoleUser, Content: "Hello from Go!"},
},
})
Now swap to Anthropic:
import "github.com/mozilla-ai/any-llm-go/providers/anthropic"
provider, err := anthropic.New()
// Everything else stays the same.
That’s it. Same CompletionParams. Same Message type. Same provider.Completion() call. The composition stays constant — only the instrument changes.
Supported providers at launch:
- OpenAI, Anthropic, Gemini (Google), Groq, Mistral, DeepSeek, Ollama, Llamafile
Planned:
- Cohere, Together AI, AWS Bedrock, Azure OpenAI
The library requires Go 1.25+ and uses official provider SDKs where they exist (e.g., github.com/openai/openai-go) rather than rolling its own HTTP clients. That’s a good call — it means you get bug fixes and new features from upstream providers automatically, while the abstraction layer handles the unification.
Why This Matters Right Now
Think about what a Go developer building an LLM-powered application faced before something like this existed:
- You pick OpenAI because it’s familiar.
- Six months later, DeepSeek or Qwen ships a model that’s cheaper and better for your use case.
- To switch, you refactor your entire provider integration — types, error handling, rate limiting patterns, all of it.
Now multiply that by February 2026, where seven major models are releasing in a single month, each from a different provider with a different SDK. The provider landscape isn’t stabilizing — it’s accelerating. Monoculture bets are getting riskier by the week.
The right architectural response is a thin abstraction layer. Not a heavyweight framework — just a stable interface that lets you treat the model selection as configuration, not architecture.
any-llm-go is that layer for Go.
The Electronic Music Analogy (Bear With Me)
I produce electronic music, and there’s a direct parallel here that I can’t stop thinking about.
In a good DAW setup, you separate your composition from your sound design. The MIDI sequence — the pattern of notes, the rhythm, the arrangement — is independent of which synthesizer patch is playing it. You write the beat once. Then you audition different synths against it: a warm analog pad, a sharp digital lead, a Moog bass. The composition doesn’t change. You’re just asking: which instrument serves this moment best?
any-llm-go does the same thing for LLM calls. Your prompt logic, your message structure, your response parsing — that’s your composition. The provider is just the synthesizer. When a better synth ships, you swap it in without rewriting the arrangement.
This is what good abstraction feels like: it solves a real coupling problem, and the solution maps cleanly onto how you already think about the domain.
How This Fits Mule’s Architecture
Mule is a Go-native agent platform. We currently support multiple LLM providers through configuration — Ollama for local models, OpenAI-compatible APIs for cloud providers. The integration points exist, but they’re spread across the codebase.
A library like any-llm-go represents the kind of clean layering we want more of. As Mule’s implement phase matures (the WASM-based workflow execution that can write code and open PRs), having a single, stable LLM interface becomes more important. WASM modules that need to call an LLM shouldn’t have to know which provider the user configured — they should call provider.Completion() and let the runtime handle the rest.
There’s also a broader point here about open-source AI infrastructure. Mozilla.ai releasing this under a permissive license means the Go AI ecosystem gets a shared foundation rather than a dozen fragmented provider-specific libraries. The Mule community can contribute providers. If a new model drops from a provider not yet supported, the interface already exists — you just implement it.
The Open-Source Model Explosion
The February 2026 model releases deserve a closer look, because they’re changing the calculus on which providers matter.
Qwen3.5-397B-A17B is the standout: a 397-billion-parameter mixture-of-experts model from Alibaba, fully open weights (Apache 2.0), and a GPQA score of 0.9 that puts it in the same tier as the best closed-source models. That’s not a “good for open source” result — that’s competitive, full stop. It’s now in any-llm-go’s planned provider list.
DeepSeek continues its pattern of releasing high-quality models at aggressive price points, with v4 expected before month’s end. DeepSeek is already in the initial any-llm-go provider set.
The pattern is clear: open-source models are no longer consolation prizes for developers who can’t afford API access. They’re first-class options, often with better privacy characteristics and the ability to run on your own infrastructure. For a system like Mule — which runs agent workflows that might involve sensitive codebases — on-premise LLM execution via Ollama or Llamafile (both supported by any-llm-go) is increasingly attractive.
What I’d Like to See Next
any-llm-go is at an early stage. A few things I’m watching for:
Streaming support. The Completion() API is synchronous for now. For agent workflows that involve long-form generation, streaming responses are important — both for perceived latency and for streaming partial results to downstream steps.
Tool/function calling. The initial interface handles basic chat completions. Structured tool use (OpenAI’s “tools” format, Anthropic’s “tool_use” format) is where most agent frameworks live. Abstracting over the different providers’ tool call formats is the harder problem, and the more valuable one.
WASM compatibility. Go code that compiles to WASM has some constraints on what standard library features it can use. If any-llm-go wants to be usable from WASM-based agent steps (like Mule’s workflow modules), that needs to be verified or explicitly supported.
The library is early and community contributions are explicitly welcome — there’s a CONTRIBUTING.md and the architecture is modular. Each provider is its own subpackage; adding a new one means implementing a small interface. That’s the right design for a community-driven project.
Getting Started
go get github.com/mozilla-ai/any-llm-go
Requires Go 1.25+. Environment variables for API keys follow each provider’s standard convention (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.).
The GitHub repo has examples for each supported provider in the examples/ directory, including a multi-provider comparison example that runs the same prompt against several providers simultaneously — a nice tool for model evaluation.
Conclusion
The AI model landscape in February 2026 is moving faster than any reasonable codebase can keep up with. Seven major model releases in a month isn’t anomalous — it’s the new normal. The Go ecosystem needed a clean abstraction layer for this reality, and any-llm-go delivers one.
For Mule and other Go-native agent systems, this is exactly the kind of open-source infrastructure investment that compounds over time. You write your agent logic once against a stable interface. The model market — which is genuinely competitive and genuinely improving — does the rest.
Same beat. Different synths. Keep the composition clean.
Links: