Blog
Interpretation, Not Translation
Written by Louise Beattie · 4 August 2026
From a Beyond Finance community call, in conversation with Tom Horner of BabelBit, Subnet 59.
Picture a doctor and a frightened patient who don't share a language, in the middle of an emergency. What has to pass between them isn't only the words, it's the meaning, and the reassurance, delivered fast enough to matter and clearly enough that nothing critical is lost. That job has a name. It's interpretation, and it isn't the same thing as translation.
A translator swaps the right words across, faithfully. An interpreter carries intention, what the person actually meant, across a culture, in real time. It's the difference between a printed sign and a person standing between two people in a courtroom or a hospital. BabelBit, Subnet 59 on Bittensor, is building for the second one: real-time speech interpretation, live audio in one language and out in another with the meaning intact.
Why it isn't just Google Translate
It helps to see why this is built differently from the translation most people already use. Google Translate, the obvious point of comparison, runs a chain of steps, speech into text, text through a model, back to text, then re-voiced into speech. Each step adds delay, which is why even the strongest centralised systems sit five to ten seconds behind a live speaker. That lag is fine for a menu or a road sign and awkward for a conversation. An interpretation-first system is trying to close that gap by design. The two are built for different jobs.
It also couldn't have been built much sooner. Real-time interpretation of this kind wasn't possible 18 months ago, it's the recent evolution in large language models and transformer design that changed that. The timing matters, because it let a small team start from a clean slate rather than retrofit something older.
How it actually works
BabelBit runs on the Bittensor protocol, and that shapes how the work gets done. Instead of one company employing all the engineers, the subnet sets a task and opens it to anyone. The current challenge is taking a live French audio stream into English. Independent operators, the miners, compete to do that better than one another, and they're scored on two things, how little delay they add and how well the meaning survives the trip. Validators run the scoring, and the network rewards whoever is ahead. So the model doesn't get better because a fixed team pushes it forward, it gets better because miners are paid to keep beating the last best result.
Under the surface there isn't one model but two. The first is built on the best open-source system the team could find, improved by fixing its bugs and, in Tom's words, making the GPUs that run it 400% more efficient. It handles about four languages, French, Spanish, Portuguese and German, and it has a hard ceiling that more money can't easily lift. The second is far more multilingual, covering the top 20 or 30 most common languages, it works both ways, and it's infinitely more programmable. That second model is where most of the headroom is, and where the miners are producing the bulk of the improvements.
One distinctive part of the design is a confidence score. The model tracks how sure it is about where a sentence is heading, and when it's confident enough it starts interpreting before the speaker has finished. "Our Father who art in heaven" can come out almost immediately, because once you've heard the first few words the rest is fixed. A more open-ended sentence lowers the confidence, and the model holds back and waits. It's interpretation as prediction rather than straight conversion, and it means the approach sits most comfortably where speech is structured and predictable, broadcast, liturgy, legal or medical routine, and struggles more where talk could go anywhere.
Why build it as a subnet
Building it as a subnet is a deliberate choice. A small team can't out-hire a large lab, and this way it doesn't have to, because the miners are the research engine, rewarded by the network for producing the best-scored interpretation.
The longer-term design is for the model to improve itself. The idea, as Tom describes it, is to take parallel copies of the audio, turn them into text, and feed that back as post-training data that another model grades, the system effectively becoming its own judge and making its own small corrections over time. Once that mechanism is in place, the model keeps sharpening without constant hands-on work, and the team's job shifts to scaling, reliability, resilience, and onboarding new niche languages. It's a design rather than a finished thing, but it's the flywheel the whole set-up is built around: the longer the subnet runs, the less the improvement leans on people.
Who would use it
Zoom out from the model and there's the question of who actually uses it. Rather than build a sales force, BabelBit means to plug into existing ones, resellers who already sell software into broadcasters and government tenders and who could carry an interpretation tool through doors a small team wouldn't reach alone. Those relationships are still early, conversations rather than contracts, with the team just partnering with its first reseller and AWS partnerships.
Furthest along are two proof-of-concepts, both for live television dubbing, one turning a South American station's Spanish into English, the other dubbing a Japanese station from English. The second is already producing output, an English news feed rendered into Japanese. That same property, condensing meaning rather than translating every word, has exposed markets nobody was serving well. Broadcast and dubbing are the obvious ones, but it reaches past the screen too, to live public speaking, where delivery has to keep pace with the speaker and stay concise in a way a full translation can't.
Beyond broadcast, the demand Tom points to is regulated and niche-language work, organisations with legal obligations to broadcast in particular languages, the BBC with Welsh, or India with its many official languages, where a specific language could be trained for a customer and tied to a long-term contract.
There's also the consumer version people always ask about, live translation on a phone call, a WhatsApp chat, a Google Meet with everyone in a different language. Tom's answer is that the model already fits on a phone; what it can't yet do is run the inference there. That step isn't far off, though. A new generation of models is starting to support CPU inference, which would run it on the phone itself, and the smaller and simpler the language task, the smaller that model needs to be, so the first versions arrive sooner than the whole. In the meantime, the input and output feeds can be handled by remote inference over the phone's existing 5G or 6G network.
What's real, and what's coming
What's real today: the model works, it runs on the subnet, and the miners are sharpening it week to week. Both proof-of-concepts are under way, and the Japanese one is already turning an English news feed into Japanese, well enough that it has been described as realistic if not yet native.
What's coming: paying customers and revenue, rather than the conversations and pilots they have now. The reseller distribution they're only just entering. The self-improving loop, which is designed but not yet running. And the version that lives on your phone, nearer than it sounds, carried by remote inference over today's networks until on-device CPU inference catches up.