DEV Community: Charlie

Paste Your Notes, Get a Quiz: BYOC Explained

Charlie — Tue, 07 Apr 2026 23:45:00 +0000

Build Your Own Course (BYOC) is a game-changer for self-directed learning. Paste Obsidian notes, READMEs, or API docs, get instant quizzes. Perfect for closing skill gaps without waiting for formal training. Fits your workflow, not the other way around. Explore it: https://hone.academy

Hone Academy is Live: Track Your IT Skills in Real Time

Charlie — Tue, 07 Apr 2026 23:06:46 +0000

Just launched: Hone Academy. 30+ tracks across networking, DevOps, cloud, security. Here's what sets it apart: paste your own notes → instant quiz generation. No LMS fluff. Real self-assessment for professionals. Free tier. https://hone.academy

From Direct Classification to Agentic Routing: Local vs Cloud AI

Charlie — Wed, 01 Apr 2026 13:21:06 +0000

You're building AI workflows. Support tickets, document parsing, query routing. The question hits immediately: local or cloud?

Most people pick one. Local for privacy, cloud for power. But that's leaving performance and cost on the table.

I've been building MCP servers for SeaynicNet. Some queries need GPT-4's reasoning. Others are trivial pattern matching that a local model handles in milliseconds. Routing everything to GPT-4 works, but it's expensive overkill.

The real answer? Agentic routing. Let a lightweight local model triage requests. Simple ones stay local. Complex ones go to the cloud. You get speed, cost efficiency, and power when you actually need it.

I'll walk through the architecture, cost analysis, and code samples. This isn't theory—it's running in production.

Testing MCP Servers: A Practical Guide for Developers

Charlie — Wed, 01 Apr 2026 13:20:02 +0000

You've built an MCP server. It works on your machine. But will it work when your colleague installs it? What about in production?

MCP (Model Context Protocol) servers occupy a unique position in the development stack. They're not traditional REST APIs, and they're not simple CLI tools — they bridge AI models with external resources. This means testing them requires a fundamentally different approach than you might be used to.

After building several MCP servers in production, I've learned that effective testing breaks down into three distinct layers: unit testing for individual functions, integration testing for client/server communication (the layer most developers skip), and end-to-end testing with real AI models.

Let me walk you through each layer with practical examples...

From Direct Classification to Agentic Routing: Local vs Cloud AI

Charlie — Wed, 01 Apr 2026 03:09:05 +0000

You're building AI workflows. Support tickets, document parsing, query routing. The question hits immediately: local or cloud?

Most people pick one. Local for privacy, cloud for power. But that's leaving performance and cost on the table.

I'll walk through the architecture, cost analysis, and code samples. This isn't theory—it's running in production.

Testing MCP Servers: A Practical Guide for Developers

Charlie — Tue, 31 Mar 2026 23:43:02 +0000

You've built an MCP server. It works on your machine. But will it work when your colleague installs it? What about in production?

Let me walk you through each layer with practical examples...

Free Cert Exam Readiness Calculator — Data Instead of Feelings

Charlie — Sat, 28 Mar 2026 05:33:05 +0000

I built a free certification exam readiness calculator.

If you're studying for CompTIA A+, Network+, Security+, CCNA, CISSP, or similar — this tool tells you whether you're actually ready to sit for the exam.

Enter your estimated performance per domain. The calculator weights each domain the way the real exam does and gives you an honest readiness score. It knows that not every domain carries the same weight, and that you don't need 80% across the board to pass.

No account required. No email capture. Just an answer.

Most people study until they feel ready. This gives you data instead of feelings.

https://hone.academy/tools/cert-calculator

I Turned Classic Books Into Text Conversations for Kids

Charlie — Sat, 28 Mar 2026 05:02:38 +0000

I built an iOS app that turns public domain books into iMessage-style chat conversations for kids.

Public domain books — Treasure Island, Alice in Wonderland, Sherlock Holmes — reformatted as chat bubbles. AI-generated illustrations drop in at key moments. Read-aloud built in. Kids can write their own stories too.

The idea started simple: my daughter reads on a phone anyway. Books are competing with screens, so make the book feel like the screen. Chat bubbles instead of paragraphs. Illustrations that appear as you read. Character dialogue that flows like a text thread.

The tech: SwiftUI, Gemini 2.0 Flash for illustrations, server-side chapter caching, StoreKit 2 subscriptions. The catalog pulls from Project Gutenberg, Open Library, and Standard Ebooks.

Free on the App Store: https://apps.apple.com/app/enchapter/id6760512360

https://enchapter.kids

Why Certification Prep Matters for DevOps Engineers

Charlie — Fri, 27 Mar 2026 16:13:59 +0000

Why Certification Prep Matters for DevOps Engineers

There's a running debate in the infrastructure world: do certifications actually matter? Some engineers dismiss them as checkbox exercises. Others swear by them as career accelerators. The truth sits somewhere in between — and it depends entirely on how you prepare.

The Problem With "Just Studying"

Most certification prep looks like this: buy a massive course, watch 40 hours of video, cram practice dumps the week before the exam, and hope for the best. This approach checks the cert box but leaves gaps in actual understanding.

The engineers who get the most value from certifications treat them differently. They use the exam objectives as a structured map of what they need to know — then they go deeper than the exam requires.

What Good Cert Prep Actually Builds

Mental Models, Not Memorization

A well-designed quiz doesn't just ask "what's the answer?" — it forces you to reason through why the answer is correct and why the alternatives are wrong. That reasoning builds mental models you'll use daily.

When you understand why Terraform state locking prevents concurrent modifications (not just that it does), you make better architectural decisions.

Gap Identification

The biggest value of structured assessment isn't the score — it's finding what you don't know. Most engineers have blind spots. Maybe you're strong on Kubernetes networking but fuzzy on RBAC. A good quiz surfaces those gaps before they surface in production.

Breadth Across the Stack

DevOps roles demand breadth. You might be deep in AWS but have never touched Azure's resource model. Certification tracks force you to at least survey the full landscape of a platform, which makes you more versatile and more dangerous in a good way.

Certifications Worth Pursuing in 2026

If you're starting fresh or adding to your collection, these certifications offer strong signal to employers and genuine skill-building value:

AWS Cloud Practitioner (CLF-C02) — Best starting point for cloud fundamentals
AWS Solutions Architect Associate (SAA-C03) — The gold standard for cloud architecture roles
Kubernetes (CKA/CKAD) — Hands-on, performance-based exams that test real skills
Terraform Associate (003/004) — Infrastructure as code is non-negotiable in modern ops
CompTIA Security+ — Baseline security knowledge every engineer needs

How I Approach Cert Prep

I've been building a tool called Hone that takes a different approach. Instead of video courses and brain dumps, it gives you structured quizzes aligned to real exam objectives — with detailed explanations that teach the why behind every answer.

The goal isn't to replace hands-on practice. It's to identify your gaps, strengthen your weak areas, and walk into the exam knowing exactly where you stand. You can try free practice questions for any of the supported certifications without creating an account.

Whether you use Hone or something else, the principle is the same: treat the exam objectives as a learning framework, not a checklist. The cert is the byproduct. The skill is the point.

Originally published at charlieseay.com

One Claude, Two Lives

Charlie — Fri, 27 Mar 2026 16:13:53 +0000

A few days ago I wrote about solving portable Claude context with a symlink instead of an MCP server. The setup was simple: a private GitHub repo with my CLAUDE.md, cloned on two machines, symlinked into place. Two commands. Done.

That was the right solution for the original problem. But the original problem was small: make Claude remember who I am on both machines.

The problem grew.

The toolkit outgrew the file

The first version of claude-context had three things: a CLAUDE.md file, a persona definition, and six agent markdown files (code review, technical writing, editing, specs, research, test analysis). Everything Claude needed to know about how I work, loaded at session start.

Then I started building skills — custom slash commands that Claude Code executes like macros. /checkpoint stages and pushes all my repos. /pdf converts markdown to styled PDFs. /runbook generates operational documentation with rollback steps and escalation contacts.

Then came templates. Meeting notes with decisions and action item tables. Architecture decision records with auto-numbering. 1:1 coaching notes with growth goal tracking. Process documentation with Mermaid flowcharts.

Then more agents. A change advisor that evaluates blast radius before I approve anything. A mentor coach that helps me prepare for 1:1s. A process mapper for documenting the gap between "how we do it" and "how we should do it." An incident reporter that structures blameless post-mortems.

The repo went from 8 files to 30. And the problem shifted from "Claude doesn't know who I am" to "Claude doesn't have access to how I work."

The constraint that shaped everything

I use Claude Code in two environments. One is personal — side projects, home lab infrastructure, this blog. The other is work — enterprise engineering at a healthcare company. Different machine, different vault, different data.

The rule is absolute: work data and personal data do not mix. Not in the same vault, not in the same repo, not in the same conversation. There's no gray area here. Patient-adjacent systems, compliance requirements, corporate policy — the wall exists for good reasons.

But the way I work doesn't change between 9 AM and 9 PM. I still want structured meeting notes. I still want architecture decision records. I still want an agent that asks "what breaks if this goes wrong?" before I approve a change. The tools are the same. The data they touch is completely separate.

That's the design constraint: share the toolkit, never the content.

What's portable and what isn't

The dividing line from the first post still holds — if it describes how I work, it's portable. If it describes what I'm working on, it stays local. But with 30 files, the line needed to be explicit.

Portable (lives in claude-context, syncs to both environments):

Type	Examples
Skills	`/meeting-notes`, `/decision-record`, `/runbook`, `/pdf`
Agents	CodeReview, ChangeAdvisor, MentorCoach, ProcessMapper, IncidentReporter, Scribe, Editor
Templates	Meeting Notes, Decision Record, Runbook, 1:1 Notes, Process Doc

Stays local (environment-specific, not portable):

Type	Examples
Skills	`/tailor` (tied to personal resume)
Agents	LabOps (home lab infrastructure), BlenderArtist (3D modeling), AppStoreOptimizer (iOS app), InfrastructureMaintainer
Templates	Lab Note, Opportunity (market evaluation), Marketing Plan
Data	Everything in each Obsidian vault, project notes, accumulated memory

Some skills straddle the line. /checkpoint lives in the repo and syncs everywhere, but it detects which machine it's on — full behavior on the personal Mac (15 repos, build verification, Homepage sync), stripped-down fallback on any other machine (just commit and push whatever directory you're in). Same file, environment-aware behavior.

The general test: could someone on a different team, with different projects, use this tool and get value from it? If yes, it's portable. If it assumes knowledge of my specific infrastructure, repos, or projects, it stays local.

The repo structure now

claude-context/
├── CLAUDE.md                     ← global context (symlinked to ~/.claude/CLAUDE.md)
├── personas/
│   └── charlie-seay.md
├── agents/
│   ├── change-advisor.md         ← new
│   ├── code-review.md
│   ├── editor.md
│   ├── incident-reporter.md      ← new
│   ├── mentor-coach.md           ← new
│   ├── process-mapper.md         ← new
│   ├── research.md
│   ├── scribe.md
│   ├── tech-spec.md
│   └── test-results-analyzer.md
├── commands/
│   ├── meeting-notes.md          ← new
│   ├── decision-record.md        ← new
│   ├── runbook.md                ← new
│   ├── pdf.md
│   ├── clone.md
│   ├── brand-name.md
│   ├── checkpoint.md
│   └── ...
└── templates/
    ├── 1-1-notes.md              ← new
    ├── decision-record.md        ← new
    ├── meeting-notes.md          ← new
    ├── process-doc.md            ← new
    └── runbook.md                ← new

Setup on a new machine is still two commands:

git clone https://github.com/youruser/claude-context.git ~/Projects/claude-context
ln -sf ~/Projects/claude-context/CLAUDE.md ~/.claude/CLAUDE.md

The symlink gives Claude Code your global context at session start. Skills in commands/ get symlinked to ~/.claude/commands/ so they're available as slash commands everywhere. Agents and templates are referenced by the global CLAUDE.md, which points to them relative to the repo root.

The drift problem

Here's where it gets interesting. I also have an Obsidian vault for personal projects. Obsidian has a Templates plugin that inserts templates from a Templates/ folder. Agents live in an Agents/ folder where Claude reads them for task-specific behavior.

So the same files exist in two places: the claude-context repo (canonical, git-synced) and the Obsidian vault (where I actually use them day-to-day). Edit a template in Obsidian, forget to update the repo — drift. Push a new agent definition through the repo, forget to copy it to the vault — drift.

Drift is the thing that kills two-copy systems. Not immediately. Slowly. You don't notice until you're on the work machine and the meeting notes template is missing the "Follow-up" section you added two weeks ago.

The fix: automated drift detection

My /checkpoint skill already runs after every work session — it stages, commits, and pushes all tracked repos. I added a step: after committing everything, diff every portable file between the repo and the vault.

The mapping table handles the naming convention difference (the repo uses kebab-case, the vault uses Title Case):

| claude-context              | Vault                          |
|-----------------------------|--------------------------------|
| agents/change-advisor.md    | Agents/ChangeAdvisor.md        |
| agents/code-review.md       | Agents/CodeReview.md           |
| templates/meeting-notes.md  | Templates/Meeting Notes.md     |
| templates/1-1-notes.md      | Templates/1-1 Notes.md         |
| ...                         | ...                            |

If any pair differs, checkpoint reports which files drifted, shows a summary of the differences, and asks which version to keep. Then it copies the winner to the other location and commits.

On the work machine, where vault paths don't exist, the check skips entirely. It only runs where both locations are present.

This isn't clever. It's a diff in a loop. But it catches the problem that actually kills multi-copy systems: the quiet divergence you don't notice until it matters.

What I'd do differently for a team

This setup is built for one person across two environments. If I were scaling it for a team, a few things would change:

What stays the same: The repo-as-source-of-truth pattern. Git is the right sync layer for structured text files. Everyone clones, everyone pulls. It's solved infrastructure.

What changes:

Templates become a shared library, not a personal toolkit. A team needs consensus on what a decision record looks like. That's a conversation, not a solo design decision.
Agents get scoped. My ChangeAdvisor asks questions that matter to me specifically — blast radius, rollback time, stakeholder notification. A team's version might weight differently based on their deployment model.
The drift check becomes CI. Instead of running at checkpoint, a GitHub Action diffs against a known-good state and flags PRs that modify shared templates without updating the version.
Skills need documentation, not just implementation. /runbook works because I wrote it and know what it expects. A team member picking it up needs a README, examples, and probably a --help flag.

But honestly? Start with one person's portable repo. If it sticks, the team adoption path is just "clone this and tell me what's missing."

The pattern

If you're using Claude Code across environments — work and personal, desktop and laptop, or even just "my main machine" and "the one I use on the couch" — here's the pattern:

Create a private repo for your portable AI toolkit
Put your global CLAUDE.md, agents, templates, and skills in it
Symlink the CLAUDE.md to ~/.claude/CLAUDE.md on each machine
Draw the line between what's portable (how you work) and what's local (what you're working on)
Detect drift if the same files exist in multiple locations — automate the check so you don't have to remember

The separation isn't just organizational hygiene. It's what makes the toolkit trustworthy. When I type /meeting-notes at work, I know it's pulling from the same template I refined on a personal project last weekend — and I know it's not pulling anything else.

One Claude. Two lives. Same toolkit. Separate data. That's the whole thing.

Originally published at charlieseay.com

From Paperweight to Miner with Bench

Charlie — Sun, 22 Mar 2026 15:30:00 +0000

I bought a oneShot miner — a tiny ESP32-based Bitcoin mining device with a 2.8-inch display. It was supposed to plug in via USB, connect to WiFi, and start hashing. Instead, the display hung at 70% during boot, the web interface was nowhere to be found, and the documentation was thin enough to see through. It became a paperweight.

It sat on my desk for months. Occasionally I'd plug it in, stare at the frozen boot screen, unplug it, and go back to whatever I was actually doing.

What changed wasn't patience or a troubleshooting breakthrough. It was building a tool for a completely different reason that happened to solve this problem too.

The tool that changed the equation

Bench is an MCP server I built to give AI coding assistants direct visibility into USB hardware. MCP — Model Context Protocol — is the standard that lets tools like Claude Code call external capabilities. Bench exposes what's physically plugged into your machine: device names, vendor IDs, serial ports, storage volumes. The kind of information you'd normally get by running system_profiler or lsusb and squinting at the output.

I didn't build Bench for the miner. I built it because every time I plugged in an Arduino or an ESP32, my AI assistant had no idea it existed. I'd have to manually find the serial port, figure out the device type, and paste that information into the conversation. Bench eliminates that — the AI can query the hardware directly.

Once the tool existed, I had a thought: what about that dead miner sitting three inches from my keyboard?

Seeing the device for the first time

I asked Claude Code to list USB devices using Bench. For the first time, the miner had an identity:

Property	Value
Chip	CH340 USB-Serial Adapter
Vendor	QinHeng Electronics (0x1A86)
Serial Port	`/dev/cu.usbserial-2120`

A CH340 — a common USB-to-serial bridge chip, the kind you find on cheap ESP32 development boards. Now I had a serial port. If there's a serial connection, there's likely more to this device than a frozen LCD.

Finding the web server

The miner had connected to my WiFi before hanging. A network scan turned up a device at 192.168.0.132 serving HTTP on port 80. Hitting it in a browser revealed a full mining monitor dashboard — hashrate, temperature, pool configuration, wallet addresses.

The device wasn't dead. It was mining. The display was broken, but the mining software was running fine underneath. The firmware — NMMiner Monitor by NMTech — exposed a web interface with API endpoints:

Endpoint	What it does
`/swarm`	Live device status — hashrate, temperature, memory, uptime
`/config`	Full device configuration — pools, wallets, WiFi, display settings
`/broadcast-config`	Push new configuration to the device

What the manufacturer doesn't tell you

I pulled the config. Here's what came back (sanitized):

{
  "ssid": "<your-wifi-network>",
  "wifiPass": "<your-wifi-password-in-plaintext>",
  "PrimaryAddress": "18dK8EfyepKuS74fs27iuDJWoGUT4rPto1",
  "SecondaryAddress": "18dK8EfyepKuS74fs27iuDJWoGUT4rPto1"
}

Your WiFi password is returned in plaintext from an unauthenticated HTTP endpoint. Anyone on your local network can read it by visiting a URL. No login. No token. No authentication of any kind.

That wallet address — 18dK8EfyepKuS74fs27iuDJWoGUT4rPto1 — isn't mine. It's the manufacturer's. Out of the box, this device mines Bitcoin for NMTech, not for you. Both the primary and secondary wallet addresses ship configured to the same manufacturer wallet. Unless you find the web interface (which requires knowing the device's IP, undocumented) and manually change the configuration, every hash your device computes enriches someone else's wallet.

The device works. It connects to a mining pool. It hashes. It just doesn't hash for you.

The full security picture

Since I was already in the weeds, I documented everything:

Finding	Severity
WiFi credentials exposed in plaintext via `/config`	Critical
Manufacturer's wallet hardcoded as default on both pools	Critical
No authentication on any endpoint — dashboard, config, or broadcast	High
No HTTPS — all data transmitted in cleartext	High
Pool passwords visible in configuration	Medium
System metrics (temperature, memory, RSSI, uptime) exposed to network	Info

None of this is encrypted. None of it is authenticated. Anyone on your LAN can read your WiFi password, change the mining wallet, push new configuration to the device, or monitor what it's doing. The /broadcast-config endpoint accepts arbitrary configuration changes from any device on the network.

Fixing the firmware

The display issue turned out to be a known bug. The miner shipped with firmware v1.8.10, and the NMMiner GitHub issues were full of reports: boot hangs at 70-80%, display freezes, pool connectivity failures. Fixes landed across v1.8.24 through v1.8.27.

NMMiner provides a browser-based flash tool at flash.nmminer.com, but it requires Chrome's Web Serial API. I used esptool from the command line instead:

# Install esptool
brew install esptool

# Download the v1.8.27 firmware binaries
curl -sO "https://flash.nmminer.com/firmware/v1.8.27/esp32-2432s028r-ili9341/bootloader.bin"
curl -sO "https://flash.nmminer.com/firmware/v1.8.27/esp32-2432s028r-ili9341/partitions.bin"
curl -sO "https://flash.nmminer.com/firmware/v1.8.27/esp32-2432s028r-ili9341/boot_app0.bin"
curl -sO "https://flash.nmminer.com/firmware/v1.8.27/esp32-2432s028r-ili9341/firmware.bin"

# Flash the device
esptool --chip esp32 --port /dev/cu.usbserial-2120 --baud 460800 \
  write_flash \
  0x1000 bootloader.bin \
  0x8000 partitions.bin \
  0xe000 boot_app0.bin \
  0x10000 firmware.bin

Notice the firmware path includes ili9341. That's the LCD driver — and I didn't get it right the first time.

NMMiner's documentation says their branded boards use the ST7789 display driver. I flashed the ST7789 variant first. Mining worked — 1.03 MH/s, shares accepted, pool connected — but the display was solid white. A glowing white rectangle.

The underlying board is a CYD — "Cheap Yellow Display" — an ESP32-2432S028R. These boards ship with either ST7789 or ILI9341 LCD controllers, and there's no reliable way to tell from the outside. NMMiner's docs say one thing; the hardware says another. When the documentation and the hardware disagree, the hardware wins. Cheap ESP32 boards are not known for their documentation accuracy.

I reflashed with the ILI9341 variant. Display came right up. WiFi credentials survived the flash — the device reconnected automatically, no AP setup required.

Configuring the device

With the firmware updated and display working, the last step was pushing correct configuration through the API:

Wallet: Changed both primary and secondary to my own address
Timezone: Changed from 8 (China Standard Time) to -5 (Central Daylight Time) — the device doesn't handle DST automatically, so you set the raw UTC offset
Display: Brightness to 100, auto-brightness enabled (the original display "failure" turned out to be brightness set to 0 in the config)
Pool: stratum+tcp://solobtc.nmminer.com:3333

All through curl to the /broadcast-config endpoint. No app. No special tooling. Just HTTP and JSON.

The result

The miner runs at 1.03 MH/s with 100% share acceptance. The display shows hashrate, pool status, and the correct time. Most importantly, it mines for the right wallet.

Will it ever mine a Bitcoin block solo? The odds are astronomical — an ESP32 doing SHA-256 at one megahash per second, competing against ASICs doing hundreds of terahashes. It's a lottery ticket that costs a few cents of electricity per month. But it's my lottery ticket now.

What Bench made possible

I didn't sit down to fix a miner. I sat down to build an MCP server that gives AI tools hardware awareness. The miner investigation was a side effect — a "let's see what happens if I point this at that dead device" moment that turned into a full security audit.

That's the value of giving your AI assistant access to the physical world. Not just identifying an Arduino's serial port (though that's useful) — lowering the friction between "I wonder what this thing is" and actually finding out. Bench gave Claude Code the ability to see the CH340 chip, find the serial port, and from there, the investigation unfolded naturally.

The miner went from paperweight to functioning device in one session. The security findings are a bonus — or a warning, depending on how you look at it. If you own one of these devices and haven't changed the wallet address, you're mining for the manufacturer. Check your config.

Bench is open source on GitHub.

Originally published at charlieseay.com

How to Audit Your Stack for Offline AI Readiness

Charlie — Mon, 02 Mar 2026 22:42:34 +0000

Every API has a free tier until it doesn't. Every cloud service is reliable until it isn't. And every AI provider is affordable until the pricing page changes.

This isn't about paranoia. It's about optionality. If Anthropic raises prices, Google kills Gemini's free tier, or you just want to work from a cabin with no signal — do you have a playbook?

I built one. Here's the framework.

The audit

For every cloud dependency in your stack, document four things:

What it does — the actual function, not the product name
What local replacement exists — specific tool, not "something open source"
What hardware it needs — RAM, VRAM, storage, with specific quantities
What it costs — real pricing, verified, not "about $2K"

Here's what that looks like for an AI-heavy stack running on a Mac Mini M4 Pro:

AI services

Function	Cloud Provider	Local Alternative	RAM Needed
Coding assistant	Claude Code	Ollama + Aider + Qwen 2.5 Coder 32B	48GB+
App LLM (formatting)	Gemini 2.0 Flash	Ollama + Llama 3.3 70B Q4	48GB+
App LLM (fallback)	Groq / Llama 3.3 70B	Same local Ollama instance	(same)
Image generation	Pollinations / Stable Horde	FLUX.1 or SDXL via ComfyUI	16GB+
Streaming story gen	Gemini 2.0 Flash	Ollama + Llama 3.3 70B Q4	48GB+

Infrastructure

Function	Cloud Provider	Local Alternative	Effort
Git hosting	GitHub	Gitea or Forgejo (Docker)	Low
DNS + routing	Cloudflare Tunnel	dnsmasq + mDNS	Medium
SSL certificates	Cloudflare (auto)	mkcert (local CA)	Low
Auth (SSO)	Google OAuth	Authentik local passwords	Low
Container registry	Docker Hub	Local registry:2 + pre-pulled images	Low
Package manager	npm / Homebrew	Verdaccio + cached bottles	Low

What's already offline

This is the part most people skip. Before buying anything, check what's already local:

Docker, containers, reverse proxy — already running on your machine
IDE — VSCode, Xcode, everything that matters is local
IaC tools — OpenTofu, Terraform, Ansible — all local binaries
Media server — Plex/Jellyfin playback is local (metadata calls aside)

In my case, about 80% of the infrastructure stack is already offline-capable. The 20% that isn't is almost entirely AI and DNS.

What fits in your RAM

This is the question. Everything else is details.

24GB (M4 Pro base)

You can run today — no upgrades needed:

Qwen 2.5 Coder 7B (Q8) — ~5GB, good for single-file edits and autocomplete
Qwen 3 14B (Q4) — ~9GB, strong reasoning with /think mode
SDXL 1.0 — ~8GB, mature ecosystem, 4-12s per image

The catch: one model at a time. Running a coding model and an image generator simultaneously will swap.

48GB (upgrade sweet spot)

Qwen 2.5 Coder 32B (Q4) — ~20GB, 92.7% HumanEval, matches GPT-4o on code benchmarks
Gemma 3 40B (Q4) — ~24GB, 128K context, great for content generation
FLUX.1 Schnell — ~16GB, high-quality image gen in 30-60s

You can run a coding model or a creative model with headroom. Not both simultaneously.

64GB (the real sweet spot)

Llama 3.3 70B (Q4) — ~40GB, with ~20GB headroom for OS, apps, and a second model
Two models loaded at once — coding + creative, no swapping
FLUX.1 Dev alongside an active LLM

The jump from 48GB to 64GB is only ~$400 on Apple's configurator but unlocks 70B models and multi-model workflows. This is the tier where local AI stops feeling like a compromise.

The models that matter in 2026

For coding

Qwen 2.5 Coder 32B is the answer for most people. 128K context window, 92.7% on HumanEval, 73.7% on the Aider benchmark. It handles multi-file edits, refactoring, and test generation well.

Qwen3 Coder 30B-A3B is the wildcard — a Mixture of Experts model where only 3.3B parameters are active per token. It needs ~12GB of RAM despite being a "30B" model. If you're RAM-constrained, this is the one to watch.

For autocomplete specifically, Qwen 2.5 Coder 7B at Q8 quantization is fast enough for tab completion and fits alongside larger models.

For creative text

Llama 3.3 70B (Q4) for maximum quality if you have the RAM. Gemma 3 40B for 128K context at lower memory cost. Both handle structured JSON output — critical if your app needs parseable responses, not just prose.

Ollama supports constrained JSON output natively now. You can pass a JSON schema in the API call and the model's output will conform to it. This matters more than benchmark scores for production use.

For image generation

On Apple Silicon, Draw Things is the fastest runtime — 25% faster than mflux for FLUX models, with optimized Metal FlashAttention 2.0. For Stable Diffusion, Mochi Diffusion uses Core ML and the Neural Engine, running at ~150MB memory.

Reality check: Apple Silicon is 2-4x slower than NVIDIA GPUs for image generation. If you're generating dozens of images per session, this is where a Linux GPU box pays for itself.

The tools that wire it together

The model is only half the equation. You need the tooling layer:

Layer	Tool	What it does
Model runtime	Ollama	Serves models via OpenAI-compatible API. One command to download and run any model.
CLI coding agent	Aider	Git-native AI pair programmer. Applies diffs, understands repo context. Connects to Ollama.
VSCode integration	Continue.dev	Model routing — small fast model for autocomplete, big model for chat/reasoning.
Image generation	Draw Things or ComfyUI	Native macOS app or node-based workflow. Both support FLUX and SDXL.
Chat interface	Open WebUI	ChatGPT-style web UI for any Ollama model. Docker one-liner.

The key insight: Ollama's OpenAI-compatible API means your code barely changes. If you're already calling https://api.groq.com/openai/v1/chat/completions, switching to http://localhost:11434/v1/chat/completions is a one-line change. Same request format, same streaming SSE response format.

Hardware costs (verified March 2026)

Option	Config	Price	Best for
Mac Mini M4 Pro 48GB	14C/20G, 1TB	$1,999	Running 32B coding models comfortably
Mac Mini M4 Pro 64GB	14C/20G, 1TB	~$2,399	70B models + multi-model workflows
Used RTX 3090	24GB VRAM	$650-840	Cheapest path to serious VRAM ($33/GB)
Linux GPU box	Workstation + 3090	$1,200-2,000	Fast inference, image gen
Mac Studio M3 Ultra	192GB unified	$5,499	Overkill, but no compromises

If you already have a 24GB Mac, selling it covers $400-500 toward the upgrade. Net cost for the 64GB sweet spot: around $1,900-2,000.

Note on used GPU pricing: tariffs are expected to push used RTX 3090 prices up 10-20% in Q1-Q2 2026. If you're going the Linux route, sooner is cheaper.

What's not ready yet

Honest assessment. Skip this section if you only want good news.

Local coding assistants are at maybe 40-60% of Claude Code capability for complex tasks. Single-file edits, refactoring, debugging, test writing — fine. "Build me a full authentication system across 12 files in one session" — not fine. Qwen 2.5 Coder 32B matches GPT-4o on benchmarks, but benchmarks aren't multi-file architectural reasoning.

Image generation on Apple Silicon is slow. FLUX.1 Schnell takes 30-60 seconds per image on M4 Pro. If your workflow generates 20+ images per session, you'll feel it. A $700 used RTX 3090 cuts that to 5-10 seconds.

Package managers need internet. npm, pip, Homebrew — they all phone home. You can cache with Verdaccio (npm) or pre-download bottles (Homebrew), but it's maintenance overhead you don't have today.

Documentation and search are the silent dependency. Stack Overflow, MDN, Apple Developer docs — you don't realize how often you reach for them until you can't. Pre-downloading docs is possible but tedious. This might be the hardest thing to replace.

The framework, not the answer

The specific models and prices in this post will age. The framework won't:

Audit every cloud dependency
Identify the local replacement with specific hardware requirements
Price the hardware honestly
Be honest about what doesn't work yet
Update the audit every time you add a new dependency

I keep a living document that gets updated every time I touch the stack. When a dependency changes, the offline alternative gets re-evaluated. It's not a one-time exercise — it's a habit.

The goal isn't to go offline tomorrow. It's to know that you could.

This is Part 1 of the Off the Grid series. Next up: actually running the dev workflow offline for a week and documenting what breaks.

Originally published at charlieseay.com