It all started with a speaker that the computer flatly refused to see. A first-generation Yandex Station Lite, released in November 2023, that hadn’t been online for a long time. (Yandex Station is a line of smart speakers from the Russian tech company Yandex, built around its voice assistant Alice, or Alisa — roughly Yandex’s answer to Alexa — and sold mainly in Russia and the CIS.) It didn’t show up over USB, it wasn’t among the Bluetooth devices, and not one of its usual ports answered on the home network. And it all ended at around one in the morning with a phrase the speaker said when it no longer needed the laptop: “Fifty-six.” I’d asked “seven times eight”, and it wasn’t Yandex that answered. It was Mia — our own AI agent, which now answers for the speaker whenever it’s asked to.
Between those two points lay one evening, three failures in a row and one very simple trick that’s worth explaining right away, because without it the whole story looks like magic.
Root isn’t what you think
It’s easy to mix up two things here: root and the route the conversation takes. It feels as if once you’ve got admin rights, the speaker is automatically yours.
No. These are two completely different things.
Root is just admin rights inside the speaker. On its own it changes nothing: the speaker keeps listening to Yandex just as before. If the goal is to replace Alice with your own model, root alone isn’t enough: it only opens the door. Where your voice goes is decided by literally one line in a config file — uniProxyUrl. As long as it holds Yandex’s address, the whole conversation goes through Yandex, however much of an admin you are.
The whole trick is to swap that line. The job is done by a small go-between program — Quasar Bridge — which is installed right on the speaker and pretends to be the cloud. It leaves speech recognition and text-to-speech to Yandex (which is why the voice is still Alice’s for now), but it intercepts the recognised text and decides by a rule who gets it: the phrase “ask the neural network” goes to our agent, everything else goes back to Yandex. For the speaker nothing has changed — it thinks it’s talking to Yandex. In reality the “brain” is already ours.
Hence the formula for this stage: Mia’s brain, Yandex’s voice. A quick route that works in a single evening. A voice of our own is a separate story; we’ll come back to it at the end.
Why this speaker, and why now
We got lucky with the hardware. A first-generation Station Lite that hadn’t been online for ages is the ideal patient. The way to get root relies on a compromised Yandex certificate sitting in a public tool, so during pairing the speaker trusts our local server. With new firmware Yandex keeps closing loopholes: on builds after 21 October 2026 a simple DNS swap no longer works, and for the Lite 1 you have to go round the long way — your own update server rolls the firmware back to an older build, and that build is what opens up access. Our speaker ended up getting root on build 0.369.1.46 from 13 October 2026 — exactly the image the tool is built around. Right after that we blocked updates, so that’s where it has stayed.
The moral for anyone with the same speaker on a shelf: don’t connect it to the internet until you’re ready. An update can close the easy route, and what’s left after that depends on the model and the firmware.
Three failures hiding the wrong cause
The idea is simple. During its first pairing, the speaker has to be tricked into fetching its settings not from Yandex’s server but from our local one — which tells it to switch on debug access. To do that, you have to slip the speaker your own DNS. Our router came from the ISP and its admin panel is locked behind a CAPTCHA, so we shared Wi-Fi straight from the laptop.
And then the detective story began. Three times in a row it didn’t work, and each time we blamed the wrong thing: first the encoding and quotes in the scripts, then permissions, then the idea that the speaker was entering the password “wrong”. The real causes surfaced one by one.
First it turned out our server wasn’t answering the speaker at all. The Windows service that shares the internet connection was already listening on port 53 on all addresses and answering DNS queries itself. Our server came up — and quietly lost. The fix was to bind it not to “all addresses” but to the specific address of the hotspot. A separate DNS query confirmed it: now it was us answering the speaker.
We bound it — and missed again. This was the sneakiest trap: the launch script started the server through a Windows mechanism that dropped the environment variables. We were setting the right address, but it never reached the server, which bound to “everything” and lost to the service again. From the outside everything looked right. What helped was launching it directly, bypassing the script.
The third problem was almost insulting. Windows switches off the hotspot if nobody connects for a few minutes, and the speaker is slow to connect. The network vanished in the middle of pairing, and it all looked like a “wrong password”. On top of that, a space in the network name and a colon in the password got in the way — they’re easy to get wrong when typing. We removed the auto-shutoff with the PeerlessTimeoutEnabled registry value and a restart of the hotspot service, gave the network a simpler name — and everything fell into place.
That, I think, is the main thing I want to get across: when something fails three times in a row, it’s very tempting to blame the obvious — the encoding, the quotes, the password. In our case, all three times the real cause sat one level lower and was disguised as the obvious one.
The moment of truth
Once all three traps were disarmed, the speaker finally went to our server, got the command to open up access — and the terminal showed what all of this had been for:
uid=0(root)A zero. Admin rights. Next, lock in the win straight away: we made the flags that enable access persistent so they’d survive a reboot, made backups of the original files in two places and blocked auto-updates — otherwise, once on the normal internet, the speaker could update itself and lose access. Only then did we reboot it, to make sure root hadn’t dropped off, the block was in place and the updater hadn’t started. It survived. Now the speaker was truly ours.
A brain that doesn’t know too much
While the speaker was going through its initiation, the “brain” was already waiting for it on the server. There’s an important detail here that we’re prouder of than the root itself.
Anyone in the house can hear the speaker — a guest, a child, a random person. So hooking up the main Mia, with all her memory and access, was absolutely out of the question. We set up a separate profile for the speaker: its own personality, its own keys and an empty memory — it has none of the main Mia’s memories. We gave it exactly one permission, deliberately: read-only access to the calendar, so the speaker can say what’s planned for the next few days. By design, this profile can’t create events, send messages or buy anything. Exactly one address is exposed to the outside — only that one; everything else answers “page not found”.
We didn’t just take it on trust that the profile has none of the main Mia’s memory. We asked point-blank: what’s our daughter’s name and where does she go to school. The answer: “I don’t know — in the speaker I don’t have access to the family’s personal data.” That’s exactly how it should be.
We also rewrote the personality for voice: answer in two or three sentences, no lists or emoji, say numbers as words, honestly say “I don’t know” and never carry out any action on a voice command. Voice isn’t a channel where an agent should be allowed to buy or send anything.
“Alice, ask the neural network why the sky is blue”
We installed the bridge, switched the speaker over to it, rebooted. And — that very first voice test.
“Alice, ask the neural network: why is the sky blue?” (The real trigger phrase is in Russian: “Alisa, sprosi neyroset”.)
The log flashed route=llm — meaning the question went not to Yandex but to our agent. In Alice’s voice, the speaker explained light scattering — that was Mia talking, and we heard the answer with our own ears. And for a phrase without “ask the neural network”, the log showed route=yandex: we deliberately left everyday commands to Yandex — there’s no point breaking what already works.
Speed is good too: in two measurements over the internet our server answered in 2.6 and 4.5 seconds. That’s the agent’s own time, without recognition and speech synthesis — we didn’t separately measure the full latency of the voice test. On tokens, the measurements look like this: an ordinary question is around 9,500 prompt tokens, while a single question that touched the calendar pulled in 69,816, because on a tool call the context is re-sent at every step. Worth keeping in mind if the model runs on a shared quota: a chatty speaker can quietly eat through it.
The most dangerous button you mustn’t press
All that was left was to move the speaker from the laptop hotspot to the home Wi-Fi. And this is where a trap was hiding that could wipe out the whole evening.
You’d think: change the network as usual — reset the speaker and set it up again. Absolutely not. A reset wipes the partition where the bridge and the access flags live. Meanwhile the uniProxyUrl line in the system config keeps pointing to the local bridge, which no longer exists after the reset. The result: the voice dies completely, debug access is wiped, and recovery means doing the whole root from scratch.
So we changed the network carefully, using system commands on the already rooted speaker, without touching anything else. We added the home network, kept the old one as a fallback just in case, and waited for the speaker to move over and get a new address. It moved.
And that’s when, with the speaker no longer needing the laptop, I asked: “Seven times eight?” “Fifty-six,” said the speaker. The laptop could be closed.
Being honest about the limits
This story easily reads as “look how cleverly we broke everything”. But the setup has limitations, and we don’t want to hide them.
- There’s no warranty any more. You’re poking around inside someone else’s device. And if the speaker turns into a brick, there’s no proven way to bring it back.
- The method relies on someone else’s mistake. Root only works because the tool contains a compromised Yandex certificate. With new firmware Yandex closes loopholes one after another, and at some build it may close the last one.
- Yandex still hears your speech. At this stage recognition and speech synthesis stay with Yandex — we only swapped the “brain”. There’s no full privacy here, and for now the voice is Alice’s.
If that doesn’t work for you, better not to start. If it works as a quick way to give the speaker your own assistant, the setup does the job: it no longer needs the laptop — the home network, our server and Yandex’s cloud for speech are enough.
The short version for fellow tinkerers
If your hands are itching to repeat this, here are the pitfalls where we lost the most time — so you don’t have to:
- On builds after 21 October 2026, a simple DNS swap no longer works. For the Lite 1 there’s a workaround through your own update server with a firmware rollback, but that’s extra steps and time. An old, offline speaker is your friend.
- The Station Lite 1 only sees 2.4 GHz. Force the hotspot onto that band, or the speaker simply won’t see the network.
- The Windows hotspot service grabs port 53 on all addresses. Bind your DNS server to the specific hotspot address and check with a separate query who’s answering.
- Windows shuts down a hotspot with no clients — and it looks like a “wrong password”. The cure is the
PeerlessTimeoutEnabledregistry value and a restart of the hotspot service. Network name and password — no spaces or special characters. - Launch the local server directly, not through a “smart” script: it loses the environment variables, and the server binds to the wrong place.
- Right after root — lock in access, take a backup and block updates. Before the speaker sees the normal internet.
- And the golden rule: once the bridge is installed, don’t reset the speaker with the button — not to change networks, not “just in case”. The network can be changed without a reset, via
wpa_cli, and if you need to remove the bridge, it has a built-in rollback:control.sh rollbackand a reboot.
What’s next: a voice of our own
Right now we have a hybrid — our brain in Alice’s voice. The next stage is far more interesting: take Yandex out of the chain entirely and give Mia her own voice.
Part of the groundwork is already done. Our server runs the Silero speech synthesiser: in tests, once warmed up, it voiced short phrases 16–20 times faster than real time, and we picked a voice — female, called Kseniya. In an end-to-end test, it took just over six seconds to go from a text question to a finished audio file with Mia’s answer in her own voice. For the speaker itself to talk like that, without Yandex, we still need to figure out the protocol it uses to talk to the cloud and plug in our own recognition and speech synthesis. That’s no longer a fantasy but a clear next step — though it’s noticeably more work than this evening was.
But that’s another story and another evening. For now, there’s a speaker on the shelf that thinks with Mia’s brain whenever we ask it to. And honestly, it still surprises me a little every time I say to it: “Alice, ask the neural network.”
If this kind of DIY with agents is your thing, we have a whole series of pieces on it, from installing your own Hermes agent to fine-tuning. Drop by the chat (in Russian) — we’ll walk you through it.
