DEV Community: Mike Meshok

Claude on a Nokia 3310: a J2ME client, HMAC instead of TLS, and 41 bundled games

Mike Meshok — Fri, 23 Oct 2026 01:42:22 +0000

I wrote VibeNokia: a Java ME client for the 2017 Nokia 3310 feature phone that turns it into a chat terminal for Claude, plus a small FastAPI server that stores history, verifies signatures and runs claude -p. The menu also has Telegram, voice messages and a catalogue of 41 mini games. It works on my physical phone, and along the way I had to re-solve several things that a smartphone gets from a one-line library call.

A caveat up front: the client has been tested on one real Nokia 3310 (TA-1030). I haven't tried other Series 30+ or Series 40 phones. The channel between the phone and the server is not encrypted; more on that below, without softening it.

The platform

The 2017 Nokia 3310 is Series 30+ on a MediaTek MT6260. It runs Java ME with CLDC 1.1 / MIDP 2.0, has a 240x320 screen, mobile data only and no Wi-Fi. It has no usable browser and no app store. A plain HttpConnection with POST and JSON does work (I've seen this on my device), and the battery lasts a week.

So the design is thin: the phone runs a client that draws the screen and sends requests, and my server does all the heavy work. The app installs as a .jad/.jar pair from the memory card, or over the air: the server itself serves the files at /ota/VibeNokia.jad.

docs/platform-notes.md collects observations I wish I'd had before starting. The ones that cost me time:

CLDC has no cryptography at all. SHA-256 and HMAC in Crypto.java are written by hand.
The standard List and Form don't deliver keyRepeated, i.e. a held key. Because of that the whole UI is a custom Canvas, with home-screen tiles, scrolling and input.
There is no timeout API on the HTTP connection, and the system timeout is measured in minutes. The client runs its own watchdog threads and aborts hung requests itself.
Server responses are cut at roughly 25 KB. The screen shows far less anyway.
Voice is recorded through JSR-135 as AMR, about 1.5 KB per second; the server converts and transcribes it.

Why not HTTPS

This is where I hit a wall. According to public sources, the Java stack in these phones stops at old TLS versions and an old certificate store, so modern HTTPS URLs don't open. In my notes this is marked "reported": I did not deliberately re-verify it on my own device. The outcome for the project is the same either way: the client uses plain HTTP.

That means you can't rely on channel secrecy, so the app is built not to depend on it. Hence signed requests.

Signing instead of TLS

The phone is paired with the server once and receives its own key. After that the key never crosses the network. Every request carries an HMAC-SHA256 computed over:

the method and path;
a request counter;
a hash of the body;
the server address.

The server checks the signature and the counter. A replayed request is dropped: a window of the 64 most recent counters works like the sliding window in IPsec. The signature includes the server address (VIBENOKIA_PUBLIC_HOST), so a request signed for a different address is rejected. Repeated wrong signatures or codes get the source banned for 15 minutes.

Pairing works like this. Set VIBENOKIA_PAIRING=1 in .env. Press 5 on the phone, and the server writes a one-time six-digit code to data/pair_code.txt (mode 600); if a Telegram token and my chat are configured, the code is also sent there. The code lives for 10 minutes and works once. You type it on the phone, the device gets its key and stores it. Then you set VIBENOKIA_PAIRING=0 and the /pair/* paths answer 404. A phone can be revoked locally with tools/devices.py against the database file; there is deliberately no network admin API.

What the signature does not give you

Signing protects against forgery, guessing and replay. It does not protect against eavesdropping at all. Anyone on the path between the phone and the server can read your questions and Claude's answers. Don't send anything secret from this phone. I say this in the README and in the deployment docs and repeat it here, because it's worse when people discover such things themselves.

Server and security

The server is Python with FastAPI and SQLite: sessions, devices and contacts live in one file. To answer, it runs claude -p with a short system prompt written for a tiny screen. What matters:

By default the server listens only on 127.0.0.1:8085, and Docker publishes the port on loopback only. To expose it, do it deliberately through a proxy that forwards only the phone's paths (/ping, /api/*, /pair/*, /device/*, /ota/*) and answers 404 for everything else. The docs have Caddy and nginx examples.
No default passwords. The admin key is generated on first run.
Claude has no shell by default: it runs with --permission-mode dontAsk and no pre-approved tools. If you allow tools via VIBENOKIA_CLAUDE_ARGS, a paired phone gets access to them. Treat such a phone like an SSH key and keep the allow-list narrow. The server removes its own secrets from Claude's environment.
The second engine (OpenCode) is off by default, because its agents may run tools according to your own configuration.
VIBENOKIA_FEATURES sets a ceiling on features: if you don't need Telegram or voice, their API paths answer 404 for every phone.

Before opening the port, the docs have a short check: ss -ltn | grep -v 127.0.0.1 should show only the proxy port, and curl against /ping and /api/chat without a signature should return 403 and never 200.

The menu: two tiles instead of a cockpit

The first version opened with every feature at once. In the second (v0.2.0) the app starts with a simple menu of two tiles: chat with Claude, and Settings. Everything else (Telegram, voice, sessions, a second tile for OpenCode, and the "advanced" group: server list, in-app update, key rotation) is switched on in Settings > Features. The choice is kept in the phone's RMS storage. The server-side ceiling is applied on top: a feature the server forbids is hidden in the app, and the list arrives in the /ping reply. Upgrading from an older version keeps everything that was visible before, while a fresh install starts simple.

Always available: chat, model choice (Opus, Sonnet or Haiku), new chat, language (Russian or English) and font size. Tiles are numbered in the order shown, the digit opens a tile, and 5 opens the selected one. Hold * to dictate: the recording goes to the server, is transcribed there (Gemini via OpenRouter, Groq Whisper as a fallback) and lands in the chat.

Features, a list of switches" width="480" height="640">

The screenshots are from MicroEmulator at 240x320.

41 games

The catalogue has 41 standalone apps with no permissions and no network. Nine were written in this repository; the other 32 are MIT-licensed games from the agneay/j2me-100-games archive. Third-party components are listed in THIRD_PARTY_NOTICES.md. One script, scripts/build-games.sh, builds them all.

Running it

You need Docker with Compose, make, and either a Claude API key or a Claude Code login:

git clone https://github.com/meshoklv/vibenokia && cd vibenokia
./scripts/quickstart.sh     # creates .env with a fresh key and starts the server on 127.0.0.1:8085
make -C client SERVER_URL=http://your.host:8080    # -> client/dist/VibeNokia.jar + VibeNokia.jad
./scripts/build-games.sh                           # optional -> games/dist/

The client builds inside a public Docker image with a J2ME toolchain. Install VibeNokia.jad from the memory card, then pair with a code as described above. Without Docker the server runs with scripts/run-local.sh; you then need Python 3.10+, ffmpeg for voice and claude on PATH.

What is and isn't tested

Tested: the client on a real Nokia 3310. For this release the client and all 41 games build in the J2ME container, and I drove the new menu and Features screen by hand in MicroEmulator (the screenshots come from there). The server image builds and answers 403 on loopback without auth, and pairing plus signed chat were exercised end to end with the phone emulator and a stub in place of claude.

Not tested: a real Claude call inside the published Docker image, other Series 30+ and 40 phones, and a TLS front together with the phone. Planned: prebuilt .jar files in releases and per-device tool allow-lists.

About the AI assistant

Part of the code was written together with an AI assistant (Claude); the commit history shows this through a Co-Authored-By line.

Links

Repository: github.com/meshoklv/vibenokia, MIT license. Issues and PRs are open; the rules are in CONTRIBUTING.md. If you have another J2ME phone and try it, tell me what happened. I post notes on Telegram at t.me/meshoklv.

Mike Meshok - github.com/meshoklv

thumbmux: a mobile web UI for tmux and AI agents that is password-protected from the first second

Mike Meshok — Fri, 23 Oct 2026 01:42:15 +0000

Claude Code, Codex, OpenCode and similar tools run in a terminal for minutes or hours. Checking on such a session from a phone through an ordinary web terminal is miserable: the keyboard fights the TUI, autocorrect mangles prompts, there is no scrolling, and all sessions look the same. I built thumbmux, a mobile web interface for your own tmux: a tab per session, a normal text field, swipe scrolling, photo and file upload. What I think matters most isn't the interface but that the terminal is behind a password and listens on no open port.

A caveat up front: the interface was designed for iOS Safari. It works in desktop browsers, but I haven't poked at it there. The Docker image and the VPN compose file were not tested on the build machine, because it has no Docker. The server side is covered by tests; the screenshots below come from a test instance opened in Chrome at iPhone size.

Screenshots from a test instance with demo sessions, opened in Chrome at iPhone size.

Start with what can go wrong

A web terminal is a shell on your machine reachable over HTTP. If it's open without a password, that isn't an inconvenience, it's a hole: anyone who can reach it runs commands as you. Every decision in the project was made with that one thought in mind, so I'll start with them rather than with pretty screens.

Loopback only by default. Without explicit configuration the server listens only on 127.0.0.1. Docker also publishes the port on the host's loopback only.
A password is mandatory. There is no default password. If you don't set one, the server generates a random one, saves it to ~/.thumbmux/password (mode 600) and prints it once in the log. A weak or placeholder password (shorter than 8 characters or from a list of obvious ones) is simply refused, and the server doesn't start.
The terminal doesn't listen on the network at all. The live terminal comes from ttyd, which has no proper access control of its own. So thumbmux starts ttyd itself on a unix socket inside a private temporary directory with mode 0700. There is no TCP port to find or connect to. The terminal reaches the outside only through the main server, at /m/term/, and only after the login and origin checks.
Everything is behind the login except /login and /healthz. Session cookies are signed (HMAC-SHA256), expiring, HttpOnly, SameSite=Strict, and Secure over HTTPS. Failed logins are throttled per address: five tries, then a one-minute lock.
CSRF and WebSocket hijacking. Every POST and every WebSocket upgrade must carry a same-origin Origin or Referer and a non-cross-site Sec-Fetch-Site, or it gets a 403. This closes the attack where another site, open in your browser, tries to connect to your logged-in terminal.
Cookies don't reach the terminal. The proxy strips cookie and authorization from requests to ttyd, and the login password is not exported into the terminal's environment.

From this follows an operating rule: put thumbmux behind TLS. The repository has Caddy and nginx examples in deploy/. Use a separate (sub)domain rather than a path prefix, forward the Host header and set THUMBMUX_TRUST_PROXY=1. Or keep it on loopback and reach it through an SSH tunnel or an overlay network such as Tailscale. Don't publish the plain-HTTP port to the internet. And to be honest about it: one shared password protects a whole shell, so choose a long, unique one.

For stronger insurance there is docker-compose.vpn.yml: the container goes through a VPN with a kill-switch, so if the tunnel drops it has no network at all. This variant is on my "not tested" list.

What the interface does

thumbmux doesn't replace tmux, it sits in front of it. The sessions are ordinary ones, so you can SSH in at the same time and run tmux attach -t phone to see the same windows. Sessions keep running whether or not the phone is connected.

Tabs and a session list. A new tab with a shell or an agent (claude, codex, opencode, gemini, aider, or any command from your THUMBMUX_AGENTS list). The list looks like Telegram: the last lines of each session and a working / waiting / done indicator.
An input box that behaves. You type into a normal text field and the text is pasted into the pane. Swipe typing and autocorrect work as in any app. Esc, Tab, arrows, Ctrl-C and your own quick commands are buttons.
Swipe scrolling. A finger movement scrolls the tmux history. The page forwards touches as wheel events, and in the recommended deploy/tmux.conf one wheel tick moves exactly one line instead of five, because a swipe produces many ticks in a row.
Uploads. JPEG or PNG photos up to 15 MB (with a thumbnail) and any file up to 100 MB go to the pane's working directory; the path is typed into the agent's prompt.
A file manager. Browse, download, make folders, rename, move, delete to trash, and undo the last 50 operations.
A folder as a tab with favourites, split panes, reopening past Claude Code chats through claude --resume, and a deep link /m/?go=claude&cwd=/path for a keyboard shortcut.
Optional voice input: recording in the browser, transcribed by any OpenAI-compatible service, local or cloud. While THUMBMUX_STT_URL is empty the feature is off and no audio goes anywhere.

The server is a single file of plain Python, standard library only, plus ttyd and tmux. Installing without Docker:

sudo apt install tmux ttyd       # or: brew install tmux ttyd
git clone https://github.com/meshoklv/thumbmux && cd thumbmux
cp .env.example .env             # optionally set THUMBMUX_PASSWORD
./run.sh

With Docker it's simpler: docker compose up --build, a random password is printed once in the logs, and you open http://127.0.0.1:7682. If you set THUMBMUX_TMUX_SOCKET, every tmux call goes to that explicit socket instead of your normal server, which is handy for keeping it away from your main sessions.

The Telegram bot: convenient and dangerous

New in Unreleased: an optional built-in bot. It messages you when a tab finishes or asks a question, with "Reply" and "Open" buttons. Answer with text or a voice message and it is typed into the right tab. There are /sessions, /new and /help. It runs inside the server using long-polling, so only outbound HTTPS, no webhook and no open ports.

And here is the main warning. The bot is remote input into your shell: whoever can message it runs commands as you. So the integration is off by default and refuses to start if a token is set while THUMBMUX_TG_ALLOWED_CHAT_IDS is empty or malformed. Both the chat and the sender are checked; everyone else gets silence (the log keeps a line without their text). The token is read only from the environment and never logged, input is limited to 20 messages per minute per chat, and the long-poll offset is stored in a file with mode 600 so old messages aren't replayed after a restart.

A second caveat: notifications contain terminal output, so it goes to Telegram. Don't enable the integration where sessions print secrets. And so far I have tested it only against a fake Bot API in the tests, not against the real Telegram server.

Tests

tests/ has security tests (login, session cookies, CSRF and origin checks, the WebSocket tunnel) and tests for the Telegram part against a fake Bot API: notification, reply routing, a foreign chat ignored, no allowlist means no start, voice, rate limit, offset after restart. Run them with python3 -m unittest discover -s tests -v; you need tmux and ttyd. Tested on Ubuntu 24.04, Python 3.12, tmux 3.4 and ttyd 1.7.4.

The changelog also has an honest line about a fixed bug: starting the server on an already existing tmux session crashed it because of an undefined variable. Fixed.

About the AI assistant

Part of the code was written together with an AI assistant (Claude); the commit history shows this through a Co-Authored-By line.

Links

Repository: github.com/meshoklv/thumbmux, MIT license. Issues and PRs are open; please report vulnerabilities privately through GitHub Security Advisories. I post notes and new versions on Telegram at t.me/meshoklv.

Mike Meshok - github.com/meshoklv

A Claude Code status line that warns you before you hit the limit

Mike Meshok — Fri, 23 Oct 2026 01:10:37 +0000

The built-in footer in Claude Code doesn't tell you that the 5-hour limit is about to run out, or that 420K tokens in a 1M window already costs real money. So I wrote my own status line in plain Python with no dependencies: a context bar, remaining 5-hour and weekly limits, a "when will it run out" projection, session cost, git and uptime. Below: how it works, the decisions I made, and where it has holes.

[Opus 5.5] | ━━━━━━━━━━ 12% (120K/1000K) | H:91% 4h21m | W:73% | ⚙M+t | session $2.84 | my-app | ⏱ 1h 12m
 model       context bar                    5h left+reset  week    mode   cost           dir      uptime

Repository: claude-statusline, MIT license.

How Claude Code draws a status line

In settings.json you can set a command in the statusLine field. Claude Code runs it whenever the session updates and passes it JSON on stdin: model, context window, limits, cost and so on. Whatever the command prints to stdout is shown at the bottom. That gives the script its main property: no network, no tokens spent, one short Python process per render.

You can test it without Claude Code, straight from the shell:

echo '{"model":{"display_name":"Opus"},"context_window":{"used_percentage":12,"context_window_size":1000000}}' | python3 statusline.py

Three decisions that make it useful

1. Context color is based on absolute tokens

Typical indicators color the bar by percentage. On a million-token window that is misleading: 42% looks fine, but it is 420K tokens and every request is already expensive. So the bar's length shows the share of the window, while its color depends on the absolute load. The threshold is in the config: thresholds.context_red_tokens, 300,000 by default. From that value the bar is fully red, whatever the window size.

2. Limits are shown as what's left

H:91% reads as "91% of the 5-hour window remains", not "used". What I care about is runway, and having green at the start of the scale lines up naturally with "plenty left". The default yellow threshold is 50% remaining, red is 20%. W: is the same for the weekly window. These segments appear for Pro and Max subscribers after the first response and are hidden when there is no data.

3. Exhaustion projection

This is the only place where the script computes something instead of just displaying it. When the value changes (or more than 10 minutes have passed), it appends a sample to a small trend file: time, percent of the 5-hour window used, and the reset timestamp. The file is trimmed to the last 300 lines, and only samples from the current window count. Once there are at least 5 minutes of history and usage is growing, the script makes the simplest possible estimate: it takes the rate from the window's first sample to now and divides the remaining percent by it. The projection code is short, and this is the gist:

span, delta = t - first["t"], five_used - first["u"]
if span < burn_min_span_s or delta <= 0 or five_used >= 100:
    return None
return t + (100 - five_used) / (delta / span)

The result is shown only if the limit will run out before the window resets; otherwise there's no point alarming you. In the red zone the line looks like H:7% 2h10m, with a flame icon and "14m" next to it: at this pace the window ends in 14 minutes. The projection is linear and crude. It's the average rate since the start of the window, so a sudden spike in usage gets smoothed out and shows up late. That is a trade-off: I wanted neither a network call nor storage more complex than one small file.

The rest

Segments: model context five_hour weekly mode tokens cost dir git mcps uptime. Order, set, colors, bar width, separator and labels are configurable in ~/.config/claude-statusline/config.json, all optional. There are presets full, minimal (model, context, five hours) and compact, with English and Russian labels.

Notes on some segments:

mode shows the effort level L/M/H/XH/MAX, a thinking flag +t and +fast mode.
cost is hidden while it's zero and turns red from a threshold you set (10 dollars by default).
tokens is off by default because it reads the session and sub-agent transcripts, counting each streamed message once. The result is cached incrementally, but the files are read on every render, which is why it isn't enabled out of the box.
git and mcps are cached: the branch for 5 seconds, the MCP server count for 60.

Example config:

{
  "segments": ["model", "context", "five_hour", "tokens", "cost", "dir"],
  "colors": { "ok": "cyan" },
  "bar": { "width": 20 }
}

Colors can be names, #rrggbb or a number 0-255. The NO_COLOR variable is respected.

Installation, and what I tried not to break

git clone https://github.com/meshoklv/claude-statusline.git
cd claude-statusline && ./install.sh

Options: --lang ru, --preset minimal, --uninstall. Editing someone's settings.json is a little scary, so the installer does three things: it backs the file up first; it won't replace a different, already configured status line without --force; and --uninstall puts the previous one back. If settings.json is invalid JSON, the installer changes nothing and says so.

The second rule is that the script must never take down the status line. A broken segment is skipped, missing data is not an error, and if the cache can't be written it just runs without it. The state directory is created with mode 0700 (~/.cache/claude-statusline by default, overridable with CLAUDE_STATUSLINE_STATE_DIR).

Tests use the standard unittest: 29 in test_statusline.py and 8 in test_install.py. CI on GitHub Actions runs them on Python 3.8 and 3.12 and also checks that the demo page docs/demo.html hasn't drifted from the code. The demo is generated by the script itself (tools/render_demo.py) and shows real colored output in four variants: full, minimal, Russian, and "almost out of limit".

What isn't verified

Tested on Linux with Python 3.8 and 3.12 in CI. It should work on macOS but I haven't checked; Windows is not supported.
The JSON format Claude Code passes to the status line isn't mine and may change. If a field disappears, the corresponding segment silently disappears.
The projection is simple and linear (see above), with no rigorous science behind it.
I haven't measured render time or memory use, so the repo has no such numbers.

Also: timestamps on every message in the VS Code chat

While on the subject of small missing things around Claude Code: in the official VS Code extension, the chat never shows when you sent what. After a week-long session you can't remember what you asked for in the morning. There is a separate project for that, claude-native-timestamps: a small badge with the time, in your time zone and format, appears above each message.

A warning is due here. There is no API for extending the chat, so the project works as a patch: it appends to the end of webview/index.js inside the Claude Code extension a map of "normalized message text to earliest time" (built from your local transcripts in ~/.claude/projects) and a small script with a MutationObserver that inserts the labels. The original is saved next to it as index.js.cc-ts-backup, a Remove command restores everything, and a Claude Code update brings a clean file by itself. After an update the patch is applied again. If the chat markup changes, the labels simply won't appear and nothing breaks. Messages are matched by text, so where there is no transcript there will be no label. There is one label per turn, meaning a question and its answer count as one block. The project is not affiliated with Anthropic; it was checked on Claude Code 2.1.x on remote Linux and not tested from a desktop on macOS or Windows.

Links

github.com/meshoklv/claude-statusline: the status line, ./install.sh in a minute, one-command rollback.
github.com/meshoklv/claude-native-timestamps: message times in the VS Code chat.
Telegram: t.me/meshoklv.

If the status line shows wrong values on your plan or Claude Code version, open an issue with the output of echo '<your JSON>' | python3 statusline.py. A star on GitHub helps others looking for the same thing.

Mike Meshok - github.com/meshoklv - meshoklv.github.io

Benchmarking Russian speech recognition on CPU: T-one, GigaAM-v3 and cloud models

Mike Meshok — Fri, 23 Oct 2026 01:10:36 +0000

Most speech-model benchmarks are in English. The Russian ones I found rarely say what hardware a number was taken on, which license the weights carry, or what broke during installation. Russian is also a harder target than the headline English models suggest: the Cyrillic alphabet, rich morphology, and everyday speech full of English tech terms that have to come out in the right script. If you ship anything for Russian speakers, you end up having to measure for yourself.

I needed a voice agent that understands Russian speech over the phone and answers out loud (the project is ru-voice-agent). I installed and measured everything I could get running: recognition, synthesis and turn detection. The results, scripts and license checks are in ru-speech-bench. This post covers recognition: what I got on a plain CPU with no GPU, and why I don't put WER in the table.

First, the constraints, because they determine how to read the numbers. The measurements were taken in September 2026 on two machines: an 8-vCPU VM with a Xeon E5-2695 v2 (CPU only, no AVX2) and a desktop with an RTX 3090 Ti on Windows 11. Numbers are comparable within a table row and its hardware, not across rows.

Why not WER

An honest WER needs a human-transcribed reference. I don't have one. The recordings are personal: voice messages from 7 seconds to two minutes of ordinary conversational speech with English terms, and they are not in the repo. So you won't find "accuracy" or "WER" for my measurements. Instead I compute disagreement: how many words you have to change to turn one engine's text into another's. It is word-level Levenshtein distance divided by the length of the reference, after lowercasing, replacing "ё" with "е" and stripping punctuation.

What that means in practice is covered in docs/methodology/stt-disagreement-and-streaming.md. In short, 20% disagreement does not mean every fifth word is wrong. It includes insertions, spelling variants and errors in the "reference" itself. The metric is good for comparing variants of one system with each other (greedy decoder vs beam search, 16 kHz vs 8 kHz) and bad as a ranking.

To compare many engines at once I use the mean distance to all the others, "distance to consensus". That has its own catch: the metric rewards resembling the majority, and as you'll see below, the majority in my set is Gemini models.

T-one: streaming on one core

T-one from T-Bank is a streaming CTC Conformer with roughly 71.7M parameters (per the model card), trained on 80,000+ hours, mostly telephone speech. Apache-2.0. It takes audio in 300 ms chunks and finds phrase boundaries itself.

Hardware results

On a 53-second clip, greedy decoder, best of four runs:

ONNX Runtime threads	Time	RTF	CPU time
1	16.39 s	0.309	16.4 s
2	11.39 s	0.215	22.2 s
4	12.78 s	0.241	41.0 s
8 (default)	21.80 s	0.411	105.1 s

By default the library takes all cores, and that is the worst option: slower, and more than six times as expensive in CPU time as a single thread. I kept one thread. The table is noisy: the VM shared its host with another container, and the host load average in some runs was 8.9-19.3. Source: stt/results_threads.json.

In streaming mode on 8 kHz clips, one thread spends 99-123 ms on average per 300 ms chunk, p95 104-175 ms. With the greedy decoder, none of the 1091 chunks exceeded 300 ms, so the stream doesn't fall behind.

Latency until a phrase appears is determined not by CPU speed but by how long the splitter waits for silence. The default is 20 frames of 30 ms, i.e. 0.6 s. Average lag came out at 1.05-1.09 s. Setting MIN_SILENCE_DURATION = 6 brings it down to 0.64-0.65 s, and on the two clips I checked no words were lost. At a value of 2 things break: words get chopped, and disagreement jumps from 20% to 46% and from 41.5% to 64.6%. Two clips is not much, and the repo says so.

You can run several lines at once with a shared model and shared language model in one process: 1, 2 and 4 lines stay real-time, p95 around 110 ms. I did not measure more than four lines.

What T-one can't do

The output alphabet is the 33 Russian letters and a space. No Latin letters, no digits, no punctuation. "Excel", "4417" or "12 500" come out as Cyrillic words, spelled as heard. The language model can't help, because those symbols are simply not in the vocabulary. Another unpleasant thing: the language model (kenlm) turns letter noise into real words, but sometimes the wrong ones. A smooth wrong phrase is harder to notice than visible garbage, and the gain from the model is only 1.4-2.3 points of disagreement.

Disagreement against GigaAM as the reference: 20-22% on a clean clip, 41.5-46.8% on a quiet recording of two people. Compression for a phone channel (G.711 mu-law) did not hurt quality, and 8 kHz was no worse than 16.

Installation, separately. Beam search is the default, and without kenlm from_hugging_face() fails, so you must explicitly ask for DecoderType.GREEDY. kenlm has no wheels on PyPI, and pypi-kenlm doesn't build on Python 3.12. I built it without root: the compiler was the ziglang wheel, headers came from a standalone Python from uv, I removed the cmake step from setup.py, and the compiler wrappers dropped the unsupported -Wl,--exclude-libs flag. If the greedy decoder is enough for you, none of this is needed. One more thing: the upstream demo server listens on 0.0.0.0:8080 with no authentication, so bind it to 127.0.0.1.

GigaAM-v3: more accurate, but not streaming

GigaAM-v3 from SberDevices is a family of models on a HuBERT-like encoder pretrained on roughly 700,000 hours of Russian speech. I used the sherpa-onnx export: RNN-T with punctuation and an int8 encoder, about 232 MB on disk. MIT license.

It is an offline model: text appears after the whole file or segment is processed. In return it adds punctuation and capital letters, and handles digits and Latin text.

On my seven recordings on the same VM, four threads, under parallel load: median 12.8 s per file for lengths of 7 to 130 s, range 3.8-26.6 s. On the desktop I saw roughly 40x faster than real time, but I didn't record whether that ran on CPU or GPU, so treat the figure as approximate.

The vendor-reported average WER over five domains is 8.4% for RNN-T, 9.2% for CTC and 25.1% for Whisper in the same table; T-one with a language model is at 19.4%. Those are model-card numbers and I did not reproduce them.

GigaAM's weak spot is Latin terms and brand names. It writes them phonetically in Cyrillic or mangles them. This is fixed with dictionary post-processing; an example is in stt/gigaam_words.example.json, hooked up in gigaam_serve.py.

Gotchas: input must be mono, 16-bit, 16 kHz (run ffmpeg first). A stereo recording of a conversation is better split by channel, recognized separately and merged by time; stt_one_shot.py --dialog does that. On the noisy recording of two people, GigaAM did noticeably better than T-one.

Cloud vs local: a small check

I ran the same seven recordings through Gemini models with audio input (via an API aggregator) and compared them with GigaAM. The full table and caveats are in stt/cloud-compare/SUMMARY.md. An excerpt, distance to consensus and median time per file:

Engine	Succeeded	Distance	Time
gemini-3.1-pro	5/7	7.0%	61 s
gemini-3.6-flash	7/7	7.5%	12 s
gemini-3.5-flash	7/7	8.2%	17 s
gemini-3.8-flash	7/7	8.4%	13 s
gemini-3-pro	7/7	8.5%	44 s
gemini-3.7-flash	6/7	8.6%	12.5 s
GigaAM-v3, local on CPU	7/7	9.4%	13 s

What you can and can't take from this. The spread is only 7.0-9.4%: on this material the engines mostly agree, and they differ in terms, verbal filler and small substitutions. GigaAM is the "farthest" from the group, but the group is mostly Gemini variants, so the metric is biased against it. The pro models were the most verbatim but 3-5 times slower and the least reliable: 3.1-pro had two timeouts at 180 seconds. On Latin terms 3.6-flash did best, but results are unstable from version to version. A strict prompt ("don't add or guess, mark anything unclear") gave no gain on 3.6-flash and slowed it from 12 to 58 seconds. All ~55 calls cost about $0.04 by the aggregator's balance, which I did not verify independently.

Whisper and dedicated recognition endpoints through the aggregator were unavailable or had no keys, so they are not in the comparison.

The rest of the repo

It didn't stop at recognition, since the agent also has to talk. Briefly; details are in the cards under docs/engines/:

Kokoro-82M (Apache-2.0), Russian via espeak: RTF 0.76 on the Xeon, 0.2 on a 5950X, 0.05 on GPU; intelligible and lively, stress sometimes wrong.
ESpeech-TTS-1 RL-V2 on the 3090 Ti: RTF 0.17-0.36, first audio chunk in 1.1-1.5 s, 6 of 6 phrases spoken verbatim, places stress itself.
XTTS-v2: good streaming (first audio in 0.47-0.53 s), but the CPML license is non-commercial. F5-TTS with a Russian fine-tune: CC BY-NC 4.0.
Silero VAD 6.2.1: 0.51-0.58 ms per 32 ms chunk, roughly 55-62x faster than real time.
Smart Turn v3.2: about 171 ms per decision, but the default threshold over-triggered on my material.

I checked licenses against the official pages and put the check date in every card. The README's licenses section says commercial use is closed for XTTS-v2, F5-TTS, Fish open weights and Piper's ruslan voice, and that all four Russian Piper voices are fine-tuned from an English voice that is research-only, so commercial use there is unverified. This is not legal advice.

What to know before quoting these numbers

Four clips for T-one and seven for the cloud comparison; the recordings are personal, mostly one speaker, and there is no reference.
The splitter threshold was checked on two clips.
Timings from the cloud run are noisy: runs of different engines overlapped in time on one machine and network.
Before publication the scripts passed python -m compileall, but I didn't re-run most of them. The numbers come from the original runs, before cleanup. You will probably need to adjust paths and model names.
No audio or weights are included; put your own recordings in ./refs/ and ./models/.

Reproducing it

pip install sherpa-onnx numpy
export GIGAAM_MODEL_DIR=./models/sherpa-onnx-nemo-transducer-punct-giga-am-v3-russian-2025-12-16
python stt/gigaam_serve.py clip.wav --timing        # mono, 16 kHz, 16-bit
python stt/stt_one_shot.py clip.ogg                 # any format, ffmpeg is called for you
python stt/cloud-compare/analyze.py raw stt/cloud-compare/timing.jsonl

If you have your own recordings and hardware, send a card for a new engine or numbers from another machine. The template and rules are in CONTRIBUTING.md: license with a link and date, hardware, command.

Repository: github.com/meshoklv/ru-speech-bench, MIT for code and docs; the engines keep their own licenses. Updates on Telegram at t.me/meshoklv. If this was useful, a star on GitHub helps others looking for the same thing find it.

Mike Meshok - github.com/meshoklv - meshoklv.github.io

Running Dark Souls on an iPhone: what I had to fix in Madeira

Mike Meshok — Fri, 23 Oct 2026 00:20:19 +0000

Since late September I have been running PC builds of Dark Souls on an iPhone Air through the Madeira emulator. Remastered is now playable with an on-screen gamepad. In heavy scenes of Dark Souls III the median went from roughly 20 to 36.7 FPS on an experimental build. Along the way I collected 5 merged and 11 open PRs against Madeira, Wine, FEX and DXMT, plus a repository of scripts, which I'm publishing now.

A caveat up front: I have one phone (an iPhone Air on iOS 27.2 beta) and one tester, me, so every number below comes from that single device. The games are my own, bought legitimately. The repository contains no game files, no save editors and no copy-protection circumvention, and I won't accept any.

What Madeira is

Madeira runs x64 Windows programs directly on an iPhone. It has three layers:

FEX-Emu translates x86-64 to ARM64 on the fly (JIT);
Wine provides the Windows API;
DXMT turns Direct3D 11 calls into Metal.

For JIT on a non-jailbroken phone I use StikDebug. Madeira's built-in helper needs a separate App ID, and my signing script strips it.

The project is strong, but "install it and run a heavy game" doesn't work out of the box. You need to know which entitlements to re-sign the app with, which of the dozens of config keys actually change anything, and how to tell from a log what went wrong. I wrote that unwritten knowledge down and automated the boring parts.

Dark Souls Remastered: eight problems in a row

I worked on it from September 27 to October 19, 2026. Every step looked the same: one run, one log, one change. A small script, tools/analyze-log.py, reads the log and reports what Madeira actually accepted from the environment, the module load order, exceptions with register dumps, whether graphics, window and audio came up, and how the run ended.

The full table of causes is in docs/bugs-and-fixes.md. Here are the ones I remember best.

Crash at startup, c0000018. The exe has a fixed base below 64 MB, but it needs a window at 0x140000000, and that range was not being handed out. This was already fixed upstream (Madeira #111), so I only had to pull it in.

Crash after the first writes to code. The game is protected by a layer that rewrites its own code at runtime, and that made everything fall over. The cause turned out to be a leak in Wine: on the [exec-req] return path in ARM64EC ntdll, leave_syscall_callback() was never called, so the "we are inside a syscall" flag stayed set. A one-line fix, wine #18, merged.

Crash in steamclient64, c0000005. This one is more interesting. The Steam client truncates an HMODULE to 32 bits, and iOS can't map memory below the 4 GB line, so the module lives at a high address and the truncated pointer points nowhere. I made an image with a "narrowed" base get a low-address name, and made VirtualQuery report as free only the memory that can actually be taken. That is Madeira #385, still open. Because of it, my phone build is upstream plus one unmerged commit, and without that commit DSR crashes at startup.

Crash while looking up the settings folder. The Wine profile C:\users\<user> simply had no AppData. A script creates the folders (device.py profile fix), and apply-config.sh calls it too.

Gamepad: three bugs in one chain

This took the longest, because the symptoms differed and three independent places were at fault.

The game doesn't see the gamepad. The game folder contains its own xinput1_3.dll, and the loader picked it over the built-in one. Fix: the loader prefers the built-in XInput (wine #19, merged).
The game sees the gamepad but ignores it. The game window wasn't active, and on iOS there is nobody to activate it. Now win32u makes the process's main window active while it polls XInput (Madeira #149, merged).
A tap that missed an on-screen button turned into a mouse click. While the gamepad layout is shown, such taps no longer count as mouse input (Madeira #150, merged).

Two things helped: return addresses in the diagnostics, and logging of the key-press chain. That is how the gap was found. I now keep such diagnostic patches around.

A crash 35 seconds into the settings menu

This was the emulator's own watchdog. It counted handled self-modifying-code writes cumulatively, and in the settings menu the game rewrites code every frame, cycling through seven keys. It reached the threshold of 2000 in about half a minute, and the process was killed. Now only consecutive identical failures on one thread are counted (Madeira #148, merged).

After these fixes I was listed in Madeira's own Settings > Credits: "Controller fixes ... and a crash-guard fix".

Two lessons from this stretch. First: check what is actually loaded, not what the config says. Image size and base address in the log lie less often than the settings file. Second: a clean CI build beats a build assembled from whatever was lying around. One of my builds, made from a mix of old and new parts, crashed in signal_set_full_context, while the clean CI one did not.

Dark Souls III: from 20 to 36.7 FPS

DS3 is heavier. Steam is installed from inside Madeira (Madeira Dock) with your own account. Cutscenes run at 60 FPS; in combat on default settings it was 17-20.

From there it was a measurement exercise. I broke logs down by phase: FPS, GPU load, core frequencies, draw calls per frame. The parsers are in tools/ds3perf/, and the conclusions, each tagged "fact" or "hypothesis", are in docs/perf/. There are 22 notes there, in Russian.

The phone heats up and clamps its clocks

The least pleasant finding, from DS3-POWER.md. In one long session, the P-cores ran at 2.8 GHz for the first seconds and gave about 34 FPS. Around the 59th second a clamp kicked in: frequency dropped toward 1.8 GHz and median FPS fell to 20.6. At 175 seconds iOS reported the serious thermal state, which changed nothing further. So any optimization has to be measured on a hot phone, otherwise the numbers are pretty and useless.

What worked

I named the change sets with letters. This is the table from docs/compatibility.md, median in heavy scenes:

Step	FPS	What changed
base set C2	~17-20	pool separation, no image copying, orphaned locks get flagged
G1	21.5	lighter diagnostics, in-process synchronization, fast path for x64 critical sections, write windows for hot code pages
H2	36.7	buffer and command-list reuse in DXMT, fast TLS, lighter SRW locks, thread QoS by name

For H2 in heavy scenes: median 36.7 FPS, p10 28.8 over the first minutes of a 12-minute run. After warm-up, with the P-cores sitting at 1.31 GHz, it holds 32-34 FPS. The GPU is about 88% busy, so now it is the bottleneck rather than the CPU.

Now the honest part. The 36.7 figure is the sum of several changes. I did not measure the contribution of each one separately, and every PR says so explicitly. G1 had a 26-minute run with no hangs and a median of 21.5.

What I tried and dropped:

MetalFX: got worse;
pool-low: got worse;
skipping self-modifying-code writes that have the same bytes: pointless, since 93% of the writes change the bytes.

A separate note about DXMT. It turned out to create about a thousand Metal buffers per frame, and roughly 50 times per frame it allocates and frees 2 MB for command lists. Two keys (DXMT_DYN_KEEP and DXMT_CMDLIST_KEEP_BLOCK) remove that churn, and both are off by default (dxmt #42, #43).

Black screen and a hang in DS3

Two separate DXMT bugs, both described in DS3-CRASH.md and DS3-FREEZE.md.

Black screen: when asked for an SRV description covering "all mip levels", DXMT returned MipLevels = -1. The game takes that number as the level count and allocates an array from it, then crashes. Now the resolved value is returned (dxmt #40).
DS3 hang: a backport of a fix from 3Shain/dxmt, where the draw-argument marshaling loops for GS/TS did not advance (dxmt #41).

I have not fully tested the gamepad or saves in DS3; the repository lists this under "not tested".

What's in the repository

madeira-kit is tooling around the loop of build, sign, install, configure, run, read the log, change one thing. It is not a fork of Madeira: I sent fixes upstream, and patches/ only holds reference copies.

unpack.sh, swap-dll.sh, sign.sh, install.sh: unpack a build, drop in patched DLLs, re-sign with your own certificate, install while keeping app data;
doctor.sh: a pre-flight check (phone visible, app installed, at least 3 GB free, game copy present);
apply-config.sh: upload madeira.cfg, read it back and compare, create any missing profile folders;
pull-log.sh and analyze-log.py: fetch the log and analyze it right away;
ready-made profiles for DS1 and DS3 in configs/.

The minimal path:

git clone https://github.com/meshoklv/madeira-kit && cd madeira-kit
cp scripts/config.example.env scripts/config.env && $EDITOR scripts/config.env
scripts/unpack.sh ~/Downloads/Madeira-build.zip && scripts/sign.sh && scripts/install.sh

scripts/doctor.sh
scripts/apply-config.sh configs/ds1-play.cfg
# swipe Madeira away, enable JIT in StikDebug, start the game
scripts/pull-log.sh first-run

You need a Mac with Xcode command line tools, an iPhone on USB, a certificate and provisioning profile for your bundle id, and pip3 install pymobiledevice3. The entitlements for extended memory and extended virtual address space require a paid developer account.

If you build Madeira on GitHub Actions yourself, the pitfalls are described in docs/guide.md: LLVM as static libraries only, TUNE_CPU=cortex-a78 for FEX, and a stub for ri_page_wait_time_mach. The Windows part of DXMT is not rebuilt by this CI.

What I don't know

The scripts are my working pipeline with personal identifiers removed. After that I syntax-checked them, but I did not re-run them end to end on a device.
Other iPhone models and iOS versions are untested, as is a fresh clone of the repo on a second machine.
I did not measure FPS or heat in Dark Souls Remastered itself, only "it's playable".
All DS3 numbers come from one phone and a handful of runs, mostly a single run per configuration.
A free developer account may not grant the required entitlements.

How to help

If you have a different iPhone or iPad, send a compatibility report: model, iOS version, game, config and result. Profiles with measured numbers are welcome. Cracks, game files and anything that bypasses protection are not.

Part of the code and patches was written together with an AI assistant (Claude); in the commits of the upstream PRs this shows as a Co-Authored-By line.

Repository: github.com/meshoklv/madeira-kit, MIT license for the scripts and docs; the patches follow the licenses of the projects they target. Issues and PRs are open. I post notes and new builds on Telegram at t.me/meshoklv. If the article was useful, a star on the repo helps others find it.

Mike Meshok - github.com/meshoklv - meshoklv.github.io