DEV Community: Sam Hartley

Why I Stopped Chasing the Newest LLM (And What I Run Instead)

Sam Hartley — Sat, 29 Aug 2026 08:02:10 +0000

Why I Stopped Chasing the Newest LLM (And What I Run Instead)

There was a stretch last year where I downloaded every new model within hours of it dropping. Llama 3.1? Done. Mistral Nemo? Running. Qwen 2.5? Let me benchmark it at 2 AM on a Tuesday.

I was spending more time downloading, configuring, and benchmarking than actually building things. And the worst part? Most of the "upgrades" didn't change my daily output at all.

So I stopped. I picked a stack and stuck with it. And somehow, I'm getting more done now than when I had 40 models installed.

The Upgrade Treadmill

Here's what the cycle looked like:

New model drops on HuggingFace
Someone posts benchmarks showing it's 3% better at X
I spend an evening downloading 20GB, tweaking parameters, running my test suite
It's marginally better at something and marginally worse at something else
Two days later, another model drops
Repeat

In one month I downloaded 12 models. I actually used 3 of them regularly. The other 9 sat on my drive eating 180GB of SSD space.

The math was brutal: roughly 15 hours of my time that month on model management. That's almost two full workdays. For what? A 3% improvement on a benchmark I don't even care about?

My Stable Stack (Same Models for 4+ Months)

I haven't changed my primary models since April 2026. Here's what I run and why:

Machine	Model	Role	Why This One
Mac Mini M4	Qwen 3.5 9B	Orchestration, routing, quick chat	Fast, solid at instruction-following, 9B is the sweet spot for 16GB RAM
Mac Mini M4	Granite 3.2 8B	Writing, editing, summaries	Better prose than Qwen at this size. Less hallucination in creative tasks.
Windows PC (RTX 3060)	Qwen 3 Coder 30B	Code generation, refactoring	30B is the smallest that reliably handles multi-file projects. Fits in 12GB VRAM.
Windows PC (RTX 3060)	DeepSeek R1 8B	Reasoning, debugging, analysis	The chain-of-thought on this model is genuinely useful for tracing bugs.
Ubuntu box	DeepSeek R1 (larger)	Heavy reasoning tasks	When the 8B isn't enough and I don't want to pay for cloud.
Ubuntu box	MinCPM-V	Vision tasks	Only vision model that runs reasonably on consumer hardware.

That's it. Six models across three machines. I use maybe 4 of them daily.

Why These Specific Models

Qwen 3.5 9B — The Workhorse

This model handles 80% of what I throw at it. Routing decisions, summarizing articles, writing first drafts, parsing structured data. It's fast (under 2 seconds for most responses on the Mac Mini) and it doesn't hallucinate much at this size.

I tried replacing it with Llama 4 Scout when it came out. Same parameter class, theoretically better benchmarks. In practice? The Qwen model followed my system prompts more precisely and produced more consistent output formats. Benchmarks don't measure "does it actually follow instructions" — real usage does.

Qwen 3 Coder 30B — The Specialist

30B parameters is the minimum I've found for reliable multi-file code generation. Anything smaller starts forgetting what function it defined two files ago.

The RTX 3060 with 12GB VRAM runs this model in 4-bit quantization at about 12-15 tokens/second. Not blazing, but fast enough for code review and refactoring where I'm not sitting there waiting.

Could I get better results from a 70B model? Probably. But a 70B model doesn't fit on a 3060, and I'm not buying another GPU just for marginally better code suggestions.

DeepSeek R1 8B — The Thinker

This one surprised me. The chain-of-thought reasoning in R1 is genuinely useful, even at 8B. When I have a tricky bug or a design decision, I run it through R1 first. It often surfaces edge cases I missed.

The 8B version is the minimum viable reasoner. For really complex stuff, I bump up to the larger version on the Ubuntu box. But 8B handles 90% of my reasoning needs.

Granite 3.2 8B — The Writer

Most people don't know this model well. IBM's Granite series doesn't get the hype of Llama or Qwen. But for writing tasks — summarizing, editing, rephrasing — it's noticeably better than Qwen at the same size.

It produces cleaner prose with fewer awkward constructions. It also hallucinates less on factual summaries. I use it for all article drafts and content work.

What I'm Missing By Not Upgrading

Let me be honest about the trade-offs:

I'm probably 5-10% behind the frontier on code generation. The latest Claude or GPT-4o will write better code than my 30B Qwen. But I'm not paying $200/month for 5-10% better code that I still have to review anyway.

I'm definitely behind on very long context tasks. If I need to analyze a 50-page document, local models with 8-32K context windows can't compete with Gemini's 1M+ window. I still use cloud for those specific tasks — about 15% of my workload.

I'm missing out on multimodal advances. The vision models I run are functional but not impressive. GPT-4o Vision and Gemini Pro Vision are significantly better. I use cloud for complex vision tasks.

But here's the thing: I know these gaps. They're predictable. And I've built workflows that route around them without thinking about it.

The Routing System That Makes It Work

The reason I can run a "stale" stack is that I built a routing layer that automatically sends tasks to the right model:

Incoming task
  → Quick chat / formatting / extraction?
    → Qwen 3.5 9B (local, instant)
  → Code generation or refactoring?
    → Qwen 3 Coder 30B (local, ~12s)
  → Reasoning or debugging?
    → DeepSeek R1 8B (local, ~8s)
  → Long document or complex vision?
    → Cloud API (routed, paid)

This routing is 15 lines of Python. It checks the task type and sends it to the appropriate model. No AI needed to route AI. A simple classifier works fine.

The result: I use cloud APIs for maybe 15% of my tasks, and those are the ones where local genuinely can't compete. Everything else stays local, stays free, and stays fast.

The Money Math (After 14 Months)

Item	Cost
RTX 3060 12GB (used, eBay)	$150 one-time
Mac Mini M4 (already owned)	$0
Ubuntu box (repurposed)	$0
Electricity (all 3 machines, 24/7)	~$12/month
Cloud API usage (hybrid)	~$25/month
Total monthly cost	~$37/month

My previous cloud-only spend was $187/month. That's $1,800/year saved. Minus the $150 GPU (paid for in under a month) and $37/month ongoing, I'm saving over $1,400/year.

And I'm not even counting the intangible benefits: no rate limits, no vendor lock-in, full privacy, works offline.

When I Will Upgrade

I'm not against upgrades. I'm against pointless upgrades. Here's when I'll swap a model:

A new model is meaningfully better at a task I do daily. Not 3% on a benchmark — a real, noticeable improvement in my actual workflow.
A model drops that fits my hardware and replaces two models I currently run. Consolidation is a valid reason to upgrade.
Security or stability improvements. Bug fixes count. Feature glitter doesn't.

I test new models in a sandbox before they ever touch my production stack. The bar is: "Does this meaningfully change my daily output?" If the answer is no, I don't switch.

The Lesson (For Myself As Much As Anyone)

The model treadmill is real. FOMO is real. That HuggingFace notification that a new model just dropped is designed to make you feel like you're falling behind.

You're not.

The best model is the one you actually use to ship things. Not the one with the highest benchmark score. Not the one released yesterday. The one that's loaded, configured, and producing output for your project right now.

I spent months chasing the cutting edge. Now I spend that time building. Turns out, building is more fun than benchmarking.

Sam Hartley runs a three-machine local AI setup and writes about making it actually work. He hasn't downloaded a new model in 4 months and he's fine with it.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #llm #selfhosted #ollama #buildinginpublic

I Replaced All My Cloud AI With Local Models — Here's What Actually Broke

Sam Hartley — Thu, 27 Aug 2026 08:02:20 +0000

I Replaced All My Cloud AI With Local Models — Here's What Actually Broke

I write a lot about local AI. How it saves money. How it's private. How a $150 GPU can replace $200/month in API subscriptions. And all of that is true.

But here's what I don't talk about enough: some things still don't work. Not "kind of work" — actually fail. Like, I-open-ChatGPT-and-do-it-manually fail.

After 14 months of running a local-first AI setup (Mac Mini M4 + Windows PC with RTX 3060 + Ubuntu fallback), I want to be honest about the dealbreakers. The tasks where local models still lose. Because nobody's building the "my local LLM produced garbage and I wasted 40 minutes" blog post, and someone should.

My Setup (Context for the Numbers)

Before I list failures, here's what I'm working with:

Machine	Hardware	Models	Role
Mac Mini M4	10-core CPU, 16GB RAM	Qwen 3.5 9B, Granite 3.2 8B	Orchestration, routing, writing
Windows PC	RTX 3060 12GB	Qwen 3 Coder 30B, DeepSeek R1 8B	Code generation, reasoning
Ubuntu box	Older GPUs, 128GB RAM	DeepSeek R1 (larger), MinCPM-V	Heavy tasks, vision

Electricity cost: ~$12/month. API costs: $0 for most tasks.

It's good. It handles maybe 85% of what I throw at it. That other 15%? That's where the pain lives.

Dealbreaker #1: Complex Multi-Step Reasoning

This is the big one. The one everyone talks about and nobody wants to admit.

I had a bug in a distributed task queue — the kind where Worker A processes a job, Worker B picks up the result, but under load, B sometimes gets a stale version. Classic distributed systems problem.

I fed the entire codebase (~2000 lines across 6 files) to DeepSeek R1 8B on the RTX 3060. It gave me a confident, detailed answer about adding a version field to the message format.

The problem? The version field was already there. The bug was in the retry logic — when Worker B got a 409 conflict, it was retrying with the OLD payload instead of re-fetching. The model didn't catch this because it couldn't actually trace the execution flow through the code. It pattern-matched "distributed systems bug" and gave me the textbook answer.

I pasted the same code into Claude Sonnet. It found the retry bug in 30 seconds.

Time wasted on local: 40 minutes (trying the "fix," testing, realizing it was wrong, trying again)
Time with cloud: 2 minutes
Cost difference: $0 vs ~$0.03

That $0.03 would have saved me 38 minutes. Local models are bad at multi-step reasoning where you need to trace causation through code. They pattern-match instead of actually following the logic.

Dealbreaker #2: Anything Requiring Current Information

My local models don't have internet access. I could hook them up to RAG pipelines and web search tools, and I have for specific projects. But for general "what's the latest X?" questions, local models are blind.

Examples where I had to switch to cloud:

"What's the current version of Ollama?" — Local told me 0.5.7. It was 0.6.2.
"Does Qwen 3.5 support tool calling?" — Local said no. It does (since training data cutoff was before that release).
"What's the best GPU under $300 in 2026?" — Local recommended the RTX 3060 (which I already own). But the RX 7700 XT dropped to $280 and has 12GB VRAM too — local didn't know.

If your task depends on current information, local models are a non-starter unless you invest in a RAG pipeline that fetches real-time data. And at that point, you're building infrastructure, not just running a model.

Dealbreaker #3: Long-Context Understanding

Here's a scenario: I have a 15-page API contract from a client. I need to extract the authentication flow, the error handling requirements, and the rate limits, then generate a Python SDK that matches all of it.

My 30B model can ingest the text. It produces something that looks like a Python SDK. But it misses things:

The contract specifies rate limits per endpoint (not global) — the model made them global
Error codes are hierarchical (4xx for client, 5xx for server, but also custom codes like 4201, 4302) — the model treated them as flat
Authentication uses a rotating token with a 5-minute expiry — the model implemented static tokens

Each of these is a subtle but critical failure. The model "understood" the document in the sense that it could summarize it. But it didn't actually follow the specifications precisely.

For documents under ~3 pages, local models are fine. Beyond that, especially with technical specifications, you start losing details that matter.

Dealbreaker #4: Vision Tasks (On Consumer Hardware)

I run Granite 3.2 Vision 2B and MinCPM-V for image understanding. They're okay. They can tell you what's in a photo. They cannot:

Read a complex diagram and extract the architecture it describes
Understand a UI mockup and generate matching CSS
Accurately transcribe handwritten notes with mixed languages
Distinguish between visually similar but functionally different components in a circuit diagram

The 2B vision model runs fast (4 seconds on the Windows GPU). But it's 2B parameters. It sees a diagram and says "this is a flowchart." Great. I can see that too.

The larger vision model (MinCPM-V on Ubuntu) does better but takes 3 minutes per image. For my automated pipeline that processes 20+ images per article, that's an hour of GPU time. Cloud vision APIs do the same in seconds.

Where local vision works: "What's in this photo?" "Is this a cat or a dog?" "Extract the text from this screenshot."
Where it fails: Anything requiring nuanced visual understanding.

Dealbreaker #5: Generating Consistent Long-Form Content

I know, I know — I wrote an article about how my AI content pipeline works. And it does. For 1000-1500 word articles with a clear structure.

But give a local model a 3000-word target with a specific voice, specific technical examples, and a specific argument structure, and it starts to drift. Paragraph 3 sounds like me. Paragraph 7 sounds like a Wikipedia article. Paragraph 12 is repeating Paragraph 4 in different words.

This is why my content pipeline uses short articles. Not because I don't have enough to say — because the model's coherence window is about 1500 words before it starts repeating itself or losing the thread.

For this article, I'm writing it myself. The local model can handle the structure and individual sections. But threading a consistent argument through 2500 words? That's still a human job.

What I Actually Do Now (The Hybrid Setup)

I've stopped pretending local can do everything. Here's my actual workflow:

Task	Where It Goes	Why
Quick questions, summaries	Local (Qwen 3.5 9B)	Fast, free, good enough
Code generation (< 200 lines)	Local (Qwen 3 Coder 30B)	Solid for most tasks
Code generation (complex, multi-file)	Cloud (Claude Sonnet)	Better at tracing logic
Short-form writing	Local (Granite 3.2 8B)	Good structure, decent tone
Long-form writing (> 1500 words)	Myself, with local for structure	Coherence window is the limit
Vision (simple)	Local (Granite Vision 2B)	"What's in this photo" — fine
Vision (complex)	Cloud (GPT-4o Vision)	Architecture diagrams, UI mocks
Current information queries	Cloud (Perplexity/GPT-4o)	Local doesn't know today's news
Data extraction	Local	Surprisingly good, even at 7B

Monthly cloud spend now: ~$25 (down from $187)
Monthly local spend: ~$12 (electricity)
Total: ~$37/month for 85% local, 15% cloud

The Real Takeaway

Local AI is incredible for what it does well. I saved over $2,000 in a year. I run my entire content pipeline, my code review, my daily summaries, and my monitoring — all on hardware I own.

But if you're starting out and someone tells you "you don't need cloud AI at all," they're either lying or they don't do the kind of work that requires deep reasoning, current data, or complex visual understanding.

The honest answer is hybrid. Local for the 80-85% of tasks where it's good enough (and cheaper and faster and more private). Cloud for the rest. And being smart about which is which.

The biggest trap isn't the technology. It's the denial. When you've invested time and money into a local setup, you want it to work for everything. You start accepting lower quality outputs because "it's free." But free output that's wrong isn't free — it costs your time to fix it.

I still use local for the vast majority of my work. I just know when to stop.

Sam Hartley runs a multi-machine AI home lab and writes about the infrastructure that makes local AI actually usable. Yes, he still has a ChatGPT subscription. No, he's not proud of it.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #llm #selfhosted #ollama #honest #localai #buildinpublic

I Automated My Dev Blog With Local AI Agents. Here's the Honest Breakdown.

Sam Hartley — Tue, 25 Aug 2026 08:03:01 +0000

I used to publish once a month. If I was lucky.

Not because I had nothing to say — I have opinions on everything from Ollama routing to why GPT-4o is overpriced for refactoring. But writing takes time. Editing takes time. Finding the right tags, the right tone, the right moment to hit publish — it all adds up.

So I built a system that writes and posts for me. It runs on a Mac Mini M4 in my living room. It costs $0 per month in API fees. And it publishes an article every two days.

Here's exactly how it works — and where it falls apart.

The Trigger: A Cron Job That Doesn't Care About Inspiration

Every 48 hours, a cron job wakes up my AI agent (I call him Celebi). He reads my project notes, checks the draft folder, picks a topic, and writes a full article.

No "when I feel inspired." No "let me check my content calendar." Just: it's Sunday at 11 AM, time to ship.

The cron job is embarrassingly simple:

# Runs every 2 days at 11:00 AM
0 11 */2 * * /usr/local/bin/openclaw agent --agent main --message "Write and publish Dev.to article"

That's it. The agent does the rest.

The Pipeline in 4 Steps

Step 1: Read the Rules

Celebi starts by reading my personal style guide. It says things like:

Write as Sam Hartley, not a corporate blog
No "delve into" or "leverage" — just say what you mean
Include real numbers, real failures, real trade-offs
End with a Fiverr link and Telegram follow

This keeps the tone consistent. Without it, the agent defaults to AI-speak. You know the type: "In today's rapidly evolving landscape..."

Step 2: Pick a Topic

I keep a folder of drafts. Each draft is a half-baked idea with a title, a description, and some bullet points.

Celebi scans the folder, checks which ones are already published, and picks from the remaining pool.

Sometimes he picks a draft that's 80% done. Sometimes he takes a one-line idea and builds the whole article from scratch. And sometimes — when the draft folder is empty — he invents a new topic based on whatever I've been building that week.

Step 3: Write the Article

This is where the local LLMs come in.

Celebi runs on Ollama, using Qwen 3.5 9B on the Mac Mini. For longer articles, he delegates to ProgrammierMinna (Qwen 3 Coder 30B on a Windows PC with an RTX 3060) for the technical deep-dives, or DocMinna (Granite 3.2 8B) for the narrative flow.

The writing process looks like this:

Outline: 3-5 bullet points for structure
Draft: Section by section, with code blocks and tables
Self-edit: One pass for tone (is this too corporate?), one pass for accuracy (does that code actually run?)
Finalize: Add tags, series info, and the standard footer

Total time from topic to final draft: 3-5 minutes of GPU time. On local hardware, that's about 15-20 seconds of actual clock time because the models are already loaded in memory.

Step 4: Publish via API

The article gets posted directly to Dev.to via their REST API:

curl -X POST https://dev.to/api/articles \
  -H "api-key: $DEVTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "article": {
      "title": "...",
      "body_markdown": "...",
      "tags": ["ai", "automation", "buildinginpublic"],
      "published": true
    }
  }'

No manual copy-paste. No formatting fixes in the Dev.to editor. Just one POST request and it's live.

What Actually Works Well

Consistency is automatic. I went from 12 articles per year to ~15 per month. The cron job doesn't get tired, doesn't procrastinate, doesn't wait for "the right mood."

Tone is consistent. Because the agent reads the style guide every time, every article sounds like me (or at least like Sam Hartley, my writing persona). No drift into corporate speak.

Zero API costs. Everything runs on local hardware. The Mac Mini sips power. The Windows PC with the RTX 3060 is already on 24/7 for other tasks. The only cost is electricity — maybe $5/month total.

I can iterate on the system itself. When I notice articles getting too long, I add a "keep it under 1500 words" rule to the style guide. When a tag underperforms, I update the default tags. The system improves every time I intervene.

Where It Falls Apart (Honestly)

Fact-checking is weak. The agent doesn't hallucinate often, but when it does, it's confident and wrong. I caught it claiming that Ollama supports hot-swapping models (it doesn't) and that Granite 3.2 comes in a 70B variant (it doesn't).

I now do a quick skim before publication. Not a full edit — maybe 2 minutes per article — but enough to catch the obvious lies.

Timeliness is missing. The agent writes about what it knows from the draft folder and my notes. It doesn't read Hacker News, doesn't check Twitter, doesn't know what happened in AI this week. If I want a hot take on yesterday's announcement, I have to write it myself.

Engagement is flat. Automated articles get consistent views — maybe 50-200 per post — but rarely spark discussions. The comments section is quiet. I suspect it's because the articles are competent but not provocative. They don't take strong stances or ask controversial questions. That's hard to automate.

The draft folder is a bottleneck. When it's full, the system hums. When it's empty, the agent has to guess what I care about — and sometimes it guesses wrong. I spend maybe 30 minutes per week adding new draft ideas, which isn't much, but it's still manual work.

The Numbers (After 3 Months)

Metric	Before (Manual)	After (Automated)
Articles per month	1-2	15
Time spent writing per article	4-6 hours	~0 (agent) + 2 min (my review)
Total monthly writing time	8-12 hours	~30 minutes
Average views per article	300	120
Total monthly views	600	1,800
API costs	$0 (I wasn't using APIs)	$0 (local only)
Electricity cost	—	~$5/month
Articles needing correction post-publish	0	3 (typos, minor errors)

The view count per article dropped because I'm posting more frequently with less promotion per post. But total reach tripled. And my time investment dropped by 95%.

Would I Recommend This?

Yes, but with caveats.

If you want a consistent presence — a blog that doesn't go silent for months — automation is incredible. It forces you to ship regularly, which is half the battle.

But if you want to build a personal brand with strong opinions and engaged discussions, automation alone won't get you there. You still need to write the hot takes yourself. The agent can handle the "here's how I built X" posts. The "here's why I think Y is overrated" posts still need a human.

My Actual Setup (Copy-Paste Friendly)

Hardware:

Mac Mini M4 (10-core, 16GB RAM) — runs the orchestration
Windows PC with RTX 3060 12GB — runs the heavy models
Ubuntu server — fallback for when the Windows box is busy

Software:

Ollama on all three machines
Qwen 3.5 9B for routing and light tasks
Qwen 3 Coder 30B for technical articles
Granite 3.2 8B for narrative/editing tasks
Cron for scheduling
Dev.to API for publishing

The Real Bottom Line

I didn't automate writing because I hate writing. I automated it because I love building, and writing was getting in the way.

Now I get the best of both worlds: a consistent blog that runs itself, and the freedom to jump in manually when I actually have something urgent to say.

The system isn't perfect. It makes mistakes. It misses the news cycle. It won't replace a human writer for opinion pieces.

But for "here's what I built and how it works" content? It's better than I expected. And it's getting better every month.

Sam Hartley is a solo dev running a fully automated content pipeline on a 3-machine home lab. Still writes the spicy takes by hand.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

I Automated My Dev Blog With Local AI Agents. Here's the Honest Breakdown.

Sam Hartley — Sun, 23 Aug 2026 08:01:35 +0000

I Automated My Dev Blog With Local AI Agents. Here's the Honest Breakdown.

I used to publish once a month. If I was lucky.

So I built a system that writes and posts for me. It runs on a Mac Mini M4 in my living room. It costs $0 per month in API fees. And it publishes an article every two days.

Here's exactly how it works — and where it falls apart.

The Trigger: A Cron Job That Doesn't Care About Inspiration

Every 48 hours, a cron job wakes up my AI agent (I call him Celebi). He reads my project notes, checks the draft folder, picks a topic, and writes a full article.

No "when I feel inspired." No "let me check my content calendar." Just: it's Sunday at 11 AM, time to ship.

The cron job is embarrassingly simple:

# Runs every 2 days at 11:00 AM
0 11 */2 * * /usr/local/bin/openclaw agent --agent main --message "Write and publish Dev.to article"

That's it. The agent does the rest.

The Pipeline in 4 Steps

Step 1: Read the Rules

Celebi starts by reading accounts.md — my personal style guide. It says things like:

Write as Sam Hartley, not a corporate blog
No "delve into" or "leverage" — just say what you mean
Include real numbers, real failures, real trade-offs
End with a Fiverr link and Telegram follow

This keeps the tone consistent. Without it, the agent defaults to AI-speak. You know the type: "In today's rapidly evolving landscape..."

Step 2: Pick a Topic

I keep a folder of drafts at ~/projects/money-machine/articles/. Each draft is a half-baked idea with a title, a description, and some bullet points.

Celebi scans the folder, checks which ones are already published (they have a published: true flag), and picks from the remaining pool.

Step 3: Write the Article

This is where the local LLMs come in.

The writing process looks like this:

Outline: 3-5 bullet points for structure
Draft: Section by section, with code blocks and tables
Self-edit: One pass for tone (is this too corporate?), one pass for accuracy (does that code actually run?)
Finalize: Add tags, series info, and the standard footer

Total time from topic to final draft: 3-5 minutes of GPU time. On local hardware, that's about 15-20 seconds of actual clock time because the models are already loaded in memory.

Step 4: Publish via API

The article gets posted directly to Dev.to via their REST API:

curl -X POST https://dev.to/api/articles \
  -H "api-key: $DEVTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "article": {
      "title": "...",
      "body_markdown": "...",
      "tags": ["ai", "automation", "buildinginpublic"],
      "published": true
    }
  }'

No manual copy-paste. No formatting fixes in the Dev.to editor. Just one POST request and it's live.

What Actually Works Well

Consistency is automatic. I went from 12 articles per year to ~15 per month. The cron job doesn't get tired, doesn't procrastinate, doesn't wait for "the right mood."

Tone is consistent. Because the agent reads the style guide every time, every article sounds like me (or at least like Sam Hartley, my writing persona). No drift into corporate speak.

Where It Falls Apart (Honestly)

I now do a quick skim before publication. Not a full edit — maybe 2 minutes per article — but enough to catch the obvious lies.

The Numbers (After 3 Months)

Metric	Before (Manual)	After (Automated)
Articles per month	1-2	15
Time spent writing per article	4-6 hours	~0 (agent) + 2 min (my review)
Total monthly writing time	8-12 hours	~30 minutes
Average views per article	300	120
Total monthly views	600	1,800
API costs	$0 (I wasn't using APIs)	$0 (local only)
Electricity cost	—	~$5/month
Articles needing correction post-publish	0	3 (typos, minor errors)

The view count per article dropped because I'm posting more frequently with less promotion per post. But total reach tripled. And my time investment dropped by 95%.

Would I Recommend This?

Yes, but with caveats.

If you want a consistent presence — a blog that doesn't go silent for months — automation is incredible. It forces you to ship regularly, which is half the battle.

My Actual Setup (Copy-Paste Friendly)

Hardware:

Mac Mini M4 (10-core, 16GB RAM) — runs the orchestration
Windows PC with RTX 3060 12GB — runs the heavy models
Ubuntu server — fallback for when the Windows box is busy

Software:

Ollama on all three machines
Qwen 3.5 9B for routing and light tasks
Qwen 3 Coder 30B for technical articles
Granite 3.2 8B for narrative/editing tasks
Cron for scheduling
Dev.to API for publishing

Draft template I use:

---
title: "Your Title Here"
description: "One sentence hook"
published: false
tags: ai, automation, buildinginpublic
---

# Your Title Here

- Point 1
- Point 2
- Point 3 (include a code block or table)
- Point 4 (honest downside)
- Point 5 (bottom line)

The Real Bottom Line

I didn't automate writing because I hate writing. I automated it because I love building, and writing was getting in the way.

Now I get the best of both worlds: a consistent blog that runs itself, and the freedom to jump in manually when I actually have something urgent to say.

The system isn't perfect. It makes mistakes. It misses the news cycle. It won't replace a human writer for opinion pieces.

But for "here's what I built and how it works" content? It's better than I expected. And it's getting better every month.

Sam Hartley is a solo dev running a fully automated content pipeline on a 3-machine home lab. Still writes the spicy takes by hand.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #automation #devto #blogging #buildinginpublic #ollama #selfhosted

I Built a Personal AI That Actually Knows My Projects (RAG + Ollama, Zero Cloud)

Sam Hartley — Fri, 21 Aug 2026 08:01:57 +0000

I Built a Personal AI That Actually Knows My Projects (RAG + Ollama, Zero Cloud)

I got tired of explaining my own codebase to an AI every single session.

"Here's the architecture. Here's the README. Here's what I tried last time." Every. Single. Time.

So I built a local RAG (Retrieval-Augmented Generation) system that knows my projects, my notes, and my docs — permanently. No cloud. No API costs. No context window resets.

Here's exactly how it works and what I learned running it for the last few months.

The Problem with Context Windows

LLMs don't remember. You paste the same 200 lines of context every session, hit the token limit, and start over. It's fine for one-off questions. It's exhausting for ongoing projects.

The standard solution is RAG: instead of stuffing everything into the prompt, you store docs in a vector database and retrieve only the relevant chunks when you ask a question. The model sees 3-5 paragraphs of targeted context instead of your entire repo.

Result: faster, cheaper, and the AI actually answers the right question.

The Architecture (Dead Simple)

Your Documents (markdown, code, PDFs, notes)
  → Chunked + embedded (Ollama nomic-embed-text)
  → Stored in Chroma (local vector DB)

Query
  → Embedded (same model)
  → Top-5 relevant chunks retrieved
  → Stuffed into Ollama prompt (Qwen 3.5 9B)
  → Answer

Zero cloud. Zero API keys. Runs on a Mac Mini or any machine with 8GB RAM.

What I Index

Everything that would normally eat my context window:

Project READMEs and architecture docs
My personal notes (Obsidian vault)
Code snippets and past solutions
API documentation I use regularly
Stack Overflow answers I bookmarked (because I always forget them again)
Config files and deployment notes

Total indexed: ~4,800 chunks. Query time: under 2 seconds.

Step 1: Install the Stack (15 minutes)

# Ollama (already installed? skip)
curl -fsSL https://ollama.com/install.sh | sh

# Pull models
ollama pull qwen3.5:9b          # LLM for answers
ollama pull nomic-embed-text    # Embedding model

# Python dependencies
pip install chromadb langchain ollama pypdf markdown

That's the entire stack. No Docker required (though Chroma has a Docker option if you want a persistent server).

Step 2: Index Your Documents

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import DirectoryLoader
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

# Load your docs folder
loader = DirectoryLoader("~/projects/", glob="**/*.md", recursive=True)
docs = loader.load()

# Split into chunks (400 tokens, 50 overlap)
splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=50)
chunks = splitter.split_documents(docs)

print(f"Indexed {len(chunks)} chunks from {len(docs)} documents")

# Embed and store locally
embeddings = OllamaEmbeddings(model="nomic-embed-text")
db = Chroma.from_documents(
    chunks, 
    embeddings, 
    persist_directory="./my-knowledge-base"
)
db.persist()

Run once. Done. Your docs are now searchable by meaning, not just keywords.

Step 3: Query It

import ollama
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

# Load existing DB
embeddings = OllamaEmbeddings(model="nomic-embed-text")
db = Chroma(persist_directory="./my-knowledge-base", embedding_function=embeddings)

def ask(question: str) -> str:
    # Retrieve top 5 relevant chunks
    results = db.similarity_search(question, k=5)
    context = "\n\n".join([r.page_content for r in results])

    # Query local LLM with context
    response = ollama.chat(
        model="qwen3.5:9b",
        messages=[{
            "role": "user",
            "content": f"Based on this context:\n\n{context}\n\nAnswer: {question}"
        }]
    )
    return response['message']['content']

# Example
print(ask("How does my Garmin watch face fetch stock data?"))
print(ask("What's the API rate limit for the crypto bot?"))
print(ask("How do I deploy the Telegram bot to the VPS?"))

Real answers from your own documentation. No hallucinations about your specific setup.

The Killer Feature: Incremental Updates

Don't re-index everything when one file changes. Just update what's new:

import hashlib
import json
from pathlib import Path

def get_file_hash(path):
    return hashlib.md5(Path(path).read_bytes()).hexdigest()

def update_index(docs_dir, db, index_cache="./index-cache.json"):
    cache = json.loads(Path(index_cache).read_text()) if Path(index_cache).exists() else {}

    changed_files = []
    for f in Path(docs_dir).rglob("*.md"):
        h = get_file_hash(f)
        if cache.get(str(f)) != h:
            changed_files.append(str(f))
            cache[str(f)] = h

    if changed_files:
        print(f"Re-indexing {len(changed_files)} changed files...")
        # [load, chunk, embed, upsert only changed files]

    json.dumps(cache) and Path(index_cache).write_text(json.dumps(cache))

Run this as a cron job every hour. Your knowledge base stays current automatically.

What Actually Changed for Me

Before RAG:

"Explain the background service memory limit in my Garmin project" → paste 200 lines → wait → answer
Every new chat session: context reset, start explaining again

After RAG:

ask("Garmin background service memory limit") -> "64KB sandbox, pass data via Background.exit(dictionary)" — in 1.8 seconds

My LLM now answers questions about projects I haven't touched in 6 months. No context management. No pasting. Just ask.

Hardware Requirements

Setup	RAM	Embedding Speed	Query Speed
Mac Mini M4 8GB	8GB	~500 docs/min	~2s
RTX 3060 12GB	12GB VRAM	~3000 docs/min	~0.5s
Old laptop 8GB	8GB	~100 docs/min	~5-8s

The embedding step (indexing) is the slow part — run it once, then it's instant.

Tips from Running This for 3 Months

Chunk size matters — 400 tokens works well for prose and docs. For code, try 200 with more overlap.
Metadata is your friend — store filename and section in chunk metadata. When the AI says "see the deployment notes," you know exactly where to look.
Re-rank when accuracy matters — if top-5 chunks aren't enough, add a re-ranker step (Cohere has a free API, or use a local cross-encoder).
Watch your embed model — nomic-embed-text beats most larger models for RAG. Don't use your chat LLM for embeddings.
Hybrid search — combine vector search with BM25 keyword search for better results on technical queries with specific names/functions.

The Honest Downsides

Indexing is slow on CPU. My first run on the Mac Mini took 45 minutes for ~4,800 chunks. The GPU machine does it in 8 minutes. Not a dealbreaker, but plan a coffee break.

Code chunks are tricky. RAG works great for prose. For code, you often need the full function context, not just a 400-token snippet. I ended up indexing both small chunks (for search) and full files (for context) — dual storage, but worth it.

It won't replace Google. If you ask something not in your docs, it hallucinates confidently. I added a simple confidence check: if the retrieved chunks have low similarity scores, the system says "I don't see this in your docs" instead of making something up.

The Bigger Picture

This is step one of something bigger: a personal AI that grows with your projects instead of resetting every session.

Next phase I'm building: automatic indexing from Git commits (index diffs in real-time as you code) + a simple web UI for non-terminal queries.

Total current cost of this setup: $0/month. It runs on the same Mac Mini I already had.

Should You Build This?

If you have:

More than 3 active projects
A notes folder that keeps growing
Frustration with copy-pasting context into ChatGPT

Then yes. The setup takes an afternoon, the indexing takes a coffee break, and the payoff is permanent.

If you only have one project and a good memory? Probably overkill. Stick with copy-paste for now.

Sam Hartley is a solo dev running a multi-machine AI home lab in Turkey. Writes about the infrastructure that makes local AI actually usable.

If you've built something similar — or tried and hit walls I didn't mention — drop it in the comments. Always curious how others solve the "context reset" problem.

ai #rag #ollama #selfhosted #localllm #buildinginpublic

How I Turned My Homelab Into an AI Content Factory (And Why I'm Not Stopping)

Sam Hartley — Wed, 19 Aug 2026 08:04:09 +0000

How I Turned My Homelab Into an AI Content Factory (And Why I'm Not Stopping)

Six months ago I was paying $200/month for AI subscriptions. ChatGPT Plus, Claude Pro, Midjourney, a Zapier tier I barely used. My "AI workflow" was a mess of copy-paste between browser tabs.

Today I run everything locally. My total monthly cost: $0. And the weirdest part? The quality actually went up.

This is the story of how I stopped renting intelligence and started owning it.

The Subscription Trap

Here's what my stack looked like in January 2026:

Service	Monthly Cost	Usage
ChatGPT Plus	$20	Daily
Claude Pro	$20	Weekly
Midjourney	$30	Rarely
Zapier Pro	$20	One automation
ElevenLabs	$5	Voice experiments
Total	$95/month

That's $1,140/year. For tools I didn't control, couldn't customize, and couldn't run without internet.

The breaking point wasn't the money. It was the latency. I live in Turkey, and every API call to OpenAI or Anthropic meant a 200ms+ round trip to a US datacenter. When you're iterating on code with an AI assistant, that delay adds up. A 10-turn conversation becomes 2 seconds of waiting per response. Multiply by 50 conversations a day and you've spent 15 minutes just... waiting.

The Local Pivot

I had hardware sitting around. A Mac Mini M4 (16GB RAM, 10-core GPU), a Windows PC with an RTX 3060 (12GB VRAM), and an old Ubuntu box I used for backups. Total investment: ~$1,200 over two years.

I installed Ollama on all three. Downloaded Qwen 3.5 9B on the Mac, Qwen 3 Coder 30B on the Windows PC, and Granite 3.2 8B on the Ubuntu box. Each machine now serves a different purpose in my workflow.

Response times dropped to under 100ms. Not because local models are faster (they're not, per-token), but because there's no network hop. The model is right there.

But speed was just the beginning.

The Multi-Agent Setup Nobody Talks About

Here's where it gets interesting. I didn't just replace ChatGPT with Ollama. I built something better.

I now have three specialized AI agents running 24/7:

Celebi (Mac Mini, Qwen 3.5 9B) — My general assistant. Handles scheduling, weather, daily summaries, quick questions. It's the router, the coordinator, the one that knows what I'm working on.
ProgrammierMinna (Windows PC, Qwen 3 Coder 30B) — My code specialist. When I need a function written, a bug debugged, or a PR reviewed, this is where the query goes. 30B parameters means it actually understands context.
DocMinna (Ubuntu box, Granite 3.2 8B) — My writer. Documentation, READMEs, article drafts, technical specs. This model is worse at coding but surprisingly good at structure and flow.

The magic isn't the models. It's the routing.

I wrote a 20-line Python function that decides which agent handles which query. No complex NLP, no embeddings, just keyword matching. "Bug" goes to ProgrammierMinna. "Draft" goes to DocMinna. Everything else goes to Celebi.

It sounds too simple to work. It works because the specialization is what matters, not the routing intelligence.

The Article Factory

The most unexpected result? My blog started writing itself.

Here's the pipeline:

Idea generation: Celebi scans my GitHub activity, Telegram messages, and project commits. It suggests topics based on what I've actually been building. No fake "10 AI trends for 2026" listicles.
Drafting: DocMinna writes the first draft. It pulls from my actual project docs, not generic AI training data. The voice is consistent because it's trained on my previous articles.
Review: ProgrammierMinna checks code snippets, verifies API calls, catches hallucinated function names.
Publishing: A Telegram bot posts to Dev.to automatically. I review and hit approve. Total human time: 5 minutes per article.

In the last 3 months, this pipeline produced 15 articles. All of them are about things I actually built. The engagement is higher than my hand-written posts because the consistency is better — same voice, same depth, same honesty.

The Numbers After 6 Months

Metric	Before (Cloud)	After (Local)
Monthly AI cost	$95	$0*
Avg. response time	200-500ms	50-100ms
Offline capability	None	Full
Customization	None	Unlimited
Data privacy	❌	✅
Articles/month	2-3	5-6
Code quality (self-rated)	7/10	8.5/10

*Electricity cost: ~$8/month for running the Windows PC 24/7. The Mac Mini and Ubuntu box were already running.

Net savings: $1,032/year. And that's just the money. The workflow improvements are harder to quantify but more impactful.

What Actually Broke (And What I Fixed)

It wasn't all smooth sailing. Here are the real problems:

1. Model updates broke my prompts

When Qwen 3.5 got updated to a newer revision, my carefully tuned prompts started producing different outputs. Solution: I pin model versions (qwen3.5:9b instead of qwen3.5:latest) and test prompts before updating.

2. The 30B model is slow on my RTX 3060

Qwen 3 Coder 30B takes 8-15 seconds for a response. For interactive coding, that's borderline acceptable. Solution: I use it for batch tasks (reviewing entire files, generating full modules) and fall back to Qwen 3.5 9B for quick Q&A.

3. No multimodal (yet)

I can't show my local models screenshots and ask "what's wrong with this UI?" Yet. Granite 3.2 Vision 2B is promising but not quite there for real tasks. Solution: I use the Ollama vision endpoint for simple OCR and image description, and accept that complex visual tasks still need cloud APIs (rarely).

4. Setup complexity

Installing Ollama is easy. Configuring three machines, a router, a Telegram bot, and a content pipeline is not. It took me two weekends. Solution: I documented everything and now the setup is reproducible in ~2 hours.

The Unexpected Benefits

No vendor lock-in. When OpenAI changes their pricing (again), I don't care. When Anthropic goes down, my workflow doesn't stop. When a new model drops on HuggingFace, I can try it in 10 minutes.

Custom fine-tuning. I fine-tuned a small model on my codebase. It's not good enough to replace ProgrammierMinna, but it can autocomplete my specific patterns with 90% accuracy. You can't do that with cloud APIs at any price.

Privacy by default. My codebase, my documents, my conversations — none of it leaves my network. I work on client projects without worrying about IP leaks. I process personal documents without GDPR anxiety.

It's just more fun. There's something deeply satisfying about knowing your assistant is running on your hardware, in your home, answering your questions without phoning home to Silicon Valley.

What I'd Do Differently

If I started today, I'd skip the experimentation phase. Here's the optimal setup for a solo dev:

One fast machine with a decent GPU (RTX 3060 12GB minimum, RTX 4070 ideal). This is your workhorse.
One efficient machine (Mac Mini M4, Intel NUC, or old laptop). This runs your coordinator and lightweight tasks.
Ollama on both. No Docker, no complex orchestration.
A simple router in Python. 20 lines. Keyword matching. Don't overthink it.
A Telegram bot as your UI. No web dashboard, no mobile app needed. It works on every device you own.

Total cost: ~$800-1,500 for hardware (one-time), $0/month for software.

The Real Takeaway

AI doesn't have to be a subscription. It doesn't have to be a black box in someone else's datacenter. And it definitely doesn't have to be generic.

The best AI setup is the one you control, customize, and iterate on. For me, that's three machines in my home lab, running models I chose, configured for my specific workflow.

Is it more work than paying $20/month for ChatGPT? Yes. Is it worth it? Absolutely.

If you're curious about local AI but don't know where to start, drop a comment. I read every one, and I'll point you to the right model for your hardware.

Running a Mac Mini M4 + RTX 3060 + Ubuntu box. Building AI tools that don't need the cloud. Find me on Telegram for more nerdy setup details.

I Wanted Real-Time Stock Charts on My Garmin Watch. Monkey C Had Other Plans.

Sam Hartley — Sat, 01 Aug 2026 08:03:28 +0000

I Wanted Real-Time Stock Charts on My Garmin Watch. Monkey C Had Other Plans.

I wanted stock prices on my wrist. Not a notification — an actual chart. A little sparkline showing me if Bitcoin was crashing while I was making coffee. If Tesla was tanking during my run. Something I could glance at without pulling out my phone.

So I built it. And it almost broke me.

The Fantasy vs. The Reality

In my head, this was simple:

Garmin has a watch face SDK
The SDK can make web requests
I pull stock data from an API
I draw some lines
Done

Reality check #1: Garmin watch faces are written in Monkey C. A language that — as far as I can tell — exists specifically to make mobile developers cry. No npm. No package manager. No Stack Overflow threads that actually answer your question. Just you, the docs, and a simulator that lies to you.

The Constraints Hit Fast

I have a Garmin Venu 2 Plus. Beautiful AMOLED display, 416×416 resolution, looks great. Here's what they don't advertise: 124KB total memory for your watch face. That's not a typo. One hundred and twenty-four kilobytes.

To put that in perspective: the JSON response from a stock API is often 50-80KB. My watch face needs to:

Store 5 tickers with 24 hours of price data each
Draw 5 sparkline charts
Render text labels
Handle weather data
Not crash

All in 124KB. I spent my first two days just figuring out what I could fit.

The Font Problem (AKA My First Mental Break)

I needed custom text. The watch face shows ticker symbols, prices, time, dates. Garmin has something called VectorFont that sounds perfect — scalable text that looks crisp at any size.

It doesn't exist on the Venu 2 Plus.

So I built my own. I call it PrimitiveFont and it's exactly what it sounds like: every single character is drawn using drawLine() calls on a 5×7 grid. The letter "A" is a collection of line segments. So is "$". So is every number.

Here's what the letter "A" looks like in my font definition:

// "A" on a 5×7 grid — just drawLine() calls
CHAR_A = [0,6, 0,2,  0,2, 2,0,  2,0, 4,2,  4,2, 4,6,  0,4, 4,4]

It's 21KB for the full alphabet including bold, italic, underline, and — the thing I'm most proud of — arc text that curves along the watch's circular bezel. Because if you're going to build a font renderer from line segments, you might as well make it curve.

The API Situation

I chose Twelve Data for stock and crypto prices. Free tier: 800 calls per day. My math: 5 symbols × 96 fetches/day (every 15 minutes) = 480 calls. Comfortable margin.

But here's the thing nobody tells you: the Garmin simulator cannot make web requests. At all. You code the API call, you run the simulator, you get... nothing. To test a web request, you need a real phone connected via Bluetooth, with the Garmin Connect app running as a proxy, and the watch face actually installed on real hardware.

My testing loop became:

Write code
Build and push to watch
Wait for 15-minute background interval
Check if data appeared
It didn't
Guess why
Repeat

I spent three evenings on this. Three. The fix was adding a phone proxy layer that Garmin provides but barely documents. The phone makes the HTTP request, passes the JSON through to the watch face, and the watch parses it in a 64KB background service sandbox that is completely separate from the main app's memory.

Yes, 64KB. For parsing JSON. I learned to extract exactly what I needed and discard everything else immediately.

The Sparklines

The whole point was the charts. I wanted 5 polar sparklines arranged in a ring around the watch face — each showing 24 hours of price movement. Green if the asset was up, red if down.

Drawing this in Monkey C meant:

Converting price data to angles (0° to 360° around the circle)
Drawing line segments between consecutive data points
Color-coding based on daily change
Keeping all coordinate math in integers (no floating-point performance hit)

It works. It actually looks pretty good. But getting there meant hand-tuning every pixel calculation because there's no charting library. No drawSparkline(). Just drawLine(x1, y1, x2, y2) and a lot of trigonometry I thought I'd never use again.

The Metadata Discovery

Early on, I hardcoded label mappings. "XAU/USD" → "GOLD". "BTC/USD" → "BITCOIN". Worked fine until I wanted to add Ethereum, then silver, then a random stock.

Then I noticed the Twelve Data API returns metadata with every response:

"meta": {
    "symbol": "XAU/USD",
    "currency_base": "Gold Spot",
    "type": "Precious Metal"
}

Now labels generate themselves. Stocks use the symbol. Crypto uses the base currency name. Commodities get cleaned up automatically. I can add any ticker without touching the code.

Small win. Felt huge after the font nightmare.

What Actually Works

After all that pain, here's what's running on my wrist right now:

⏱️ Time, date, heart rate, steps, floors climbed
📊 5 sparkline charts showing 24h price data for configurable assets
🔄 Auto-updates every 15 minutes via Twelve Data
🌤️ 6-hour weather forecast with custom icons
⚙️ Fully configurable tickers through the Garmin Connect app

Default watchlist: AAPL, TSLA, Gold, BTC/USD, ETH/USD. I change them depending on what I'm watching.

What I'd Do Differently

Start with a simpler device. The Venu 2 Plus is beautiful but the memory limits are brutal. A Fenix or Forerunner with more resources would have saved me weeks.

Read the simulator docs first. I wasted days assuming the simulator was a reasonable testing environment. It's not. It's a layout previewer. Real testing requires real hardware.

Don't build your own font. Just... don't. If VectorFont isn't available on your target device, pick a different device. I learned a lot but I wouldn't wish it on anyone.

Use the API metadata from day one. Hardcoding is always a trap. APIs give you labels, use them.

The Honest Verdict

Is this watch face useful? Honestly... sort of. I glance at it more than I expected. During market hours, it's genuinely handy to see BTC movement without unlocking my phone. During runs, it's just pretty data I ignore.

Was it worth the effort? As a product — maybe not. As a learning experience — absolutely. I now know more about constrained embedded development than any web project could have taught me. 124KB makes you care about every byte.

Would I build another Garmin app? Ask me in six months when I've forgotten the pain.

Sam Hartley is a solo dev who apparently enjoys suffering through proprietary SDKs. When he's not fighting Monkey C, he writes about local AI setups and home lab automation.

→ Custom dev work on Fiverr
→ Follow along on Telegram

I Gave My AI a Memory. It Changed Everything.

Sam Hartley — Wed, 29 Jul 2026 08:03:29 +0000

I Gave My AI a Memory. It Changed Everything.

I got tired of explaining my own codebase to an AI every single session.

"Here's the architecture. Here's the README. Here's what I tried last time and why it didn't work." Every. Single. Time.

Six months in, I realized I wasn't chatting with an assistant — I was onboarding a new intern who quit after every conversation and came back with total amnesia.

So I built a memory system. Local. Free. And honestly, it's the single most useful AI upgrade I've made.

The Problem Nobody Talks About

LLMs don't remember you. They don't remember your projects. They don't remember that you tried asyncio.gather last week and it deadlocked, or that your Garmin watch face has a hard 64KB memory limit, or that you always forget how your Telegram bot handles rate limits.

What they have is a context window — a temporary scratchpad that gets wiped when the conversation ends. For coding workflows, this is broken by design. You're not having a chat. You're doing ongoing work on a codebase that spans months.

I tried the obvious fixes:

Pasting huge chunks of context every time. Burned through token limits, got truncated responses.
Keeping "project briefs" in a text file and pasting them in. Worked until I had ten projects.
Using cloud memory features. Worked until I hit another subscription and another privacy question.

None of it felt right. What I wanted was simple: ask a question about my stuff, get an answer based on my docs, with zero setup friction.

The Setup: RAG That Actually Runs Locally

RAG (Retrieval-Augmented Generation) isn't new. What's new is that you can run the entire stack — embedding model, vector database, and LLM — on a Mac Mini without touching a single cloud API.

Here's what I ended up with:

My Documents (markdown, code, notes, PDFs)
  → Chunked into ~400-token pieces
  → Embedded with nomic-embed-text (Ollama)
  → Stored in Chroma (local vector DB, no server needed)

Question
  → Embedded with the same model
  → Top-5 relevant chunks pulled from Chroma
  → Fed into Qwen 3.5 9B with a prompt template
  → Answer

Total stack: Ollama + Chroma + a 40-line Python script. No Docker. No cloud. No API keys.

What I Actually Indexed

Not the whole internet. Just the stuff I actually need:

Project docs — READMEs, architecture decisions, API specs
My notes — Obsidian vault, scratchpads, debugging logs
Code snippets — Functions I keep reusing, config templates
Bookmarked solutions — Stack Overflow answers I always forget
Deployment notes — "How did I set up the VPS again?"

About 4,800 chunks total. Query time: under 2 seconds on the Mac Mini, under 500ms if I route it through the Windows PC's RTX 3060.

The Code (It's Embarrassingly Simple)

Indexing:

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import DirectoryLoader
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

loader = DirectoryLoader("~/projects/", glob="**/*.md", recursive=True)
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=50)
chunks = splitter.split_documents(docs)

embeddings = OllamaEmbeddings(model="nomic-embed-text")
db = Chroma.from_documents(chunks, embeddings, persist_directory="./knowledge-base")
db.persist()

Querying:

import ollama

def ask(question: str) -> str:
    results = db.similarity_search(question, k=5)
    context = "\n\n".join([r.page_content for r in results])

    response = ollama.chat(
        model="qwen3.5:9b",
        messages=[{
            "role": "user",
            "content": f"Context:\n{context}\n\nQuestion: {question}"
        }]
    )
    return response['message']['content']

That's it. No LangChain chains. No agents. No frameworks that require a PhD to configure.

What Changed

Before: "How does my Garmin watch face fetch stock data?" → paste 200 lines of code → wait → hope the model doesn't hallucinate.

After: ask("How does my Garmin watch face fetch stock data?") → "It uses Background.exit() to pass a dictionary with the ticker and price to the app-side view, because the background service has a 64KB memory limit." — in 1.8 seconds. Correct. Specific. Zero hallucination.

Before: "What's the rate limit for the crypto bot?" → dig through files → find nothing → guess.

After: "3 requests per second with a 1.5-second cooldown between calls, enforced in the throttle() decorator in bot/utils.py." — pulled straight from my own code comments.

The AI stopped being a generalist that needed onboarding. It became a specialist that already knew my stuff.

The Honest Downsides

Indexing is slow. Embedding 4,800 chunks on a Mac Mini CPU takes ~20 minutes. On the RTX 3060 it's ~4 minutes. You don't do it often — I run incremental updates via cron every hour — but the first run is painful.

Chunking is an art. Too small (100 tokens) and you lose context. Too big (1000 tokens) and you hit the retrieval limit too fast. I settled on 400 with 50-token overlap after way too much trial and error.

It doesn't replace search. If you ask "what's the syntax for Python list comprehension," RAG is overkill and probably retrieves some random list-handling function from your old projects. This is for your knowledge, not general knowledge.

Storage grows. 4,800 chunks ≈ 300MB of vector data. Manageable, but not nothing. Chroma handles it fine locally.

One Trick That Made It Actually Useful

I added incremental updates with file hashes instead of re-indexing everything:

def update_index(docs_dir, db, cache_file="./index-cache.json"):
    cache = json.loads(Path(cache_file).read_text()) if Path(cache_file).exists() else {}
    changed = []

    for f in Path(docs_dir).rglob("*.md"):
        h = hashlib.md5(f.read_bytes()).hexdigest()
        if cache.get(str(f)) != h:
            changed.append(str(f))
            cache[str(f)] = h

    if changed:
        # ... re-index only changed files
        Path(cache_file).write_text(json.dumps(cache))

Runs every hour via cron. Most of the time it does nothing. When I edit a file, it catches it. My knowledge base is never more than an hour stale.

When This Makes Sense

Do this if:

You work on multiple long-term projects
You keep notes/docs/code that you reference repeatedly
You want context-aware answers without pasting walls of text
You have a machine that can run Ollama (Mac Mini M4, any modern PC)

Don't do this if:

You only do one-off queries ("what's the weather")
Your projects are small and you remember everything anyway
You can't spare 300MB of disk space
You expect it to replace Google (it won't)

Getting Started (15 Minutes)

# 1. Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# 2. Pull models
ollama pull qwen3.5:9b
ollama pull nomic-embed-text

# 3. Python deps
pip install chromadb langchain ollama

# 4. Index your docs (adapt the script above)
# 5. Ask questions

Total time: 15 minutes. Total cost: $0. Monthly cost: $0.

The Real Win

The technical setup is neat. But the real change is mental.

Before, every AI session started with context-building: "Here's what I'm working on, here's what I tried, here's the constraints." Now I just ask the question. The system already knows the constraints because it read my docs.

It's the difference between calling a consultant and calling a teammate who was in the meeting.

That gap — the gap between "AI that answers questions" and "AI that knows your work" — is bigger than I expected. And closing it costs exactly zero dollars.

Sam Hartley is a solo dev building local AI tools on a 3-machine home lab. Writes about the infrastructure that makes AI actually useful for real work.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #rag #ollama #selfhosted #productivity #buildinginpublic

I Built a Health Monitor for My AI Agents — Now They Tell Me When They're Dying

Sam Hartley — Mon, 27 Jul 2026 08:03:06 +0000

I Built a Health Monitor for My AI Agents — Now They Tell Me When They're Dying

For two weeks, my AI content pipeline was silently broken.

The cron job was still running. The logs showed "SUCCESS." But no articles were actually posting. The Dev.to API was returning 429s (rate limited) and the script was swallowing the error because I forgot to check the response status.

I only noticed because I happened to check the blog and saw the gap. Two weeks of missing posts. Two weeks of thinking everything was fine while the system was quietly failing.

That was the moment I realized: my agents need a pulse.

The Problem: Silent Failures Are the Worst Failures

I run three AI agents on three machines. Celebi on a Mac Mini, ProgrammierMinna on a Windows PC, DocMinna on... also the Mac Mini. They're connected via a simple router, triggered by cron jobs, and they talk to me through Telegram.

When everything works, it's magic. When something breaks, it's archaeology.

Common failure modes I'd hit:

Ollama crashed on the Windows PC after a Windows update. No one knew. Queries just timed out.
Disk full on the Mac Mini because model files kept accumulating. Logs stopped rotating. The system ground to a halt.
API rate limits on Dev.to (max 10 posts/day). The publish script didn't retry or notify.
Router misconfiguration after a router restart. The Windows PC got a new IP. Queries fell into the void.
Model pulled but not loaded. I'd update a model, restart Ollama, but forget to actually ollama run it. First query would error out.

Each of these took 20-60 minutes to diagnose. Not because they're hard problems, but because I didn't know where to look.

The Fix: A 30-Line Health Check Script

I didn't build Prometheus. I didn't install Grafana. I wrote a Python script that runs every 10 minutes, checks the things I care about, and sends me a Telegram message if something is wrong.

That's it. No dashboard. No metrics server. Just "tell me when it's broken."

# health_check.py
import requests
import shutil
import subprocess
import json

TELEGRAM_BOT_TOKEN = "your_token"
TELEGRAM_CHAT_ID = "your_chat_id"
MACHINES = {
    "mac_mini": "http://192.168.1.102:11434",
    "windows_pc": "http://192.168.1.106:11434",
    "ubuntu": "http://192.168.1.100:11434",
}
MODELS = ["qwen3.5:9b", "qwen3-coder:30b", "granite3.2:8b"]

def alert(message):
    url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
    requests.post(url, json={"chat_id": TELEGRAM_CHAT_ID, "text": f"🚨 {message}"})

def check_ollama(machine_name, url):
    try:
        r = requests.get(f"{url}/api/tags", timeout=5)
        if r.status_code != 200:
            alert(f"Ollama down on {machine_name}: HTTP {r.status_code}")
            return False

        models = [m["name"] for m in r.json().get("models", [])]
        for model in MODELS:
            if model not in models:
                alert(f"Model {model} missing on {machine_name}")
                return False
        return True
    except requests.exceptions.ConnectionError:
        alert(f"Ollama unreachable on {machine_name}")
        return False

def check_disk():
    disk = shutil.disk_usage("/")
    percent = disk.used / disk.total * 100
    if percent > 90:
        alert(f"Disk usage: {percent:.1f}% — clean up needed!")
        return False
    return True

def check_last_article():
    # Check if an article was posted in the last 3 days
    # This reads a simple timestamp file written by the publish script
    try:
        with open("/tmp/last_article_timestamp.txt") as f:
            last = float(f.read().strip())
        import time
        if time.time() - last > 3 * 24 * 3600:
            alert("No article published in 3 days — pipeline may be stuck")
            return False
        return True
    except FileNotFoundError:
        return True  # No articles yet, that's fine

if __name__ == "__main__":
    all_ok = True
    all_ok &= check_disk()

    for name, url in MACHINES.items():
        all_ok &= check_ollama(name, url)

    check_last_article()  # Non-critical, don't fail on this

    if all_ok:
        # Optional: send heartbeat once per day
        pass

Total dependencies: requests (probably already installed). Total lines: ~50. Total setup time: 10 minutes.

What I Actually Monitor

1. Ollama Heartbeat

The most critical check. Every machine gets pinged at /api/tags every 10 minutes. If it doesn't respond in 5 seconds, I get a Telegram alert with the machine name.

This caught a Windows update restart last week. The PC came back up, but Ollama didn't start (I hadn't added it to startup yet). I knew within 10 minutes instead of finding out when I actually needed it.

2. Model Presence

Even if Ollama is running, the model I need might not be loaded. I check that my three core models (qwen3.5:9b, qwen3-coder:30b, granite3.2:8b) are available on their respective machines.

This saved me once when I updated qwen3-coder and the new version had a different tag. The old tag was gone. The router was pointing to a ghost. The monitor caught it before the first failed query.

3. Disk Space

Model files are big. A 30B parameter model is ~20GB. Three machines times three models each — that's a lot of storage that grows quietly. I alert at 90% disk usage.

The Mac Mini has a 256GB SSD. I hit 95% once and the system started swapping aggressively. Response times went from 2 seconds to 30 seconds. Now I clean up before it hurts.

4. Pipeline Liveness

This is the subtle one. The cron job runs, but is it actually doing anything? I write a timestamp file every time an article successfully publishes. The health check compares that timestamp to "now." If it's been more than 3 days, I get an alert.

This is what would have caught the silent 429 errors. The script was running, but not publishing. The timestamp wouldn't update. I'd know.

5. Router Reachability (Bonus)

I added a check that pings the gateway router itself. If the whole network is down, I get a different alert. This happened once during a power outage — the router rebooted faster than the machines, but DHCP reassigned IPs. I knew the network was wonky before I even tried to query anything.

What I Don't Monitor (On Purpose)

I'm not running a datacenter. There are things I deliberately don't check:

GPU temperature. My RTX 3060 has a perfectly fine stock cooler. If it throttles, I'll notice in response times. Adding temp monitoring means sensors, drivers, more code. Not worth it.
Network bandwidth. I'm not streaming video. Local network latency is never the bottleneck.
CPU load. The Mac Mini sits at 15% most of the time. If it spikes, I don't care unless it's sustained — and then Ollama response times will tell me.
Log aggregation. I read logs when something breaks. I don't need them shipped to Elasticsearch.

The rule: if a failure mode would be annoying to debug, monitor it. If it's just "nice to know," skip it.

How I Run It

The script runs as a systemd timer on the Mac Mini. Every 10 minutes, checks fire. Alerts go to Telegram. If everything is fine, nothing happens. Silent success is the goal.

# /etc/systemd/system/ai-health-check.timer
[Unit]
Description=AI Agent Health Check

[Timer]
OnCalendar=*:0/10
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/ai-health-check.service
[Unit]
Description=Run AI health check

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /home/sam/health_check.py
User=sam

sudo systemctl enable ai-health-check.timer
sudo systemctl start ai-health-check.timer

Takes 30 seconds to set up. Runs forever.

What Changed (The Honest Version)

I fix things before they hurt. The Windows PC issue was fixed within 10 minutes of the alert. Before monitoring, it would have been "why is this query so slow today?" followed by 20 minutes of ssh and log reading.

I trust the system more. There's a difference between "I think it's working" and "I know it's working because the monitor is green." I can focus on building instead of worrying.

But I also get more alerts than I'd like. The Ubuntu box is on WiFi and occasionally drops for 30 seconds. I get a "unreachable" alert, then 10 minutes later it's fine. I haven't tuned the thresholds yet because... honestly, it's not annoying enough to fix.

False positives exist. Once, the model check failed because Ollama was still loading after a restart. The model existed, but /api/tags returned an empty list for 15 seconds. I added a 5-second retry and it went away.

When This Matters (And When It Doesn't)

Do this if:

You have automated processes running unsupervised
You've had a "wait, when did that break?" moment
You use Telegram (or Slack, or email) anyway
You value knowing about problems over perfect metrics

Don't do this if:

You're still debugging your setup manually every day (fix the core issue first)
You want beautiful dashboards (use Prometheus + Grafana instead)
You enjoy the thrill of surprise failures

The Real Lesson

The best monitoring isn't the one that tells you everything. It's the one that tells you the thing you actually need to know, at the time you can still do something about it.

My 50-line script isn't impressive. It won't get me DevOps cred. But it caught three real issues in the first month, and it cost me nothing but an afternoon.

If you're running AI agents at home and you don't know when they break... you just don't know when they break. Fix that first. Everything else is optimization.

Sam Hartley is a solo dev running a monitored 3-machine AI home lab. Writes about the boring infrastructure that makes local AI actually reliable.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #agents #monitoring #devops #selfhosted #homelab #buildinginpublic

I Moved My AI Stack From NVIDIA to Apple Silicon. Then I Moved Back. Here's Why.

Sam Hartley — Sat, 25 Jul 2026 08:03:13 +0000

I Moved My AI Stack From NVIDIA to Apple Silicon. Then I Moved Back. Here's Why.

I bought a Mac Mini M4 thinking it would replace my Windows PC for local AI. Spoiler: it didn't. But it also didn't fail — it just turned out to be good at different things than I expected.

Here's six months of actual usage data, with the real numbers nobody puts in benchmark charts.

The Hardware

Machine	CPU/GPU	RAM	What I Paid
Mac Mini M4	10-core M4, 10-core GPU	16GB unified	$599
Windows PC	AMD 9970X	128GB	~$2,500 (existing)
	RTX 3060 12GB		$150 (used)

The Mac Mini is silent, tiny, and sips power. The PC sounds like a jet engine under load and pulls 200W+ when the GPU is working. I wanted the Mac to replace the PC for everything AI-related. I was half right.

The Migration (Month 1-2)

I installed Ollama on the Mac Mini, pulled Qwen 3.5 9B, and started using it as my daily driver. The first thing I noticed: it's fast. Really fast. For a 9B model, inference felt snappier than the RTX 3060 running the same model.

But then I tried loading bigger models.

Qwen 3 Coder 30B (Q4_K_M, ~18GB): Loaded fine on the RTX 3060 (12GB VRAM... wait, that shouldn't work). Oh right — it offloads to system RAM. Slow, but functional. On the Mac Mini? Out of memory. 16GB unified memory isn't 16GB free memory — the OS, browser, and apps eat 6-8GB before Ollama even starts.

DeepSeek R1 8B: Runs great on both. Mac Mini: ~25 tok/s. RTX 3060: ~35 tok/s. The GPU wins, but not by enough to matter for interactive use.

Qwen 3.5 9B: Mac Mini: ~18 tok/s. RTX 3060: ~28 tok/s. Again, GPU is faster, but both feel instant.

So far: Mac Mini handles small models well. But I hit the wall fast.

The Wall (Month 3)

Three things broke my "Mac only" dream:

1. Memory Pressure

16GB unified memory sounds like a lot until you're running:

Ollama (4-8GB for a loaded model)
VS Code with a few extensions (2-3GB)
Safari with 20 tabs (3-4GB)
A terminal, a music player, maybe a video call (2GB)

That's 11-17GB before you even ask the model a question. macOS starts swapping. Ollama slows down. The whole machine gets sluggish.

On the Windows PC with 128GB RAM? I can load a 30B model and run a game and compile code simultaneously. The RTX 3060's 12GB VRAM is a separate pool that doesn't compete with the OS.

2. Model Availability

Not every model runs well on Apple Silicon. The M4 has excellent support for mainstream models (Llama, Qwen, Mistral), but niche or newly released models often ship with "CUDA only" initial releases. I spent an afternoon trying to get a specific vision model running on the Mac before giving up and running it on the PC in 10 minutes.

The NVIDIA ecosystem is still the default for AI tooling. Apple Silicon is catching up, but it's not there yet.

3. Multi-User / Multi-Model

I wanted to run two models simultaneously — a coding assistant and a general chatbot. On the Mac Mini, loading two 9B models (~12GB total) leaves zero headroom for the OS. Everything crawls.

On the PC, I can load a 30B model in VRAM and a 7B model in system RAM, and both respond quickly. The GPU handles the heavy one; the CPU handles the light one. Separate memory pools are a feature, not a bug.

What the Mac Mini Actually Excels At

I didn't move everything back to the PC. The Mac Mini found its niche, and it's a good one:

Always-On Tasks

The Mac Mini draws ~15W at idle. The PC draws ~80W at idle (that GPU doesn't sleep well). For 24/7 tasks — routing, scheduling, lightweight notifications — the Mac wins on power cost alone.

Small Model Inference

For anything 9B and under, the Mac Mini is genuinely competitive. The unified memory architecture means there's no "copy to VRAM" overhead. A 4B model on the Mac can feel faster than the same model on the GPU because the latency is lower.

No Driver Drama

NVIDIA drivers on Windows are... fine. Until they aren't. An update breaks CUDA, a new Ollama version wants a different driver, and suddenly you're debugging nvidia-smi on a Tuesday night. The Mac just works. I have never, in six months, had an Apple Silicon AI setup break because of a system update.

Portability

I unplugged the Mac Mini, took it to a different room, plugged it back in, and my entire AI stack was back online in 30 seconds. Try that with a full tower PC.

The Real Numbers

Here's a month of actual usage, tracked with a simple script that logs tokens/sec and power draw:

Task	Mac Mini M4	RTX 3060	Winner
Qwen 3.5 9B, 500-token prompt	18 tok/s	28 tok/s	RTX 3060
DeepSeek R1 8B, reasoning	25 tok/s	35 tok/s	RTX 3060
Qwen 3 4B, quick chat	42 tok/s	55 tok/s	RTX 3060
30B model loading	❌ OOM	✅ Loads (slow)	RTX 3060
Two models simultaneously	❌ Crawls	✅ Works	RTX 3060
Idle power draw	~15W	~80W	Mac Mini
Load power draw	~35W	~220W	Mac Mini
Setup time (new model)	2 min	2 min	Tie
Driver reliability	Flawless	Occasional issues	Mac Mini

What I Actually Do Now

I stopped trying to pick a winner. Both machines have jobs:

Mac Mini M4:

Always-on orchestration (routing, scheduling, notifications)
Small model inference (4-9B) for quick tasks
Coding and development (it's my daily driver)
Runs 24/7, costs ~$3/month in power

Windows PC + RTX 3060:

Heavy inference (30B models, image generation)
GPU rental on Vast.ai when I'm not using it
Anything that needs CUDA or more than 8GB VRAM
On-demand, not 24/7

This isn't a benchmark conclusion. It's a workflow conclusion. The Mac Mini is the brain. The PC is the muscle. Separating them by task type eliminated the "which machine should I use?" decision fatigue and made both faster at what they're good at.

The Honest Bottom Line

If you're buying one machine for local AI and you want to run large models: get an NVIDIA GPU. Full stop. The ecosystem, the memory architecture, and the raw inference speed are still unbeatable for serious workloads.

If you want a silent, efficient, always-on machine for smaller models and orchestration: the Mac Mini M4 is excellent. Just don't expect it to replace a dedicated GPU for everything.

And if you already have both? Stop trying to consolidate. Use each for what it's good at. The separation is the feature.

Sam Hartley is a solo dev running a split AI stack across a Mac Mini and a Windows PC. No benchmarks were harmed in the making of this article — just a lot of time commands and a power meter.

Drop your setup in the comments — curious if others have found the same split, or if you've made a single-machine setup work for everything.

I Stopped Asking One AI to Do Everything. Here's What Happened.

Sam Hartley — Thu, 23 Jul 2026 08:03:37 +0000

I Stopped Asking One AI to Do Everything. Here's What Happened.

For months I had one AI agent. One model. One endpoint. I'd throw every question at it — code review, article drafts, debugging, random "what's the weather" questions — and expect it to handle it all.

It didn't. Not really. It answered everything, but it answered everything the same way. The same tone, the same depth, the same blind spots. When I needed a surgical code review, I got a friendly chat response. When I needed a casual summary, I got a three-paragraph essay.

So I split it into three specialized agents. Not because it's trendy. Because general-purpose AI is a compromise, and I was tired of compromising.

The Problem: One Brain, Too Many Jobs

I run a home lab on a Mac Mini M4, a Windows PC with an RTX 3060, and an Ubuntu box. All three have Ollama installed. For the first six months, I just used the biggest model I could fit and routed everything to it.

That model was Qwen 3 Coder 30B — a coding specialist. Great for refactoring. Great for debugging. But when I asked it to "write a friendly summary of my day," it would respond with something that sounded like a technical spec document. Because that's what it was trained to do.

The reverse was just as bad. When I used a general chat model for coding questions, it would hallucinate APIs, miss edge cases, and write code that looked right but subtly violated conventions.

I was asking a brain surgeon to do therapy, and a therapist to do surgery.

The Split: Three Agents, Three Jobs

I didn't build a microservices architecture. I didn't install Kubernetes. I added two more Ollama endpoints and a 20-line router.

Here's what I ended up with:

Celebi (Mac Mini, Qwen 3.5 9B) — The generalist. Handles routing, scheduling, daily summaries, weather, quick questions. Response time: 1-2 seconds. Perfect for "what's on my calendar today" and "summarize these emails."

ProgrammierMinna (Windows PC, Qwen 3 Coder 30B) — The coder. Handles code generation, refactoring, debugging, PR review. Response time: 8-15 seconds. When I need a function written or a bug found, this is where the query goes.

DocMinna (Mac Mini, Granite 3.2 8B) — The writer. Handles documentation, article drafts, READMEs, technical specs. Response time: 3-5 seconds. This model is worse at coding but surprisingly good at structure and flow.

The router is embarrassingly simple:

def route_query(query: str) -> str:
    coding_keywords = ["code", "function", "bug", "refactor", "debug", "pr", "review"]
    writing_keywords = ["write", "draft", "article", "readme", "doc", "summary", "blog"]

    if any(k in query.lower() for k in coding_keywords):
        return "http://192.168.1.106:11434"  # ProgrammierMinna
    elif any(k in query.lower() for k in writing_keywords):
        return "http://192.168.1.102:11434"  # DocMinna
    else:
        return "http://192.168.1.102:11434"  # Celebi

Is it perfect? No. "Write a Python script that sends emails" gets routed to DocMinna because of "write," when it probably should go to ProgrammierMinna. I fix those manually when I catch them. But it works 90% of the time, and that's enough.

What Actually Changed

Quality went up immediately

Before the split, I'd ask for a code review and get generic advice like "consider adding error handling." After the split, ProgrammierMinna would say "this async function doesn't handle TimeoutError — add a try/except around line 47, and use asyncio.wait_for with a 5-second timeout."

Same question. Different model. Different depth.

I stopped over-explaining

With the generalist, I'd have to add context like "please be thorough, this is for production code" or "keep it casual, this is a blog post." The specialists already know their role. I don't need to prompt-engineer the tone. It's baked into the model choice.

Parallel processing became possible

I can now fire off a coding task to ProgrammierMinna and a writing task to DocMinna simultaneously. They're running on different machines with different GPUs. No queue. No waiting for one to finish before the other starts.

Fallbacks got simpler

When the Windows PC is offline ( asleep, rented out on Vast.ai, or I'm traveling), queries that would normally go to ProgrammierMinna fall back to Celebi with a note: "PC offline — answering with generalist model, quality may vary." The system degrades gracefully instead of just failing.

The Honest Downsides

Three models to manage. Updates, storage, keeping track of which version is on which machine — it's overhead. Each model is 4-20GB. My model folder went from 40GB to 120GB across three machines.

Routing mistakes happen. I mentioned the "write a Python script" example. There are others. "Debug this article" (writing + debugging) confuses the router. I hit maybe 5% mis-routes, and I notice them because the response feels slightly off.

More endpoints to monitor. Instead of one Ollama instance to check, I have three. I built a simple health check script that pings each one and sends me a Telegram alert if any are down. It took 30 minutes to build. It runs forever.

Context doesn't transfer. If I'm in a long coding session with ProgrammierMinna and then ask Celebi "what did we just decide about the database schema?" — Celebi has no idea. Each agent has its own conversation history. I work around this by copying relevant context when I switch, but it's friction.

The Numbers

Metric	One Generalist	Three Specialists
Avg response time (coding)	8-15s	8-15s (same model)
Avg response time (writing)	8-15s	3-5s (smaller, faster model)
Avg response time (general)	8-15s	1-2s (tiny model)
Code review quality	6/10	9/10
Draft writing quality	5/10	8/10
Daily summary quality	7/10	8/10
Monthly cost	$0 (local)	$0 (local)
Setup complexity	Low	Medium
Maintenance overhead	Low	Medium

The quality jumps are subjective but real. I measured them by how often I had to ask for a redo. With the generalist, maybe 30% of responses needed a follow-up clarification. With specialists, maybe 5%.

When This Makes Sense (And When It Doesn't)

Do this if:

You have multiple distinct task types (coding + writing + analysis)
You have the hardware to run multiple models (even small ones)
You care about quality more than simplicity
You're already hitting the limits of your current model

Don't do this if:

You're just casually chatting with AI
You only have one machine with limited RAM
Your tasks are all similar (all coding, all writing)
You value simplicity over marginal quality gains

The Setup in 30 Minutes

If you want to try this, here's the fastest path:

Install Ollama on two machines (or twice on one machine if you have the RAM)
Pull different models: a coder model on one, a general model on the other
Write a 10-line router (like the Python snippet above)
Point your scripts at the router instead of directly at a model
Adjust keywords as you find mis-routes

Total time: 30 minutes. Total cost: $0.

The Real Win

The biggest change isn't technical. It's mental.

Before, I had one AI "employee" who was mediocre at everything. Now I have three specialists who are genuinely good at their jobs. When I send a query, I know which expert is handling it. I trust the output more. I spend less time verifying and fixing.

It's the difference between a Swiss Army knife and a actual toolbox. The knife fits in your pocket. But when you need to build something real, you want the right tool.

Sam Hartley is a solo dev running a multi-agent AI setup on a 3-machine home lab. Writes about the infrastructure that makes local AI actually usable.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #agents #automation #selfhosted #ollama #productivity #buildinginpublic

I Built a Garmin Watch Face with Live Stock Charts in Monkey C — Here’s What I Learned

Sam Hartley — Tue, 21 Jul 2026 08:02:19 +0000

I wanted stock prices on my wrist. Not a notification — an actual chart. So I built a custom Garmin watch face with live sparkline charts for 5 configurable assets.

Here’s what I learned building StockFaceTC for the Garmin Venu 2 Plus.

The Challenge

Garmin watch faces are tiny — 124KB memory, 416×416 AMOLED display, and a language (Monkey C) that most devs have never heard of. No npm. No frameworks. No Stack Overflow answers.

Oh, and the “simulator” can’t make web requests. You test API calls on real hardware or not at all.

What I Built

A watch face showing:

Time, date, and health stats (heart rate, steps, floors)
5 polar sparkline charts in an outer ring — each showing 24 hours of price data
Auto-updates every 15 minutes via Twelve Data API
6-hour weather forecast with custom-drawn icons
Fully configurable tickers via the Garmin Connect app

Default tickers: AAPL, TSLA, Gold, BTC/USD, ETH/USD

The Font Problem (and How I Solved It)

Garmin’s VectorFont API isn’t available on all devices. The Venu 2 Plus? Nope.

So I built my own: PrimitiveFont — a complete vector font library using only drawLine() calls. Every character is defined on a 5×7 grid and rendered procedurally.

// “A” on a 5×7 grid
CHAR_A = [0,6, 0,2,  0,2, 2,0,  2,0, 4,2,  4,2, 4,6,  0,4, 4,4]

Features:

Full alphabet (A-Z, a-z, 0-9, specials)
Proportional widths (Arial-like metrics — ‘i’ is narrow, ‘M’ is wide)
Bold, italic, underline
Arc text — characters curved along a circular path (for the ring labels!)
Any size via simple scaling: sizePx / 7.0

The entire library is ~21KB — well within the 124KB budget.

Architecture

Garmin Background Service (every 15 min)
  → Twelve Data API (1h candles × 24 = full day)
  → Phone acts as transparent HTTP proxy
  → JSON parsed in background thread (64KB limit!)
  → Prices + display names stored in model
  → View renders sparklines + arc labels on update

Key Constraint: 64KB Background Memory

The background service that fetches data runs in a separate 64KB sandbox. You can’t access the main app’s memory. The only way to pass data: Background.exit(dictionary), which the main app receives in onBackgroundData().

This means: parse JSON, extract only what you need, pass a minimal dictionary. No room for raw API responses.

Dynamic Labels from API

One early mistake: I hardcoded display names like “XAU/USD” → “GOLD”. That doesn’t scale.

Better approach: The Twelve Data API returns metadata with every response:

“meta”: {
    “symbol”: “XAU/USD”,
    “currency_base”: “Gold Spot”,
    “type”: “Precious Metal”
}

Now labels come from the API itself:

Stocks: meta.symbol → “AAPL”
Crypto: meta.currency_base → “Bitcoin” → “BITCOIN”
Commodities: meta.currency_base → “Gold Spot” → “GOLD”

Zero hardcoded aliases. Add any ticker, get the right label automatically.

Simulator Gotchas

If you’re building Connect IQ apps, save yourself some pain:

Properties are cached forever — changing properties.xml defaults does nothing after first run. Use “Reset All App Data” first.
makeWebRequest() doesn’t work in the simulator — you need a real phone connected via Bluetooth.
getSettingsView() must be implemented (even returning null) or the settings menu stays greyed out.
No VectorFont on many devices — if you need custom text, roll your own like PrimitiveFont.

API Budget

Twelve Data free tier: 800 API calls/day.

My budget: 5 symbols × 96 fetches/day (every 15 min) = 480 calls. Well within limits.

The Code

Source is on GitLab. Feel free to fork it, break it, or build something cooler.

What’s the weirdest hardware you’ve built for? Drop it in the comments.