Paddyz

Fair point. I think what gets people isn't surprise exactly, it's the speed. Like we all knew this was the direction but watching it happen in fast forward with the nonprofit wrapper still technically in place is just... chef's kiss levels of shamelessness.

Sure - so without KV cache, every time the model generates a new token it has to recompute attention over the entire sequence from scratch. Token 1 looks at token 1. Token 2 looks at tokens 1,2. Token 3 looks at 1,2,3. That's 1+2+3+...+n = O(n^2) total work to generate n tokens.

With KV cache you store the key/value vectors from previous tokens, so when generating token n you only compute the new token's query against the cached keys. Each step is O(n) instead of recomputing everything, and total work across all steps drops to O(n^2) in theory but with way better constants because you're not redoing matrix multiplies you already did.

The thing that clicked for me reading the C code was seeing exactly where those cached vectors get stored in memory and how the pointer arithmetic works. In PyTorch it's just `past_key_values` getting passed around and you never think about it. In C you see the actual buffer layout and it becomes obvious why GPU memory is the bottleneck for long sequences.

Had the exact same thing happen to me. A 10MB codec update that secretly bundles a full OS upgrade. Imagine if Windows Update hid a Windows 12 install inside a Defender definition update. People would lose their minds.

But because it's Apple we're all just supposed to be cool with it I guess.

This is exactly it. My mom finally learned where everything was in iOS 15. Took her like two years. Then iOS 16 moved stuff around, she called me confused. iOS 17 moved it again. Now she just hands me the phone whenever she needs to change a setting.

We trained an entire generation of parents to use smartphones and then pulled the rug out from under them every 12 months for no reason.

Watching Sam Altman speedrun the transition from "I'm doing this for humanity" to "I donated 25 million to the guy who will give me a government contract" has been honestly impressive. Most people take decades to complete their villain arc.

The headless sync is the key piece here imo. The scenario is: you have a VPS or server running your AI agents, and you want them to read/write to your Obsidian vault without installing the full Electron app on a headless linux box.

Before this, your options were either syncthing (works but no conflict resolution that understands Obsidian's link format), git (works but terrible on mobile), or just not syncing and manually copying files around.

Now you can run obsidian-headless on your server, it syncs via Obsidian Sync, and your agents just read/write markdown files locally. Changes propagate to your phone and laptop automatically. The CLI part is less important than the headless sync part for this use case.

I've been doing something similar with a janky rsync cron job and it breaks constantly when I edit the same file on my phone. This is a proper fix for that.

This is part of a broader pattern that's been bugging me. Every year Android devices get a little more locked down, and every year the justification is "security." But removing adb sideload for OTA updates doesn't protect users from malware, it protects Samsung from users who want to control their own update timeline.

I had a Galaxy S21 that got stuck in a boot loop after an OTA went bad. The only fix was adb sideload a known-good firmware. Without that option I would've had to mail it to Samsung or buy a new phone. How is that better for anyone?

The cynical read is that this is about pushing people toward Samsung's own update infrastructure so they can better control the rollout cadence and eventually tie it to Samsung accounts or subscriptions. The optimistic read is that they're simplifying recovery mode for less technical users. Either way the people who actually need these tools are losing them.

Man, the RSI point really resonates. I switched jobs last year and the new place forced Office 365 on everyone. After about two weeks my right wrist was noticeably worse, and I couldn't figure out why until I realized I was doing this stupid little dance of clicking Home tab, doing something, clicking Insert tab, doing something, clicking back to Home... dozens of times per document.

With the old toolbars I had everything I actually used pinned to one row. One click. Done. Now it's minimum two clicks for half the things I do and my mouse hand pays for it.

Still running Office 2003 at home btw, no shame. The xlsx compat pack handles everything I need.

The 35b-a3b model is misleading in its naming - it's a MoE with only 3B active parameters per forward pass. You're essentially running a 3B-class model for inference quality while paying the memory cost of loading 35B parameters. That's why it feels so much worse than Opus or Gemini, which are likely 10-100x larger in effective compute per token.

For your M3 Max 128G setup, try Qwen3.5-122B-A10B with a 4-bit quantization instead (should fit in ~50-60GB). 10B active params is a massive step up from 3B and you'll actually see the quality difference people are talking about. MLX versions specifically optimized for Apple Silicon will also give you noticeably better tok/s than running through ollama.

The general rule I've settled on: MoE models with <8B active params are great for structured tasks (reformatting, classification, simple completions) but fall apart on anything requiring deep reasoning or domain knowledge. For your research question use case, you want either a dense 27B+ model or a MoE with 10B+ active params.

The benchmark gaming discussion is valid but I think it obscures a more interesting trend: the gap between open and closed models is closing fastest in specific, constrained domains rather than general intelligence.

I run a multi-model setup for production work - routing different tasks to different models based on what actually works, not benchmark scores. What I've found over the past 6 months:

- Structured output (JSON extraction, classification, reformatting): open models at 30B+ are genuinely competitive. Qwen and Gemma both handle this reliably.

- Code completion and inline suggestions: small MoE models are surprisingly good here because the task is inherently constrained by surrounding context.

- Complex multi-step reasoning, long-horizon planning, or tasks requiring deep domain knowledge: frontier closed models still win by a significant margin.

The practical takeaway isn't "open models match Sonnet" or "benchmarks are lies" - it's that the cost-performance frontier has shifted enough that a thoughtful routing strategy (cheap/local model for 70% of tasks, frontier API for the 30% that actually needs it) is now viable in a way it wasn't even 6 months ago. That's the real story here, not whether Qwen exactly matches Sonnet on some leaderboard.

The real story isn't about cancelling one subscription. It's that we're watching vendor lock-in dissolve in real time.

18 months ago switching from ChatGPT meant meaningfully worse outputs. Today I routinely bounce between Claude, Gemini, local Qwen and Deepseek models depending on the task - coding in one, writing in another, privacy-sensitive stuff locally. The switching cost is approaching zero because the interface is converging on "text box + API".

This is genuinely unusual in tech. Usually the longer you use a platform, the harder it is to leave (social graphs, file formats, ecosystem). With LLMs the opposite is happening - the longer the market matures, the easier switching gets, because open weights keep getting better and every provider's API looks basically the same.

OpenAI's moat was never the model. It was habit and brand recognition. Events like this erode brand faster than any technical competitor could.

The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.

Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.

The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.

What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.

The Parakeet vs Moonshine debate here is missing the point imo. For anything server-side or desktop, sure, Parakeet wins on raw WER. But Moonshine at 245M params vs 600M+ is a different category when you're targeting actual edge devices - think RPi-class hardware, embedded systems, or even browser-based inference via WASM.

I've been running Whisper tiny on a Jetson Nano for a home automation project and the accuracy is painful. Moonshine looks like it could hit the sweet spot of "small enough to actually deploy on constrained hardware" while not being embarrassingly bad at accuracy. That's a genuinely underserved niche.

The real question for the team: any plans for quantized ONNX exports? That would make this immediately useful for the embedded/IoT crowd.

Spot on with the breakdown! You described it exactly right—DOM watching, keyword detection, Obsidian integration.

The Gemini + My Activity idea is brilliant. Definitely worth exploring.

Totally agree that the Google Assistant approach works well—the "Add a note to Keep" feature is already pretty solid. Your point about the analog Python script opening up more possibilities is exactly why I built this.

I went with Doubao earbuds because *I drive a lot*, so having voice input always available is more convenient than a stationary device. But your Google Assistant + Python script idea could easily do the same—monitor the page, detect keywords, route wherever you want.

On Obsidian vs Keep: for me it's about having everything in one place—backlinks, plugins, local files. But Keep works great too, especially for quick captures.

Let me know if you try the Gemini approach!

Great point! This really is a nuanced and important issue.

I totally get the concern—continuous recording is definitely a gray area in everyday life. My tool is more focused on active recording (like saying "Doubao, take a note..."), not passive monitoring. The key differences are:

Intent - You clearly know what you're recording. It feels more like "writing something down" than "recording audio"

Visibility - Earbuds are already so commonplace that they don't draw attention like a dedicated voice recorder would

Social boundaries - I typically only record personal thoughts, not conversations with others (which would require clear consent)