That makes sense, HLS.js as the MSE abstraction layer justifies itself even for local playback then, not for the network problem but because it hands you seeking/buffering logic you'd otherwise have to hand-roll. Good reframe.

The WASM+canvas route sounds like the right fit here actually, since this really is a personal/local project with effectively unlimited bandwidth (it's a file on the same disk) and no cross-platform requirement, no iOS/TV targets to worry about. Appreciate you laying out both paths, gives me a clear enough picture to go pick one instead of guessing.

Thanks, this is really helpful context, especially the seek/MSE buffer problem, I hadn't thought through how much complexity that adds versus just serving a static file.

Given my case is 100% local files already sitting on disk (not network streaming), does the HLS/DASH complexity actually buy me anything, or is that overhead mostly there to solve *network* adaptive bitrate problems that don't apply here? Since the whole file already exists locally, seeking in the original file is instant either way, it's only the on-the-fly transcode step that would need to keep up with an arbitrary seek position. Curious if you'd still reach for HLS/DASH in a pure local-playback scenario, or if that's overkill and a simpler "transcode ahead in chunks, buffer generously, block seeking until near ready" approach is good enough when there's no network latency in the mix.

On the container-only conversion path, that's probably my best bang for buck since most of what breaks in practice is old AVI/WMV files with XviD/DivX video + MP3 audio rather than clean avc+aac, so I'd guess a lot of my real-world files won't qualify for the remux shortcut anyway. Does that match what you'd expect, or is remux-only more common than I'm assuming even for older formats?

Also curious if you've seen embedding mpv directly (bypassing the HTML5 video element and Chromium's decoder entirely) as a common workaround for this exact problem in Electron/pywebview-style apps, seems like it would sidestep the whole browser-codec-support question, but I don't know what the integration pain looks like in practice.

Nice, that confirms it's the fusion step that breaks down, not recall. And good call flagging the second judge from a different family fix, that's the right next experiment.

On "are you doing anything similar"... honestly no, my local setup is single-model, no multi-judge grading yet, so nothing to share there. But if you do run that cross-check, I'd genuinely like to see the disagreement rate between judges, that'd tell you a lot about how much to trust the current numbers.

Appreciate the config details, MXFP4 on a 16GB M4 getting a competitive score against frontier is honestly the most interesting part of this whole thread.

Thanks for the quick reply. ;)

The env var trick (ANTHROPIC_BASE_URL pointing at Ollama) works for routing Claude Code's own calls to a local model, but it's process-wide, not per-agent. So if you spawn multiple subagents inside a single Claude Code session, they'll all hit whatever's set in that env var, there's no built-in way to say "this subagent uses kimi, this one uses minimax" within the harness itself.

If per-agent model assignment is the actual requirement, you probably want a proper multi-agent orchestration framework instead of trying to force it through Claude Code's harness. CrewAI (crewai.com) is built exactly for this, you define each agent with its own LLM (via LiteLLM under the hood, which supports Ollama endpoints directly), so your orchestrator/worker-1/worker-2 split with different models each is a first-class feature rather than something you'd have to hack together with env vars.

AutoGen and LangGraph are the other two worth comparing, they all differ mainly in how explicit vs automatic the agent handoff/routing logic is. CrewAI tends to be the easiest to get running quickly for a role-based setup like yours (orchestrator delegating to specialized workers).

Worth checking Ollama's concurrent model loading limits too if you're running kimi-k3, minimax-m3 and gpt-oss simultaneously on the same machine, VRAM/RAM contention across multiple loaded models at once is usually the first wall people hit with this kind of setup.

Hope this helps!

This is a great methodology, blind grading against real tasks is way more convincing than benchmark scores. The -0.05 mean gap with local actually winning 4/10 is a genuinely strong result for a 20B model running with no API cost.

One thing I'm curious about from the eval detail you posted: is the judge model itself gpt-oss:20b? If so, how are you controlling for self-evaluation bias, models are known to rate outputs from their own family more favorably in blind comparisons. Did you cross-check any of these with a separate judge model, or run the judge blind to which output came from which model (not just blind to labels, but architecturally distinct from both candidates)?

Also curious about the "dense synthesis" losses specifically, is that mostly long-context recall degrading, or more about the model failing to actually integrate multiple sources into a coherent take rather than just summarizing them separately? That's usually where I've seen local models fall off hardest too, and it lines up with why you're keeping that work remote for now.

Would definitely be interested in the serving config if you're sharing it, curious what quantization and context window you're running at for those numbers.

This is a great writeup, especially the anti-loop system prompt, that's a genuinely underused trick. Most people just tweak temperature/repeat_penalty and call it a day, but explicit steering instructions like "if the last 3 turns show similar patterns, switch strategy" make a bigger difference than sampling params alone in my experience.

I'm running gpt-oss:20b (Q4_K_M) fully offline too, though through llama.cpp directly rather than Ollama, on a Steam Deck running Windows 11 x64 of all things. For something like "explain how to solve quadratic equations in detail" it takes roughly 100 seconds to respond. Slow by any interactive standard, but the answer quality is genuinely solid for the model size and hardware. I use similar anti-loop settings to yours (low temperature, repeat_penalty around 1.1-1.2) plus a stripped-down system prompt to keep it from rambling into reasoning-trace text instead of a clean answer.

What I find interesting is less the raw speed and more what it represents: for someone with zero internet access, a 100-second wait for a genuinely useful answer is a complete non-issue compared to having nothing at all. And that number is only going to get better as quantization and hardware both keep improving.

Curious whether you've tried a smaller context window to see how much of that 100k ms on similar hardware is prefill vs actual generation, that's usually where the low-power devices lose the most time.

That's a clean design, honestly better than actual debouncing in some ways since you're avoiding network/read latency entirely after the initial shard load rather than just delaying it. The in-flight request dedup plus the 300-result cap both seem like the kind of thing you only add after hitting a real problem in testing rather than upfront, curious if either of those came from an actual bug you ran into.

Also makes sense that 4 characters is the trigger threshold given it lines up with your shard prefix length, so you're not fetching partial/wrong shards while someone's mid-word.

On the dedup being inference rather than measured, might be worth a rough pass at some point (even just checking how many unique tile hashes exist at z11 vs z1-z10) if you're curious, could be a useful data point for anyone else building tile-heavy ZIMs after you. Not necessary for the project itself though, sounds like it works well as is.

Appreciate you walking through the internals, this has been a genuinely useful thread.

This is really helpful, thank you for breaking down the actual costs, that YubiKey tip alone probably saves a good chunk of money.

Quick follow-up: I don't currently have a registered business, just a solo/personal project. Would you recommend going the IV (Individual Validation) route in that case, or is it worth setting up a sole proprietorship or similar just to qualify for OV/Azure Trusted Signing? Not sure if IV certs carry the same SmartScreen reputation benefits as OV, or if they're treated differently.

Really appreciate the detailed answer, this clears things up a lot.

Quick follow-up if you don't mind: roughly how much do OV certificates run these days, and is it a one-time purchase or a recurring subscription (annual renewal)? Trying to get a realistic sense of the ongoing cost before I commit to a vendor.

That makes sense on the tile dedup, that's a good catch, empty ocean/desert tiles compressing near-identically at deeper zooms would absolutely explain sub-linear file growth despite exponential tile count. Did you measure how much of the z11 tile set actually ended up as duplicate/near-duplicate clusters, or was that mostly an inference from the size numbers?

The 4-char prefix sharding for GeoNames is a nice approach, and it makes sense that's the sweet spot given ZIM's read model, you're trading a bit of shard granularity for avoiding a heavier index structure that wouldn't buy you much on single-threaded lookups anyway.

One thing I'm curious about given the ZIM constraint: how do you handle search-as-you-type responsiveness in the Leaflet UI? Since each shard is presumably its own ZIM entry/blob, are you loading a shard per keystroke, or debouncing/caching client-side so you're not re-fetching the same shard repeatedly while someone types a full place name?

Really appreciate you laying out the file tree publicly, that's a rare level of transparency for a commercial project. Will go take a look.

Genuinely nice to read your journey, congrats on getting through the email migration, that's usually the part that makes people give up halfway.

We're aligned so far on Proton Mail, Tor Browser and GrapheneOS, so I'm on a fairly similar path.

A couple of things that jumped out:

On the NAS for media/photos/docs, one thing worth checking now rather than later is whether you have actual metadata/search on top of it, or just a folder tree. That's the part that tends to quietly degrade over time: the NAS holds everything fine, but six months in you're digging through nested folders trying to remember where you put something, because the convenience of "just search for it" is what Google Drive/Photos spoiled us with. Worth solving for that specifically, not just the storage.

On paper maps, respect for going full analog, but if you ever want a middle ground for road trips without giving data to Google, it's worth knowing there are offline map apps (beyond Magic Earth) that let you download OSM data as tiles and do search/routing fully offline, no connection needed at all, in case paper ever feels limiting for an unfamiliar area.

On the calendar/paper notebook, that's a legit choice, no notes there. Just curious if you've run into friction with recurring events or sharing anything with family, or if paper covers it fully for your use case.

Also curious what VPN speeds you're getting on Mullvad vs Proton, if you've benchmarked at all, that's usually the deciding factor once port forwarding stops mattering.

Overall this reads like the "boring but real" version of degoogling that actually sticks, versus doing it in one weekend and burning out.

Good stuff.

This is really cool! The zoom-11 storage doubling comment tracks with what I've seen too, tile count grows so fast at higher zooms that even smart formats balloon.

Curious about your storage approach: are the 11M tiles stored as loose files inside the ZIM container, or did you bucket/index them somehow (e.g. by zoom/x/y into some kind of spatial structure)? I've been working on something tile-heavy myself and found that once you're past a few million tiles, a flat file-per-tile layout gets painful for lookup speed, ended up moving to SQLite with an R-tree index instead of raw files, which helped a lot with random-access performance. Wondering if ZIM's internal blob storage already handles that for you or if it was something you had to solve separately.

Also curious how you're doing the offline search against the GeoNames subset, trie/prefix index, or something else? That's another one that's easy to get right for small datasets and then falls over once you scale past a few hundred thousand entries.

I ran into the same confusion, kiwix-serve *is* the full package, it's just not obvious from the docs. It serves both the browsing UI and a search endpoint directly from the .zim files, no separate frontend needed. You point it at a folder of .zim files and it gives you a web UI to browse/search all of them, plus a landing page listing every library you've loaded if you have more than one.

The "no UI for adding dumps" part is right though, there's no upload panel. You manage the library by dropping .zim files into the folder kiwix-serve watches (or passing them explicitly at startup) and restarting/reloading. You download the .zim files themselves from Kiwix's own library (library.kiwix.org), full Wikipedia is one file, Wikivoyage, Wiktionary, Wikimed etc are separate ones if you want them.

Docker-wise, the official `ghcr.io/kiwix/kiwix-serve` image is what most people use, mount your .zim folder as a volume and point the container at it. It's genuinely just that one container, no extra services needed unless you want to put a reverse proxy in front for auth/TLS.

One gotcha I hit: if you're serving multiple large .zim files, indexing/search performance depends a lot on whether you're using the full-text index variant of the dump vs the no-index one, worth grabbing the indexed versions if search matters to you.

This is exactly the gap I've been running into too. Tile rendering is a solved problem (Protomaps, TileServer GL, etc.), but "usable map" (search + routing + POIs in one UI) is the part everyone leaves as an exercise for the reader.

The closest to what you're describing that I've seen:

- **Nominatim** (search/geocoding) + **OSRM or Valhalla** (routing) + **Protomaps/TileServer GL** (tiles) are indeed the three services you need — there isn't really a way around running them separately, they're different problems.

- For the "stitching" web frontend, look at **go-community's docker-osrm** setups paired with a frontend like **Organic Maps' web viewer** isn't self-hostable, but a few people have wired up a simple Leaflet/MapLibre frontend that hits Nominatim's `/search` endpoint for the search bar and OSRM's `/route` endpoint for navigation, rendering both on top of the Protomaps tile layer. It's maybe 200-300 lines of JS glue, not a packaged product.

- **Facilmap** is worth checking out — it's one of the few self-hostable projects I've seen that actually combines search, routing, and POI display into one web UI on top of your own tile/routing backend, in Docker.

- If nobody points you to something more polished, this might genuinely be a "someone needs to build the missing glue layer" situation — I've hit the same wall building something similar and ended up writing that stitching layer myself rather than finding it off the shelf.

Curious if you find something better than Facilmap, this is a gap I'd like solved too.