Macos

I’ve spent weeks stress-testing Apple’s on-device model — the ~3B parameter one that runs on the Neural Engine of any Apple Silicon Mac. To test it thoroughly, I built Think Local, a macOS app that exercises every capability of the model: chat, image generation, structured output, tool calling, and parameter comparison. My conclusion: As a chatbot, the model is terrible. As a structured output and tool calling engine, it’s surprisingly good. ...

You’re paying anywhere from $20 to $200 a month for access to LLMs. Claude, GPT, Gemini, whatever. And most of the calls you’re making from your scripts and dev tools boil down to something like this: “Classify this bug into one of these five categories” “Name this variable for me” “Tell me if this commit is a fix, feat, or refactor” “Summarize this block of text in two sentences” Meanwhile, your Apple Silicon Mac has a 3-billion-parameter language model baked right in, integrated with the operating system. No cost, no internet needed, no API key, no network latency. And you’re probably not using it at all. ...

Imagine you’re building an app that analyzes conversations within a development team. You want to detect whether the team’s tone is healthy or if there are signs of stress. You decide to use Apple’s NLTagger because it’s readily available, free, runs on-device, and doesn’t require a server. Three lines of code, and off you go. First surprise: the phrase “kill the process and restart the daemon” scores -0.6. Negative. Almost hostile. “Fatal error in memory allocation” gets a -0.8. And “crash report uploaded successfully” — which is literally good news — scores -0.4. ...

How many gigabytes of junk are sitting on your Mac right now without you even noticing? I’m not talking about duplicate photos from that 2019 barbecue or your Downloads folder looking like a digital landfill. I’m talking about build artifacts. node_modules from projects you haven’t touched since the pandemic. Build caches for frameworks you barely remember installing. Xcode’s derived data piling up like dust under the bed. I spent months with my drive hovering at 85% full, juggling what to delete. Then I found Mole, ran mo purge --dry-run, and the screen spat out a number: 17 GB recoverable. Three hundred and fifty forgotten build artifacts quietly rotting in the dark. ...

I have a menu bar app that needs to know a number. A percentage from 0 to 100. To get it, it calls a server every 30 seconds. Do the math: 30 seconds means 2 calls per minute, 120 per hour, 960 in an 8-hour workday. Almost a thousand HTTP requests per day to read a number that sometimes doesn’t change for 20 minutes. That’s not monitoring. That’s harassment. The real problem isn’t technical. It’s political. When you depend on an API you don’t control — that’s not public, that has no documented rate limits, that belongs to a company that can change their Terms of Service any given Tuesday — every unnecessary request is a risk. Not of timeout. Of getting cut off. ...

I’m building Tokamak, a menu bar app for macOS that monitors your Claude Max quota. A couple of weeks ago, Anthropic published this in their Terms of Service: “You may not use OAuth or similar authorization mechanisms to allow third-party applications to access Claude on behalf of users.” And there I was, reading Claude Max quota using browser cookies to call an undocumented endpoint, staring at the screen thinking: “What now?” ...

It’s 2 AM. Your app compiles. You sign it. You package it in a DMG. You run notarytool submit. Apple says “In Progress”. You wait 5 minutes. 10. 20. An hour. Two hours. The submission is still “In Progress”. You go to bed. The next morning: Invalid. With no more explanation than “The signature of the binary is invalid”. For both architectures. Thanks, Apple. Very helpful. Notarization is one of those processes that works perfectly… until it doesn’t. And when it fails, it leaves you with a .dmg that Gatekeeper won’t let open and an error that tells you nothing. After fighting with this for a couple of days with Tokamak (my menu bar app for monitoring Claude quota), I decided to document everything I learned and write a linter so I never have to go through this again. ...

I’m building a menu bar app for macOS. It works perfectly on my Mac. Now I need to know if it works on a clean macOS: without my settings, without my permissions, without my data. A user installing it from scratch. How do you test that? You need a virtual machine. “Easy,” I thought. “I have UTM installed. I’ll open the wizard, create a macOS VM, and we’re good to go.” ...

Kimi K2 will have to wait Yesterday I wanted to download the latest Moonshot model, Kimi K2 Instruct. A pretty promising model that I’d been wanting to test for days. I went to make some space, checked the disk, and found this: Disk: 927GB Used: 644GB Free: 283GB Hmm. 283GB free isn’t bad, but what the hell is taking up 644GB? I keep my Mac pretty clean, don’t store movies locally, and use the cloud for almost everything. ...

The Surprise of 10 GB You install Claude Desktop on your Mac. Everything seems fine; the app doesn’t take up much space. But one day, you check your disk and find this: ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB. Yes: one single file called claudevm.bundle, tucked away in Claude’s vm_bundles folder, taking up almost eleven gigabytes of your disk space. Ten gigabytes for a chatbot? What does it contain— the extended edition of The Lord of the Rings trilogy? ...