What v0.11 ships

The point of the bench work is that you shouldn't have to read it to get a good install. v0.11 looks at your Mac on first launch — how much RAM, Apple Silicon or Intel — and picks the right models for each task. You can override anything in Settings, but the defaults aim to be the right answer out of the box.

Remember This runs three jobs against your archive, each picked separately because the trade-offs are different:

• Photo Understanding — captions every photo and video so you can search by what's in them, not just when they were taken.
• Audio Transcription — voice memos and video soundtracks become searchable text.
• Dreamer Sessions — periodically, Claude Code reads through the day or week's captions, transcripts, and time logs and writes a synthesis: a rollup, an open question, a long-horizon nudge. Heaviest job; benefits most from a fast LLM.

Photo Understanding — defaults per Mac

Apple Silicon with 16 GB+ runs SwiftLM, a new Apple-MLX-based runtime bundled in v0.11. It's what runs the MLX-native VLM families (Qwen3-VL, Gemma-4-Vision, FastVLM) that don't have an ollama equivalent at our quality bar. The 48 GB+ row unlocks Qwen3-VL-8B, the side-by-side quality winner in our caption eval; the 32 GB row uses Qwen3-VL-4B, the best speed-and-quality tradeoff at that tier. Both scored in detail in the VLM matrix further down. Intel Macs fall back to ollama (MLX is Apple-Silicon-only). For LLMs the runtime verdict goes the other way — see finding #3.

Audio Transcription — defaults per Mac

Plus a backend pick per machine: Metal (Apple's GPU framework) on Apple Silicon, where it's 8–22× faster than CPU; CPU on Intel, where Metal on the older Radeon Pro discrete GPU is both slower than CPU and crashes on long audio — see finding #1.

Dreamer Sessions — defaults per Mac

Hosted Claude (claude.ai) is the default on every Mac, including the 64 GB+ tier — best long-context coherence, no first-pull download, single privacy stance. Flip the toggle in Settings to use a local LLM instead and v0.11 picks one sized for your tier:

qwen3.6:35b on 64 GB Apple Silicon runs at ~24 tok/s with a 32 K-token conversation behind it — the highest-quality model that's still fast enough to chat with at that point. gemma4:e2b also holds up at long conversation lengths but is a much smaller model. Intel users get gemma4:e2b: the only model we tested that stays usable on an Intel CPU at 32 K tokens of history. Users who prefer SwiftLM-local (Apple Silicon only) can flip the runtime in Settings; finding #3 below shows why ollama is the default. The SwiftLM model picks for the same tiers are Qwen3-8B at 32 GB and Qwen3.6-35B-A3B at 48 GB+.

Battery awareness

Each background job has its own rule for when to run — voice transcription runs anytime, photo captioning pauses on battery, Dreamer is manual. The bench work turned up two ways the GPU silently slows down on Apple Silicon: when Low Power Mode is on (5–6× slower), and when the battery drops below ~5 % (another 2–3× even with High Power Mode set). An overnight catch-up on a draining battery uses ~3× the energy for the same captions and runs ~10× slower in the final hour. The default avoids both. Each rule is overridable per job in Settings → Background, which also shows the current power state so it's obvious why any job is paused.

Six findings worth pulling out

The picks above are mostly a packaging job — pick a model per RAM tier per task, ship it. The more interesting part of two weeks of benching is below: observations about local AI on Mac in May 2026 that are useful whether or not you ever touch Remember This.

1. Transcription runs ~32× faster on Apple Silicon than Intel

Same audio clip (60 s of LibriVox Sherlock Holmes, public domain), same large-v3-turbo model, same bench script. A 10-minute meeting transcribes in ~18 seconds on M1 Max with Metal, and in ~9 minutes on an Intel i9-8950HK with the CPU path. On Intel, the GPU path (Metal on the Radeon Pro 560X) is actually 2× slower than the CPU path and crashes reliably on any audio longer than ~3 minutes. So Intel picks CPU automatically; there's no Metal/CPU toggle in Settings on Intel, because the one right answer is already in place.

Update: the full 65-minute Holmes chapter now has a real number, not an extrapolation from the 10-minute clip — 117.9 seconds on M1 Max Metal, holding the same 0.03 s/s-audio rate the 10-minute clip predicted (within 8 %). That's 33× real-time: an hour of clean speech transcribes in under two minutes. We also checked whether that number is specific to clean audiobook narration by running a completely different speech style — a slow, conversational 1939 radio address with natural pauses (FDR's Fireside Chat #14, 11 minutes) — through the same Metal path: 0.027 s/s audio, marginally faster than the audiobook, not slower. On Apple Silicon Metal, content style doesn't move the number; budget ~0.03 seconds of wall time per second of audio for any clean single-speaker recording.

The "Intel Metal crashes" bug specifically: sona aborts with GGML_ASSERT(buf_src) failed in ggml-metal-device.m:1561, deterministic across retries. The same audio on Apple Silicon Metal runs cleanly. Reproducer + cross-platform comparison: gotchas/polaris-whisper-crash-long-audio.md.

2. On SwiftLM, LLMs slow down a lot when conversations get long. On ollama, they barely slow down.

We started out assuming all LLMs get slower the longer the conversation gets — the bigger the chat history, the more work per word. The first sweep on M1 Max was all SwiftLM, and looked like the textbook curve: Llama-3.2-3B dropped from 54 to 24 tok/s as the prompt grew from 4 K to 16 K tokens. Every other SwiftLM row in the matrix follows the same shape.

Then we ran the same models on ollama. They stay nearly the same speed across the whole range:

Same hardware, same Apple GPU underneath — but at 64 K tokens of context, SwiftLM has slowed down 30× while ollama has slowed down 1.5×. So the slowdown comes from how the runtime is built, not from the hardware. The mechanism, roughly: SwiftLM sends many tiny instructions to the GPU per word it produces, and the cost of that overhead grows with the conversation length. ollama (via llama.cpp) batches more aggressively, so the same overhead barely shows up.

What this means in practice: SwiftLM is fine for short chats (~8 K tokens or less, roughly a few thousand words of history); past 16 K its speed drops sharply. For a Dreamer session — which builds up context as it reads photos, voice memos, and time logs — ollama is the right pick on M1 Max.

3. On M1 Max, ollama beats SwiftLM on LLMs — and by more when conversations get long

We started out saying "ollama on Intel, SwiftLM on Apple Silicon, because SwiftLM is 10–15× faster than ollama on the big efficient (MoE) models we care about." That was based on a single short-conversation test of Qwen3-Coder-30B. When we later ran a full head-to-head across five model classes and a range of conversation lengths (4 K to 64 K tokens), the verdict flipped:

ollama wins on every model we tested. The two are roughly tied at short conversations and ollama pulls ahead as the conversation gets longer. Only Qwen3.6-35B-A3B at very short prompts (4 K, 8 K) still favours SwiftLM, by 1.3–1.5×. Past 16 K, ollama wins everywhere, and the gap widens: 2–3× at 4 K becomes 22–45× at 64 K. The biggest gap is gemma-4-e2b at 64 K, where ollama holds 49.5 tok/s while SwiftLM drops to 1.1. The reason is in finding #2 above — it's how the two runtimes are built, not the models or the hardware.

What this means for the v0.11 picks: the Dreamer-tier Apple Silicon defaults are now ollama, not SwiftLM (Hosted Claude remains the top-level default). SwiftLM stays as the VLM runtime — the MLX-only VLMs we ship have no ollama equivalent at our quality bar. SwiftLM-local Dreamer is still selectable in Settings for users who specifically want a single-stack setup.

Update: at first publish, the SwiftLM side of the Qwen3-Coder-30B-A3B test was unfinished (battery died mid-run) — it's the model that produced the original 10–15× SwiftLM claim, so it was the one place ollama might still have lost. It's done now: SwiftLM ran 16.8 tok/s at 4 K down to 1.4 at 64 K; ollama ran 54.5 down to 24.1 over the same range. Same pattern as every other model — ollama wins everywhere, 3.2× at 4 K widening to 17× at 64 K. The matrix below now has a clean row for both. A second update: the Qwen3-Next-80B-A3B row below has also been partially re-benched clean (4 K–16 K); see the note under the matrix for why 32 K–64 K are blank instead of showing the old numbers.

4. macOS quietly slows the GPU when battery drops below ~5 %

Same model, same M1 Max, same High Power Mode setting in both runs. Morning, full battery: Llama-3.2-3B at 4 K ran at 54 tok/s on SwiftLM. Evening, 2 % battery: 18.8 tok/s on the same hardware. 2.9× slower from battery alone. It gets worse at longer conversations — at 32 K, the speed dropped from 8 to 0.4 tok/s. This is on top of the better-known slowdown when macOS Low Power Mode kicks in (another 5–6×). All the "clean" Apple Silicon numbers in this post assume the laptop is plugged in or above ~5 % battery. If you bench on battery, watch for it.

5. Photo captioning runs ~15–24× faster on Apple Silicon than Intel

Same model (Qwen3-VL-2B weights): 53 s per photo on Intel via ollama, 3.6 s per photo on M1 Max via SwiftLM. For the typical photo (less text in the image to read), M1 Max is closer to 24× faster. Almost all of that comes from Apple Silicon's shared memory + MLX framework + the GPU running the model directly. The gap is big enough that "do you have Apple Silicon" is the most important question for anyone deciding whether local AI is worth running on their photo library.

6. SwiftLM's first request after loading a model is 3× slower than every request after it

Found while completing the Qwen3-Next-80B-A3B re-bench (the ‡ row above): 4 K ran at 3.4 tok/s, then 8 K ran at 11.8 and 16 K at 10.3 — backwards from every other row in the matrix, where 4 K is always the fastest point, not the slowest. Re-running just the 4 K case after a small throwaway request landed at 6.7 tok/s: better, but still short of the ~11 tok/s the model settles at.

The cause is Apple's MLX framework compiling GPU kernels the first time it actually runs a given operation shape — loading the model onto the GPU doesn't trigger this, only the first real generation does. It's a one-time cost per SwiftLM process, not a property of any particular context size, so it happens to land on whichever row a bench script tests first — in this case 4 K, making it look artificially slow relative to 8 K and 16 K next to it. A trivial warmup request only partly compensates; it needs to be roughly the same shape (context length, thinking mode) as real traffic to fully absorb the cost.

Practical takeaway if you're building on SwiftLM: every 4 K-context number in any ctx-sweep you read (including several tables in this post) may be a mix of this one-time compile tax and genuine short-context speed — treat isolated first-request numbers with suspicion, and warm the runtime with a full-size dummy request before serving real traffic if session latency matters. Remember This's SwiftLM sidecar currently treats "model loaded" and "ready to serve" as the same signal (a /health check, not a real generation) — so today, a user's first Dreamer or caption request after a cold start eats this cost directly. That's a concrete follow-up for the sidecar, not yet shipped.

Full writeup: gotchas/swiftlm-cold-start-ramp-up.md.

The full matrices

All the numbers behind the picks at the top of the post. Detail-heavy — the findings above are the takeaways; these tables are for "OK but what about model X."

Reproducing this on your hardware

We benched exactly one Intel i9-8950HK / 32 GB and one M1 Max / 64 GB. If you have something else interesting — a higher-core Intel, 16 / 96 / 128 GB Apple Silicon, an M2/M3/M4 of any tier — please run the bench scripts and contribute results.

Full bench harness, raw numbers, gotcha writeups, and PII-clean aggregate matrices live at github.com/rememberthis-ai/local-ai-benchmarks. The transcription bench specifically (with the canonical LibriVox clip via git-LFS) is at transcription-bench/. Aim for the model list we used plus extras you care about, then open a PR with your results.

Your results may vary — especially with power mode. All Apple Silicon numbers above are with the Mac plugged in and Low Power Mode off. macOS Low Power Mode throttles the M1 Max GPU 5–6×, and it auto-enables on battery below ~20 %. Check with pmset -g | grep lowpowermode before benching; expect 2–6× slower numbers if it's on. The gotchas/ dir in the bench repo covers a half-dozen other silent ways local-AI numbers can be wrong — ollama 4 K prompt truncation, sona's --gpu-device -2 not actually disabling Metal, Gemma-4 repetition collapse at long context, etc.

v0.10.x continues to ship ollama + MiniCPM-V 4.5 as the captioner; the picks above land in v0.11.