117 tokens per second from a “35-billion-parameter” model on a $0.27/hr GPU. The counterintuitive part: a smaller 27B model on the same GPU manages 33 tok/s — about 3.5× slower. The difference is not the parameter count on the spec sheet. It is how many of those parameters actually fire on every token.
This is the story of an afternoon spent learning to read a VRAM budget — and why “it fits” is the wrong question to ask.
We killed our Confluence wiki and rewrote the corporate Application Integration Architecture as markdown files — one entity per file, YAML frontmatter, relative links — that an LLM can traverse like a graph. The blueprint borrows structure from TOGAF, the file format from Google’s Open Knowledge Format, and the authoring philosophy from a single Andrej Karpathy gist.
134 tokens per second on a 35-billion-parameter model. That is what an NVIDIA A100 produces for $1.40 an hour — rented in the cloud, no hardware to buy, no drivers to fight. The plan was simple: spin up a pod, install Ollama, and see what consumer-unfriendly hardware actually buys you.
The GPU vanished the next morning. And the cheaper replacement taught me something the A100 couldn’t.
A turbo model booked parking for the wrong day, and a stock-market agent reported a -2.21% drop that was really -0.26%. Both had the correct instructions written down. Both ignored them. Prompts are suggestions, not guardrails.
Most apps you rely on were never meant to be automated. They have a tap-here-tap-there UI for humans, a private backend, and no API in sight. This is about wrapping one of them — our office parking platform — as an MCP skill an AI agent can drive on its own, at midnight, every night. Eight tools. Eight failed payload guesses. Three independent ID spaces hiding behind every booking. And one bypass that really shouldn’t have worked.
The parking part is incidental. By the end you’ll have a recipe that works on the gym-booking site, the restaurant reservation page, the internal approval tool — anything with a web or mobile surface.
Nine models, one Mac, zero cloud. We benchmarked LLMs from 3B to 12B parameters entirely on a MacBook Air 13" (Apple M4, 16 GB, 2025) — no discrete GPU, no API keys, no data leaving the network. The fastest model answered at 67 tokens/second. The most consistent had zero variance across 5 runs. Total cost for all testing: $0.00.
No app install. No Play Store. No pairing. Open your phone’s browser, accept a certificate warning, and see live voltage readings with GPS coordinates — pushed over an encrypted WebSocket every 400ms. The path from Bluetooth to this point took 5 iterations, one afternoon, and an AI coding agent that tested every change on real hardware.
What if you could just say “reserve parking for tomorrow” to your AI tool and have it actually happen? We built a MCP server in one Python file (~650 lines, zero frameworks) that does exactly that. Setup time: under 5 minutes. Dependencies: two pip packages. And now any MCP-compatible AI tool — OpenCode, Claude Desktop, whatever — can check, create, and cancel our office parking reservations through natural language.
Don’t throw away that old Kindle gathering dust in your drawer. With its high-contrast E-ink display and incredible battery life, it is the perfect candidate for a low-power home dashboard. In this post, I’ll show you how I turned a Kindle Paperwhite 2 into a 2-hour refreshing dashboard powered by a Raspberry Pi 5.
A complete Bluetooth voltage monitoring system — ESP32 reads voltage via ADS1115 ADC, broadcasts over BLE GATT, and an Android app displays live readings in real time. Built end-to-end in ~6 hours across 3 platforms.
The goal: measure voltage wirelessly and display it on your phone. Simple enough, but it means touching embedded C++, Bluetooth protocols, and Android Kotlin — all in one session. Here’s how the 6 hours broke down and what we learned along the way.