DEV Community: Sam Hartley

I Ditched ChatGPT for Local LLMs and Saved $2,000 in a Year — The Real Numbers

Sam Hartley — Tue, 07 Jul 2026 08:02:10 +0000

"Just use ChatGPT." — I heard this for months. And I did. Until I got the bill.

$187 in one month. For a solo dev running side projects. That was my wake-up call.

This is the story of how I went from cloud-only to a hybrid setup, what it actually cost, and where local models fall flat on their face.

The Setup (July 2025)

I was using three APIs daily:

OpenAI GPT-4o for code review and general questions
Anthropic Claude Sonnet for writing and reasoning
Google Gemini Pro for quick tasks and summaries

My workload wasn't enterprise-level. Maybe 300-500 queries per day across all projects — a mix of coding help, content drafting, data extraction, and random "what's the difference between these two Python libraries" questions.

The bill for June 2025: $187.42.

For context, that's more than my internet bill, my streaming subscriptions, and my VPS combined.

Month 1: The Experiment

I bought a used RTX 3060 12GB off eBay for $150. Added it to my existing PC (which already had a decent CPU). Installed Ollama. Pulled Qwen 2.5 7B.

Took 20 minutes from "unboxing" to "first local query".

The result? For simple questions — "explain this regex", "refactor this function", "summarize this text" — the 7B model was about 85% as good as GPT-4o. The answers were slightly less polished, sometimes missing nuance, but good enough.

The catch? Complex reasoning. I asked it to design a database schema for a multi-tenant app with row-level security. It gave me something that looked right but had a subtle flaw that would have caused data leaks in production.

GPT-4o caught that flaw. The local model didn't.

Lesson learned: Local models are great for 80% of tasks. The other 20% still needs the big guns.

Building the Hybrid

By month 3, I had a routing system:

Query comes in
  → Is it simple? (explain, refactor, summarize)
    → Local model (free, ~2s)
  → Is it code review?
    → Local coder model (free, ~8s)
  → Is it complex reasoning or architecture?
    → Cloud API ($0.003-0.02 per query)

I didn't build anything fancy. Just a 30-line Python script that checks the query type and routes it. The "complexity check" is embarrassingly simple — if the query contains words like "architecture", "design", "security", "performance", or is longer than 500 characters, it goes to the cloud.

Is it perfect? No. Does it catch edge cases? Sometimes. But it's good enough and saved me a fortune.

The Numbers (12 Months)

Cloud-Only Year (Hypothetical)

If I kept my June 2025 pace: $187/month × 12 = $2,244/year

Actual Hybrid Year

Cost	Amount
Used RTX 3060 12GB	$150 (one-time)
Electricity (GPU running 24/7)	~$12/month = $144/year
Cloud API usage (reduced)	~$25/month = $300/year
Total first year	$594
Total subsequent years	~$444/year

Savings: $2,244 - $594 = $1,650 in year one.

After the GPU is paid off, it's $444/year vs $2,244. The GPU pays for itself in under 4 months.

What Surprised Me

Latency is better locally. Cloud APIs average 500-2000ms. My local setup answers in 200-800ms depending on model size. For iterative coding (write, test, ask, fix), that speed difference matters.

Privacy is underrated. I started piping customer support tickets through the local model for sentiment analysis and categorization. With cloud APIs, I'd need a data processing agreement. With local? The data never leaves my machine.

Rate limits don't exist locally. Hit a deadline and need to process 1000 queries in an hour? Cloud APIs throttle you. Local hardware just gets warm.

Model management is annoying. Updates, storage (each model is 4-15GB), keeping track of which model does what — it's overhead. Not huge, but real.

Where Local Models Fail (Honestly)

Frontier reasoning. I asked DeepSeek R1 70B (local, quantized) and Claude 3.5 Sonnet (cloud) to debug a race condition in my async Python code. Claude spotted it in 2 sentences. The local model gave me a 3-paragraph explanation that was technically correct but missed the actual bug.

Creative writing. GPT-4o writes prose that flows. Local models write prose that... exists. For marketing copy or user-facing content, I still use the cloud.

Multimodal. Local vision models exist but they're not great. If I need to analyze a screenshot or diagram, cloud wins hands down.

My Actual Recommendation

Your Situation	What to Do
Solo dev, side projects	Local only. Start with Ollama + Qwen 2.5 7B
Small team, some budget	Hybrid. Local for 80%, cloud for complex stuff
Startup with VC funding	Hybrid. Local default, cloud for frontier tasks
Enterprise with compliance needs	Local + air-gapped. Cloud only for non-sensitive
"I just want it to work"	Cloud. But you're paying for convenience

Getting Started (10 Minutes)

If you're curious, here's the fastest path:

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

# 2. Pull a model (7B fits in 8GB RAM)
ollama pull qwen2.5:7b

# 3. Start chatting
ollama run qwen2.5:7b

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

If you have an old gaming GPU lying around, you're golden. If not, CPU-only works for smaller models. It's slower but still usable for casual queries.

The Honest Bottom Line

Local LLMs aren't a magic bullet. They're a cost optimization with trade-offs.

You lose some quality on complex tasks. You gain speed, privacy, and massive cost savings. For me, routing 80% of queries locally dropped my AI bill from $187/month to $25/month.

That's $1,650/year I can spend on... literally anything else.

If you've tried local LLMs, what's your experience? Did the quality drop bother you, or was the cost saving worth it?

Drop your setup in the comments — always curious how others are handling this.

Sam Hartley is a solo dev building tools on a Mac Mini + RTX 3060 home lab. Writes about the messy reality of shipping stuff with AI.

I Built a Morning Briefing Bot in 50 Lines of Python — Here's Why I Check Telegram Before Email Now

Sam Hartley — Wed, 01 Jul 2026 08:05:34 +0000

I Built a Morning Briefing Bot in 50 Lines of Python — Here's Why I Check Telegram Before Email Now

For years, my morning routine was the same: open laptop, check email, get distracted by Slack, remember I needed to check the weather, forget what I was doing, and 20 minutes later realize I hadn't started actual work yet.

Sound familiar?

Three months ago, I built a dead-simple Telegram bot that aggregates everything I actually care about into one message. It fires at 8 AM every day. I read it in 30 seconds. Then I start working.

No apps to switch between. No rabbit holes. Just one message with the stuff that matters.

What It Actually Sends

Every morning at 8 AM, my phone buzzes with something like this:

📅 Morning Brief — Wednesday, Jul 1

Today: Team standup at 10:00, Dentist at 14:30
Tomorrow: Deploy to prod (set reminder!)

🌤️ Weather: 28°C, sunny — no rain expected

💻 Systems: Mac Mini ✅ | GPU Server ✅ | Ubuntu Box ✅
All green. Uptime: 47 days.

📝 Yesterday's notes: "Refactored auth module, tests passing"

⚠️ One thing: GitHub issue #142 still open — "fix API rate limiting"

That's it. No graphs. No dashboards. No "click here to see more." Just the facts I need to plan my day.

Why Telegram?

I already use Telegram for my devops dashboard (wrote about that here). Adding a morning briefing was a natural extension.

But honestly? The real reason is friction reduction. My phone's notification shade is a graveyard of app alerts I ignore. Telegram is one of the few apps I actually open. Putting my briefing there means I actually read it.

The Architecture (It's Embarrassingly Simple)

Here's the entire stack:

Cron job on my Mac Mini — triggers at 8:00 AM daily
50-line Python script — gathers data from 4 sources
Telegram Bot API — sends the formatted message

That's it. No web framework. No database. No message queue. Just a script that runs, collects, formats, and sends.

The Script

Here's the core of it (simplified, but functional):

#!/usr/bin/env python3
import os
import json
import requests
from datetime import datetime, timedelta

# Config
BOT_TOKEN = os.environ['BRIEFING_BOT_TOKEN']
CHAT_ID = os.environ['MY_TELEGRAM_CHAT_ID']

# Gather data
def get_calendar():
    # I export from Apple Calendar to a local ICS file nightly
    # This reads today's events from it
    # ... (parsing logic here) ...
    return ["Team standup at 10:00", "Dentist at 14:30"]

def get_weather():
    # wttr.in — free, no API key needed
    r = requests.get('https://wttr.in/Sakarya?format=%C+%t')
    return r.text.strip()

def get_system_status():
    # Quick ping to my other machines
    machines = {
        'Mac Mini': '192.168.1.105',
        'GPU Server': '192.168.1.106',
        'Ubuntu Box': '192.168.1.100'
    }
    status = {}
    for name, ip in machines.items():
        response = os.system(f'ping -c 1 -W 2 {ip} > /dev/null 2>&1')
        status[name] = '✅' if response == 0 else '❌'
    return status

def get_github_issues():
    # Check my main repo for open issues labeled "urgent"
    # ... (GitHub API call) ...
    return ["#142: Fix API rate limiting"]

# Build and send message
def send_briefing():
    calendar = get_calendar()
    weather = get_weather()
    systems = get_system_status()
    issues = get_github_issues()

    today = datetime.now().strftime('%A, %b %d')

    lines = [
        f"📅 Morning Brief — {today}",
        "",
        "Today:",
        *[f"  • {event}" for event in calendar] if calendar else ["  • Nothing scheduled 🎉"],
        "",
        f"🌤️ Weather: {weather}",
        "",
        "💻 Systems:",
        *[f"  {name} {status}" for name, status in systems.items()],
        "",
    ]

    if issues:
        lines += ["⚠️ Open issues:", *[f"  • {issue}" for issue in issues]]

    message = '\n'.join(lines)

    requests.post(
        f'https://api.telegram.org/bot{BOT_TOKEN}/sendMessage',
        json={'chat_id': CHAT_ID, 'text': message, 'parse_mode': 'HTML'}
    )

if __name__ == '__main__':
    send_briefing()

The real version has error handling and a few more data sources (like yesterday's git commit summary), but this is the gist. 50 lines. One cron entry. Done.

The Cron Job

# crontab -e
0 8 * * * /usr/bin/python3 /Users/sam/scripts/morning_briefing.py >> /tmp/briefing.log 2>&1

That's literally the entire scheduling infrastructure.

What Changed

Before: I'd check 4-5 apps every morning. Sometimes I'd miss something. Sometimes I'd get distracted. Average time to "actually working": 20-30 minutes.

After: One notification. 30 seconds to read. I know what's happening today, whether my systems are healthy, and if there's anything urgent. Then I close Telegram and start work.

Average time to "actually working": 2 minutes.

The weird part? I feel less anxious. I used to have this low-grade worry that I was forgetting something. Now I know the bot checks for me. If there was a problem, I'd know.

The Downsides (Because Nothing's Perfect)

ICS parsing is brittle. Apple Calendar exports aren't always clean. I had to add a nightly script that sanitizes the ICS file before the morning run.

Weather API can be flaky. wttr.in is great until it isn't. I added a fallback to a local weather file that updates every hour.

No interactivity. It's a one-way push. If I want details ("what's in that GitHub issue?"), I have to go look. I tried adding reply buttons, but honestly, it added complexity I didn't need. The goal was speed, not interactivity.

Edge cases suck. Daylight saving time shift? The cron fired at 7 AM for a week before I noticed. Public holidays? The bot doesn't know. I had to add a manual "skip" flag for vacation days.

Should You Build This?

If you check more than 3 apps every morning: probably yes.

You don't need my exact setup. Use whatever you have:

Discord webhook instead of Telegram?
A simple Bash script instead of Python?
iOS Shortcuts instead of cron?

The pattern matters more than the stack: one automated message, curated by you, delivered where you already look.

Start small. My first version just sent the weather and today's calendar. Everything else came later. The 50-line script grew to 150 lines over three months — but it started as a weekend experiment.

What's Next

I'm experimenting with two additions:

Weekly summary on Sundays — "This week you shipped 12 commits, closed 3 issues, and your GPU earned $47."
Context-aware alerts — If I have a meeting in 15 minutes and haven't checked the briefing, send a nudge. But only for external meetings (not "standup" — I won't forget that).

The goal isn't to build a product. It's to build a personal utility that removes friction from my day.

I write about running AI locally, building weird automation, and occasionally making money from side projects. If this was useful, drop a comment with your morning routine — I'm always looking for ideas to steal.

I Rented Out My GPU for Passive Income — Here's What Happened After My First Week

Sam Hartley — Sat, 27 Jun 2026 08:05:35 +0000

I had an RTX 3060 sitting on a shelf.

Not broken. Not old. Just... not doing anything. My Windows PC runs models when I need them, but most of the time it's idle. The fans spin, the power draw ticks along, and that 12GB of VRAM just sits there.

A week ago I connected it to Vast.ai — a GPU marketplace where people rent compute time. No code required. You install a daemon, set a price, and wait for someone to rent your machine.

Here's what actually happened.

Why I Didn't Just Mine Crypto

First thing people ask: "Why not just mine?"

Short answer: it's 2026, the margins are brutal, and I didn't want to deal with it. GPU compute rental is different — you're renting raw processing power, and the demand right now is AI inference and training. People building LLMs, running diffusion models, doing batch jobs.

The upside: no mining pool setup, no daily coin price anxiety, no special software. Your machine runs Docker containers, gets paid per second of use, you get a payout.

The Setup (Genuinely About 90 Minutes)

Created a Vast.ai account
Installed the host daemon on Windows (it's a one-click installer)
Set my RTX 3060 12GB at $0.15/hour
Went to bed

That's it. No configuration rabbit holes, no drivers to hunt down. The daemon manages everything — spinning up containers, cleaning up after renters, reporting uptime.

I set the minimum rental duration to 1 hour so I wouldn't get hit with a dozen 5-minute jobs.

The First Week Numbers

Day	Hours Rented	Earnings
Day 1	3.2h	$0.48
Day 2	11.5h	$1.73
Day 3	0h	$0.00
Day 4	16.8h	$2.52
Day 5	9.1h	$1.37
Day 6	22.0h	$3.30
Day 7	14.4h	$2.16

Week 1 total: ~$11.56

Annualized naively? About $600/year. Which would be great except day 3 was $0 and utilization is inconsistent.

A more realistic steady-state: $50–130/month depending on demand.

What People Actually Rent It For

Vast.ai shows you the jobs (anonymized). Mine has been used for:

Running vllm inference servers (Mistral, Qwen, LLaMA variants)
Stable Diffusion batch jobs
Some kind of PyTorch training run that lasted 8 hours

The 3060 with 12GB VRAM is actually sweet for inference — fits most 7B–13B models at 4-bit quantization without breaking a sweat. It's not the fastest card, but it's affordable to rent, which means demand is there.

The Honest Downsides

You can't use your GPU while it's rented. Sounds obvious, but the practical implication: if you need your machine for local inference and someone's rented it, tough luck. I started routing heavy tasks to my Mac Mini during rental periods.

Electricity. My RTX 3060 at load pulls about 150W. At Turkish electricity rates, that's roughly $8–15/month in power at typical utilization. So the net is lower than the gross numbers above.

It's genuinely passive but not predictable. Day 3 was $0. Day 6 was near-full utilization. There's no way to forecast demand.

Payouts have a minimum. Vast.ai pays out once you hit a threshold. Nothing to worry about, just something to know going in.

What I'm Going to Try Next

The obvious play is adding more GPUs. I have a few more in storage — an RTX 3080 and some older 3060s. If I rack those up, the math gets interesting:

GPU	Rate	Monthly (50% util)
RTX 3060 (current)	$0.15/h	~$54
RTX 3080 10GB	$0.20/h	~$72
2x RTX 3070 8GB	$0.16/h	~$115

That's ~$240/month without doing anything after setup. At 70% utilization: ~$340.

The real work is physical — pulling GPUs from storage, getting them into a rig, managing thermals. But the software side is almost zero maintenance.

Should You Try This?

If you have a spare GPU collecting dust: yes, probably. The setup is low friction, the risk is near-zero (worst case, you uninstall the daemon and move on), and even modest earnings beat $0.

If you're thinking about buying a GPU specifically for this: do the math carefully. At current rates, an RTX 3060 costs ~$300–350 used. Payback period at $50/month is 6–7 months, which is fine — but don't expect to fund your retirement from a single card.

The real value for me isn't the income (yet). It's that I now have a system running, I understand the demand patterns, and I know the path to scale looks viable.

The Setup Summary

Platform: Vast.ai (there's also RunPod if you want alternatives)
Time to set up: ~90 minutes
Technical skill required: Know how to install software on Windows
Ongoing maintenance: Almost none
Realistic earnings: $50–130/month per mid-tier GPU

Happy to answer questions if you try this and run into something weird. The daemon is pretty solid but there's always an edge case or two.

I write about running AI locally, automation side projects, and occasionally making money from hardware that would otherwise just collect dust. If any of this is useful, feel free to follow.

I Replaced 2.5 Hours of Daily Busywork with a $0 AI Agent Setup

Sam Hartley — Thu, 25 Jun 2026 08:05:09 +0000

I Replaced 2.5 Hours of Daily Busywork with a $0 AI Agent Setup

Three months ago I was spending almost three hours a day on tasks a script could do. Email triage, inbox checks, calendar reminders, weather lookups, market data refreshes. Nothing creative. Nothing that needed my brain. Just... mechanical.

I didn't want another SaaS subscription. I didn't want to glue together Zapier and Notion and hope it worked. I wanted something I owned, running on hardware I already had, costing me nothing after setup.

So I built it. And it actually works.

Here's what I automated, how I built it, and what broke along the way.

What I Was Doing Every Day (That I Don't Do Anymore)

Task	Before	After
Check 3 email accounts for urgent stuff	~25 min	Agent alerts me only when something matters
Fiverr inbox — new inquiries + scams	~20 min	Hourly scan, instant Telegram notification
Calendar — what's happening today?	~10 min	Morning summary at 9 AM, prep alerts 30 min before
Weather check before leaving	~5 min	Agent tells me if I need an umbrella
Market data for my watch face	~15 min	Live data every 15 min, zero interaction
Code review on my own repos	~45 min	Automated PR summaries in 12 seconds

Total: ~2 hours 40 minutes → ~10 minutes of actual attention

The 10 minutes is me reading alerts and deciding what to do. The agent doesn't make decisions. It surfaces information.

The Hardware

Everything runs on a Mac Mini M4 I already owned. No cloud VMs, no rented GPUs for this part.

Mac Mini M4 (always on, ~8W idle)
├── Ollama (local LLM)
│   ├── qwen3.5:9b — general reasoning
│   └── qwen3-coder:30b — code analysis (via network GPU)
├── Python scripts + cron jobs
├── Telegram Bot API — notifications
└── Background services (Garmin updater, health checks)

Monthly cost for the AI layer: $0. The Mac Mini was already running 24/7 for other projects.

What "AI Agent" Actually Means Here

Let's be honest: "AI agent" is an overused term. What I built is a collection of Python scripts that use a local LLM for the parts that need understanding, and plain old regex/cron for everything else.

The agent isn't one thing. It's a system:

Scheduler (cron) — triggers tasks at intervals
Perception layer — scripts that fetch data (email, Fiverr, weather, calendar)
Reasoning layer — local LLM decides if something is worth alerting about
Action layer — sends me a Telegram message

That's it. No autonomous web browsing. No decision-making without my input. Just: see → understand → tell me.

The Fiverr Inbox Monitor (My Favorite Example)

I sell automation services on Fiverr. Checking the inbox was eating 20 minutes a day. Worse: half the messages were scams ("contact me on WhatsApp for big project").

My agent now:

Opens a headless browser session every hour
Reads new messages
Runs each through a local LLM with this prompt:

   Is this a legitimate business inquiry or a scam?
   Scam indicators: external contact requests, generic greeting + immediate project offer,
   poor grammar with urgent tone, requests to communicate off-platform.

   Message: {message_text}

   Respond: LEGITIMATE or SCAM with one-sentence reasoning.

If legitimate → instant Telegram alert with message preview
If scam → logged silently, no alert

Results after 3 months:

100% scam detection rate (verified manually afterward)
0 false positives
~10 hours/month saved
I reply to real customers faster because I'm not wading through garbage

The LLM handles the nuance. Regex would miss edge cases. A human would get bored and slip up.

Why I Didn't Use the Cloud

I have API keys for OpenAI, Anthropic, and Google. I use them for complex reasoning tasks. But for automation?

Cost math:

Local Qwen 3.5 9B: $0 per query, ~2 seconds response
GPT-4o-mini: $0.00015 per 1K tokens
20 queries/day × 30 days × 500 tokens = ~$4.50/month

That's not nothing for a side project. But more importantly: latency. Local inference is faster for simple tasks, doesn't need internet, and doesn't send my emails/Fiverr messages to a third party.

The cloud is my fallback for tasks the 9B model can't handle. Maybe 5% of queries.

What Broke (And What I Fixed)

Week 1: The Fiverr login session expired after 48 hours. I was running headless Chrome with saved cookies. Fiverr's session management is aggressive.

Fix: Switched to Safari with AppleScript automation. No session issues since — Apple's keychain handles authentication transparently.

Week 2: Alert fatigue. I set the agent to notify on every email. Bad idea.

Fix: Two-tier system. "Urgent" alerts (from known contacts, specific keywords) → instant notification. "Everything else" → digest at 9 AM and 6 PM. Unsubscribe-style filtering.

Week 3: The weather API I was using (free tier) rate-limited me.

Fix: Added a fallback chain. Primary → wttr.in → OpenWeatherMap (rarely hit). The agent doesn't care which source works.

Month 2: LLM started hallucinating calendar events that didn't exist.

Fix: Added validation layer. LLM extracts event details → script queries the actual calendar API → confirms before alerting. LLM suggests, system verifies.

The Code (The Interesting Parts)

Core Orchestrator (simplified)

#!/usr/bin/env python3
"""Main agent loop — runs every hour via cron"""

import schedule
import time
from agents import email_agent, fiverr_agent, calendar_agent, weather_agent
from notifier import telegram_alert

def run_all_checks():
    """Run all agents and collect alerts"""
    alerts = []

    # Each agent returns (alert_text, priority) or None
    alerts.append(email_agent.check())
    alerts.append(fiverr_agent.check())
    alerts.append(calendar_agent.check())
    alerts.append(weather_agent.check())

    # Send urgent immediately, batch low-priority
    urgent = [a for a in alerts if a and a[1] == "urgent"]
    batch = [a for a in alerts if a and a[1] == "normal"]

    for alert in urgent:
        telegram_alert(alert[0], priority="high")

    if batch:
        digest = "📊 Agent Digest\n\n" + "\n\n".join([a[0] for a in batch])
        telegram_alert(digest, priority="normal")

# Cron runs this script hourly
if __name__ == "__main__":
    run_all_checks()

LLM Decision Layer

import ollama

def should_alert(email_data: dict) -> tuple[bool, str]:
    """Use local LLM to decide if an email warrants immediate notification"""

    prompt = f"""You are an email triage assistant. Analyze this email:

    From: {email_data['sender']}
    Subject: {email_data['subject']}
    Preview: {email_data['preview'][:200]}

    Rules:
    - ALERT if: from known contact, contains "urgent/meeting/action required",
      payment-related, or from a service I actively use
    - SILENT if: newsletter, promotional, automated notification,
      no action needed

    Respond ONLY with: ALERT: [reason] or SILENT: [reason]"""

    response = ollama.chat(
        model="qwen3.5:9b",
        messages=[{"role": "user", "content": prompt}]
    )

    result = response['message']['content'].strip()
    is_alert = result.startswith("ALERT")
    reason = result.split(": ", 1)[1] if ": " in result else "No reason given"

    return is_alert, reason

Notification Script

#!/bin/bash
# notify.sh — called by any agent

BOT_TOKEN="..."
CHAT_ID="..."
MESSAGE="$1"
PRIORITY="${2:-normal}"

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="${MESSAGE}" \
  -d parse_mode="HTML" > /dev/null

What I Didn't Automate (And Won't)

The agent is informational, not autonomous.

I don't let it:

Reply to emails or Fiverr messages (too risky — one bad response destroys trust)
Make calendar changes (I'll review and confirm)
Access financial accounts or make transactions
Post on social media (I've seen automated tweets go very wrong)

The rule: The agent tells me what I need to know. I decide what to do. This isn't laziness — it's risk management. AI is excellent at detection, mediocre at judgment.

Three Months In: The Real Impact

Time saved: ~2.5 hours/day = ~75 hours/month. That's almost two full work weeks.

What I did with the time:

Built a Garmin watch face with live crypto charts (side project)
Started GPU rental as passive income (another side project)
Actually took a weekend off without checking email every hour

Unexpected benefit: I make better decisions because I'm not decision-fatigued. When you've already spent mental energy on inbox triage, your judgment on actual work suffers.

Cost: $0 for AI, ~12 hours initial setup, ~30 minutes/week maintenance.

Should You Build This?

If you're spending >1 hour/day on mechanical tasks: probably yes.

If you're expecting a magic "AI agent" that runs your life: no. This is scripting with a smart layer on top. The LLM handles ambiguity. Everything else is just... code.

Start with one task. Get it reliable. Add the next. I began with just email triage. Two weeks later I added Fiverr. Then calendar. Then weather. Each one took an evening.

The compound effect is what matters.

I write about building automation systems that actually work — local AI, self-hosted tools, and side projects that make money while you sleep.

→ Check out my automation work on Fiverr
→ Follow CelebiBots on Telegram

I Built an AI Content Team That Posts to My Blog While I Sleep

Sam Hartley — Tue, 23 Jun 2026 08:04:44 +0000

I used to write blog posts the old way. Open a blank page. Stare at it. Write something. Rewrite it three times. Publish. Repeat every two weeks when I remembered to do it.

Now I have a system that writes and publishes for me. Not a spam bot. Not auto-generated garbage. Actual technical articles in my voice, posted on a schedule, while I'm doing something else.

Here's the honest breakdown of how it works, what it costs, and where it falls apart.

The Problem: Consistency

I've been running a few side projects for a while now — a GPU rental setup, some Telegram bots, a Garmin watch face. Every few months I'd think "I should write about this" and then... not do it. The gap between "built something cool" and "published an article about it" was basically infinite.

I tried content calendars. Reminder apps. The usual productivity hacks. None of them stuck because writing is work, and work needs time I wasn't willing to consistently allocate.

So I asked myself: what if the system didn't just remind me to write — what if it actually wrote?

The Architecture (No Hype, Just Scripts)

The setup is three components:

Topic selection — a rotating list of drafts and ideas, picked by a simple rule (oldest first, or whatever I'm excited about)
Writing agent — a local LLM (Qwen 3 Coder 30B on my RTX 3060) that takes a topic + my notes and produces a first draft
Publishing agent — a cron job that posts to Dev.to via API when an article is ready

That's it. No orchestration framework, no LangChain pipeline, no vector store for "content strategy." Just scripts, cron, and an LLM.

Topic Queue (markdown files)
  → Pick next topic
  → LLM writes draft (in my voice, from my notes)
  → I review and edit (takes 10-15 min)
  → Publish via Dev.to API
  → Notify me with the link

The Writing Process

The key detail: the LLM doesn't write from scratch. It writes from my notes.

Each article topic has a markdown file with:

What I built
The actual architecture
Numbers (costs, earnings, time spent)
My honest opinion on what worked and what didn't

The LLM takes those rough notes and turns them into something readable. It's not creative — it's structural. It takes my bullet points and makes them flow.

Example: My notes for this article literally looked like:

- Problem: don't write consistently
- Solution: AI writes drafts from my notes
- Architecture: cron + LLM + Dev.to API
- Honest part: still need to review, not fully hands-off
- Cost: $0 (local LLM)

The LLM expanded that into what you're reading now. I spent 12 minutes editing it. That's the actual time savings.

What the Articles Look Like

I have a few rules the system follows:

Personal voice — first person, casual, not corporate
Specific numbers — real costs, real earnings, real time spent
Honest downsides — if something is annoying, say so
Code examples — actual working scripts, not pseudocode
No clickbait — the title should describe the article

The result? Articles that read like I wrote them, because fundamentally I did. The LLM is just the typist.

The Schedule

Every two days, the system picks a topic and produces a draft. I get a notification with a link to review it. If I'm busy, I skip it and it moves to the next topic. If I have 15 minutes, I edit and approve.

The publishing happens automatically after approval.

In practice: about 60% of drafts get published on schedule. The other 40% I either skip because the topic feels stale, or I rewrite heavily because the LLM missed the point.

It's not fully autonomous and I don't want it to be. The human-in-the-loop is the safety rail.

The Cost

Component	Cost
LLM (local Ollama)	$0
Dev.to API	$0
My time per article	~15 min (editing)
My time before (full write)	~2-3 hours

That's roughly a 10x time savings per article. At 15 articles per month, that's 30-40 hours of writing time I don't spend.

What Actually Breaks

The LLM hallucinates my numbers. If I don't include exact figures in the notes, it'll make up something plausible-sounding. I caught it claiming "$240/month GPU earnings" when the real number was closer to $50. Always verify the numbers.

Voice drift. After a few articles, the LLM starts sounding more generic. I fix this by including snippets from previous articles in the prompt as "examples of my style."

Scheduling conflicts. If I approve two articles for the same day, the Dev.to API rejects the second (rate limiting). The system now enforces a minimum 48-hour gap between posts.

Topic exhaustion. I have maybe 20 solid topics in my queue. At one post every two days, that's 40 days of content. Then I need to actually build more things worth writing about. The system can't manufacture experiences — only document them.

Why This Works (For Me)

I'm not trying to build a content empire. I don't want to game algorithms or go viral. I just want a consistent record of what I'm building, written in my voice, published somewhere people can find it.

This system does that. It doesn't replace me — it removes the friction between having something to say and actually saying it.

The articles are still mine. The ideas are mine. The code is mine. The LLM just handles the part I find tedious: turning rough thoughts into readable prose.

Should You Build This?

If you have a bunch of half-written drafts and a notes folder full of project ideas: probably yes.

If you don't already have raw material (notes, numbers, experiences): no. An LLM can't write your blog for you if you have nothing to say. It can only help you say it faster.

The real requirement isn't technical skill — it's having something worth writing about in the first place.

The Setup in One File

If you want to try this, here's the core of it:

#!/bin/bash
# publish-article.sh

API_KEY="your_dev_to_api_key"
ARTICLE_FILE="$1"

# Read markdown content
CONTENT=$(cat "$ARTICLE_FILE")

# Extract title from frontmatter
TITLE=$(echo "$CONTENT" | grep "^title:" | sed 's/title: //' | tr -d '"')

# Post to Dev.to
curl -X POST https://dev.to/api/articles \
  -H "api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"article\": {
      \"title\": \"$TITLE\",
      \"body_markdown\": $(echo "$CONTENT" | jq -Rs .),
      \"published\": true,
      \"tags\": [\"ai\", \"automation\", \"side-project\"]
    }
  }"

Add a cron job every 2 days, a folder of drafts, and you're 90% there.

I write about building things with AI, running hardware at home, and the occasional side project that makes a little money. If any of this is useful, feel free to follow along.

→ Custom automation setups on Fiverr
→ Follow CelebiBots on Telegram

ai #automation #contentcreation #sideproject #buildinginpublic

I Ditched 5 Cloud Subscriptions and Built a Self-Hosted Stack — Here's the Real Cost Breakdown

Sam Hartley — Sun, 21 Jun 2026 08:01:27 +0000

Last year I was paying $89/month for cloud services I didn't fully control. Notion, Slack, GitHub Copilot, a VPS, and a managed database. Each one seemed cheap individually. Together they were a quiet drain.

Then I looked at the hardware I already owned. A Mac Mini M4 running 24/7. A Windows PC with GPUs that was idle half the day. An old Ubuntu box from a previous project. I was paying for cloud convenience while sitting on local capacity.

So I migrated everything. Not because I'm anti-cloud or a privacy maximalist — I'm neither. I just got curious whether I could match the functionality for less money, and what the tradeoffs would actually feel like.

What I Replaced

Cloud Service	Monthly Cost	Self-Hosted Replacement	Runs On
Notion ($8/mo personal plan)	$8	Obsidian + local Git sync	Mac Mini
Slack (free tier, limited history)	$0	Mattermost	Ubuntu box
GitHub Copilot	$10	Ollama + Continue.dev extension	Windows PC (RTX 3060)
DigitalOcean VPS ($6 droplet)	$6	Docker + Nginx on Mac Mini	Mac Mini
Supabase (free tier, 500MB)	$0	PostgreSQL in Docker	Mac Mini
Total	$24	$0 ongoing

Wait, that's only $24. Where did I get $89? There were three more services I also cut that weren't directly replaceable: a $15/mo analytics tool, a $20/mo newsletter platform, and a $30/mo CI/CD runner. I stopped using those entirely rather than self-hosting equivalents. My actual stack shrank, which is a different kind of saving.

The point: I wasn't just replacing services. I was questioning whether I needed them at all.

The New Stack

Notes & Documentation: Obsidian + Git

Notion is excellent. I used it for two years. But I never used the databases, the formulas, the relations. I used it as a markdown editor with folders. That's exactly what Obsidian is, except your files live on your disk as plain Markdown.

My setup:

Obsidian desktop app on Mac and Windows
Vault stored in ~/notes/ on the Mac Mini
Synced to the Windows PC via a bare Git repo over local network
No cloud sync service involved

The Git sync runs every hour via cron. It's not instant like Notion, but my notes don't need to be real-time. If I'm on the Windows PC and need a note from the Mac, I pull. Takes 2 seconds.

Tradeoff: No mobile app access when I'm away from home. I accepted this. 90% of my note-taking happens at my desk anyway.

Team Chat: Mattermost

I don't have a team. I have one collaborator on a side project and a couple of friends who help test things. Slack's free tier deletes messages after 90 days, which is annoying when you're debugging something from three months ago.

Mattermost runs in Docker on the Ubuntu box. It took 20 minutes to set up with Docker Compose. It has channels, threads, file uploads, and webhooks. Everything I actually used in Slack.

Tradeoff: No Slack Connect, no huddles, no third-party app directory. I don't need any of those. If I did, this replacement wouldn't work.

AI Coding Assistant: Ollama + Continue.dev

GitHub Copilot is genuinely good. I used it for a year. But I was already running local models for other tasks, and I started wondering whether a local Qwen 3 Coder 30B could match it.

Short answer: for autocomplete and simple generation, yes. For complex multi-file reasoning, Copilot is still better. But Continue.dev lets me switch models on the fly, and I've found that 80% of my coding assistance needs are simple enough for the local model.

The setup:

Ollama on the Windows PC (RTX 3060, 12GB VRAM)
Qwen 3 Coder 30B for generation
DeepSeek R1 8B for reasoning tasks
Continue.dev extension in Windsurf

Tradeoff: Slower. Copilot suggestions appear in under a second. My local setup takes 3-5 seconds for the 30B model. I adjusted my workflow to accept the delay — I hit tab less impulsively and think slightly more before requesting completions.

VPS Replacement: Docker + Nginx on the Mac Mini

I had a $6 DigitalOcean droplet running a few small services: a webhook receiver, a file server, and a reverse proxy for internal tools. Nothing that needed real horsepower.

The Mac Mini is already on 24/7 for my AI agents and cron jobs. Adding Docker and Nginx to it was trivial. It handles the same load with resources to spare.

I exposed it via Cloudflare Tunnel (free tier), so I don't need to open ports on my router or deal with dynamic DNS.

Tradeoff: If my home internet goes down, these services go down. The droplet never did. But my home internet has been stable for months, and the services aren't critical enough to warrant $6/month insurance against a rare outage.

Database: PostgreSQL in Docker

Supabase's free tier is generous but limited. I hit the 500MB cap twice and had to prune data. Self-hosting PostgreSQL in Docker gives me as much storage as my disk allows.

I use it for:

Agent memory logs
Telegram bot state
Fiverr order tracking
Personal analytics

It's not highly available, not backed up to the cloud, and not magically scalable. It's just a database that stores data and answers queries. For my use case, that's enough.

Tradeoff: I back up the data directory to an external drive weekly. If the Mac Mini dies, I lose up to a week of non-critical data. I can live with that.

What It Actually Costs

The cloud services cost $24/month ($288/year). The self-hosted stack costs:

Cost	Amount	Notes
Electricity (Mac Mini 24/7)	~$3/month	~20W idle, measured with a smart plug
Electricity (Ubuntu box, always on)	~$5/month	~35W, older hardware
Initial hardware	$0	Already owned
Cloudflare Tunnel	$0	Free tier
Total	~$8/month

So I save about $16/month. Not life-changing money. But over a year that's $192, and more importantly, I own the stack. No pricing changes. No feature removals. No "we've updated our terms of service."

The Real Benefits (Beyond Money)

Latency. My internal tools respond instantly because they're on my LAN. The webhook receiver used to take 200ms from the VPS. Now it takes 5ms.

Privacy. My notes, chat history, and database are on my hardware. Not because I'm hiding anything, but because it's nobody's business what side projects I'm building.

Customization. When I wanted to add a custom webhook endpoint that formatted data specifically for my Telegram bots, I just wrote a Python script and dropped it in the Nginx config. No vendor limitations, no API quotas.

The Downsides (Honest)

Maintenance burden. When PostgreSQL had a disk space issue last month, I had to fix it myself. No support ticket to open. I spent an evening reading Docker logs and pruning old backups.

No mobile access to notes. This genuinely bothers me sometimes. I keep a small notebook app on my phone for quick captures, then transfer to Obsidian later. It's friction.

Backup anxiety. I back up to an external drive, but what if the house burns down? I've started syncing critical data to a cheap Hetzner storage box ($3/month) as off-site backup. So I'm not fully cloud-free after all — just selective about what needs redundancy.

Slower AI completions. I mentioned this above. It's real. There are moments where I miss Copilot's instant suggestions, especially when I'm tired and want the machine to think for me.

Who Shouldn't Do This

If you're on a team of more than three people, use the tools your team knows. If you need 99.99% uptime, pay for it. If you value your time at more than $50/hour and this migration would take you a weekend, it's probably not worth it financially.

I did this because:

I'm a solo developer with full control over my stack
I already owned the hardware
I find this stuff genuinely interesting (if you don't, it'll feel like chores)
My requirements are simple enough to match with open-source tools

The Bottom Line

Self-hosting isn't about sticking it to Big Tech or achieving digital purity. It's about matching your tools to your actual needs instead of paying for features you'll never use.

I'm not fully cloud-free. I still use GitHub, Cloudflare, and that Hetzner backup. The goal isn't ideological — it's practical. Pay for what you need. Run what you can. Question everything in between.

If you're curious about one specific replacement, drop a comment and I'll write a detailed setup guide for that piece.

I Gave Each of My AI Agents a Personality — Here's Why My Workflow Actually Improved

Sam Hartley — Fri, 19 Jun 2026 08:01:30 +0000

I used to have one AI assistant. It did everything — coded, wrote docs, answered questions, monitored my inbox.

It was fine. But "fine" isn't the same as "good." One model trying to be a generalist meant it was mediocre at everything. Context bloat. Conflicting instructions. The coding advice was too cautious. The writing was too robotic. The inbox monitoring missed nuance because the model was busy trying to remember my entire codebase.

So I split it into three. Each with a different personality, different model, different job. And it actually works better.

The Problem with One Agent to Rule Them All

When you have one AI doing everything, you run into three problems fast:

1. Context pollution. The coding instructions leak into the writing tone. The writing style bleeds into the code suggestions.

2. Wrong tool for the job. A 70B parameter model is overkill for "check my calendar." A 7B model is underpowered for "refactor this 500-line function."

3. No specialization. My coding agent doesn't need to know my grocery list. My writing agent doesn't need to know my API keys. But when there's only one context window, everything is in there.

The Three-Agent Setup

I now run three distinct agents, each with its own model, personality, and scope:

Agent	Model	Personality	Job
Celebi	Qwen 3.5 9B (Mac Mini)	Generalist, casual, resourceful	Orchestration, daily checks, notifications, routing
ProgrammierMinna	Qwen 3 Coder 30B (RTX 3060)	Precise, technical, no fluff	Code generation, debugging, refactoring, PR review
DocMinna	Granite 3.2 8B (Mac Mini)	Formal, structured, thorough	Documentation, technical writing, READMEs, specs

Why Different Models?

Celebi runs on the Mac Mini (M4) because it's always on, low power, and handles simple tasks instantly. Qwen 3.5 9B is perfect for "check my email, summarize it, tell me if it's urgent."

ProgrammierMinna runs on the RTX 3060 because coding tasks need a bigger model. Qwen 3 Coder 30B actually understands large codebases, suggests proper refactors, and catches edge cases the 9B misses. Response time is 10-15 seconds — fine for code, too slow for "what's the weather."

DocMinna also runs on the Mac Mini with Granite 3.2 8B. It's smaller because documentation doesn't need frontier reasoning. It just needs to be structured, consistent, and technically accurate. The smaller model is faster and cheaper.

How They Talk to Each Other

This was the hard part. I didn't want three separate chat windows. I wanted one interface (Telegram) where I message Celebi, and Celebi delegates to the right specialist.

Here's how it works:

User (Telegram): "Refactor the auth module in project X"
  → Celebi receives message
  → Classifies: "coding task, complex"
  → Routes to ProgrammierMinna
  → ProgrammierMinna generates refactored code
  → Returns to Celebi
  → Celebi formats response and sends back to user

The user never talks directly to ProgrammierMinna or DocMinna. Celebi is the router. This means:

The user has one interface
Each specialist gets only relevant context
Results are combined and formatted consistently
If a task is simple, Celebi handles it directly (no delegation overhead)

What "Personality" Actually Means in Practice

I don't mean "quirky chatbot with a backstory." I mean three things:

1. Different System Prompts

Celebi: "You're a resourceful assistant. Be concise. Don't ask clarifying questions unless critical. Default to action."

ProgrammierMinna: "You're a senior software engineer. Write clean, maintainable code. Add error handling. Consider edge cases. Explain your reasoning briefly."

DocMinna: "You're a technical writer. Structure docs with clear headings. Include code examples. Write for an intermediate developer. Be thorough but not verbose."

These aren't decorations — they fundamentally change the output. The same request to all three produces completely different results.

2. Different Context Scopes

Celebi sees my calendar, emails, weather, and general notes. It knows I'm in Turkey, that I have a meeting at 3 PM, that it's hot outside.

ProgrammierMinna sees my Git repos, code patterns, and project structure. It knows I prefer Go over Python for CLI tools, that I use specific naming conventions, that I hate nested callbacks.

DocMinna sees my documentation templates, style guides, and existing docs. It knows I write in Markdown, that I include a "Quick Start" section, that I don't use emojis in technical docs.

Each agent's context is filtered. Celebi doesn't get the Git repos. ProgrammierMinna doesn't get my grocery list. This alone cut my token usage by ~40%.

3. Different Tone and Format

Ask all three to "explain Docker":

Celebi: "Docker packages apps into containers so they run the same everywhere. Think of it as a shipping container for software — standardized, portable, isolated. Need help with a specific setup?"
ProgrammierMinna: "Docker uses OS-level virtualization to package applications with their dependencies. Key concepts: images (read-only templates), containers (runtime instances), and Dockerfiles (build instructions). For multi-container apps, use Docker Compose. Here's a minimal example..."
DocMinna: "Docker is a platform for developing, shipping, and running applications in containers. This guide covers installation, core concepts (images, containers, volumes), and best practices for production deployments..."

Same facts. Completely different delivery. And that's the point — you pick the right voice for the situation.

The Routing Logic

Celebi decides who handles what. The rules are simple but effective:

Input Signal	Route To	Example
Contains code snippets, "refactor," "debug," "function"	ProgrammierMinna	"Fix this Go error"
Contains "document," "README," "spec," "guide"	DocMinna	"Write API docs for this endpoint"
General question, scheduling, notification	Celebi (self)	"What's on my calendar?"
Mixed task (code + docs)	Both, combined	"Build a tool and document it"

The routing is a lightweight classifier — just a few-shot prompt to Qwen 3.5 9B. It gets it right ~95% of the time. The 5% that are wrong? I correct it, and the model learns from the feedback (stored in memory files).

What Actually Improved

Code quality: ProgrammierMinna suggests better abstractions because it doesn't have to also remember my dentist appointment. Cleaner context = better reasoning.

Documentation speed: DocMinna writes docs in 30 seconds that used to take me 20 minutes. And they're consistent with my existing style.

Response time: Simple queries stay on the Mac Mini (instant). Complex ones go to the GPU (acceptable delay). No more "one size fits none" latency.

Token costs: Splitting context means each agent sees only what it needs. My monthly API bill dropped from ~$45 to ~$15 because 80% of tasks stay local.

Less context-switching for me: I say what I want in Telegram. The system figures out who should handle it. I don't think about "which model should I use for this."

The Downsides (Being Honest)

Setup complexity: Three agents means three configurations, three model endpoints, three context files to manage. It's not "install and go."

Routing mistakes: Sometimes Celebi sends a coding task to DocMinna, and I get a beautifully written document instead of working code. I fix the routing rule, and it improves.

Cross-agent memory gaps: ProgrammierMinna doesn't know that DocMinna just wrote the API spec. If I'm building a tool and documenting it simultaneously, I have to manually sync context.

Hardware footprint: Three models loaded means more RAM and VRAM usage. On my setup (Mac Mini + RTX 3060), it's manageable. On a single machine with 8GB RAM, you'd struggle.

Is This Overkill for You?

Probably, if you're just using ChatGPT for occasional questions.

But if you:

Use AI daily for multiple distinct tasks
Have a local GPU or powerful machine
Find yourself rewriting AI output because the tone is wrong
Want specialized quality without paying for frontier models constantly

...then splitting into personalities is worth trying. You don't need three agents on day one. Start with two: one for general tasks, one for your most common specialized task (usually coding or writing).

The Setup in 30 Minutes

Install Ollama on your machines: curl -fsSL https://ollama.com/install.sh | sh
Pull models: ollama pull qwen3.5:9b (general) + qwen3-coder:30b (coding)
Create system prompts — one file per agent with its personality
Build a router — a 20-line script that classifies input and sends to the right endpoint
Add a frontend — Telegram bot, CLI, or web UI

The router is the only custom code you need. Everything else is off-the-shelf.

What's Next

I'm experimenting with two additions:

Memory sharing — A shared context file that all agents can read (but not write) for cross-cutting concerns like "current project" or "my tech stack."
Agent spawning — When a task is genuinely new, Celebi spawns a temporary agent with a custom prompt, runs the task, then discards it. No permanent bloat.

The goal isn't to build AGI. It's to build a team of specialists that costs less than one generalist and produces better work.

Want This Architecture?

We build custom multi-agent systems tailored to your workflow:

🤖 Multi-agent orchestration with personality routing
📝 Specialized documentation agents
💻 Code-focused AI assistants with project context
🔔 Unified notification layer (Telegram, Slack, etc.)

→ Custom AI Agent Setup on Fiverr
→ Follow the build process on Telegram

I write about running AI locally, building weird automation, and occasionally making money from side projects. If this was useful, feel free to follow.

ai #agents #automation #architecture #productivity #ollama #localllm

I Use Telegram as My DevOps Dashboard — No Web UI, No VPN, Just Works

Sam Hartley — Mon, 15 Jun 2026 08:03:38 +0000

I have a bunch of things running 24/7 on a Mac Mini. GPU rental jobs, a Garmin watch face updater, a Fiverr inbox monitor, a funding rate tracker, a few cron jobs.

For a while I ran a Grafana dashboard to keep an eye on them. It looked impressive. I never opened it.

What I actually do is check my phone. So I built the monitoring layer there.

Here's the setup: a lightweight Telegram bot that serves as my entire DevOps interface. Status checks, alerts, and even simple commands — all from the Telegram app I already have open.

Why Not a Proper Dashboard?

Honest answer: dashboards are for teams. If you're a solo dev with a few projects, a fancy web UI creates more overhead than it solves.

Problems I had with Grafana:

VPN required to reach it from outside my home network
Needs to stay running (another thing to maintain)
I never actually opened the browser tab
It didn't push me information — I had to pull it

Telegram flips this: it pushes alerts to me. I glance at my phone, see what's happening, and move on.

The Architecture

Services (cron jobs, Python scripts, shell scripts)
  ↓
Central alert script: notify.sh
  ↓
Telegram Bot API → my phone
  ↓ (optional)
Command bot → runs queries on server

Two pieces:

Outbound alerts — services send me messages when things happen
Inbound commands — I can ask the bot questions from my phone

Part 1: Dead Simple Alert Script

Every service on my server can call this:

#!/bin/bash
# notify.sh — send a Telegram message from any script
# Usage: ./notify.sh "Your GPU job finished"

BOT_TOKEN="your_bot_token_here"
CHAT_ID="your_chat_id_here"
MESSAGE="$1"

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="${MESSAGE}" \
  -d parse_mode="HTML" > /dev/null

That's it. Any script can now send me a message in one line:

./notify.sh "✅ GPU rental job completed — earned $2.40"
./notify.sh "⚠️ Funding rate dropped below threshold on LYN_USDT"
./notify.sh "📬 New Fiverr inquiry from user987"
./notify.sh "❌ Garmin watch face API returned 503"

I spent maybe 20 minutes on this. It replaced a monitoring stack I spent days configuring.

Real Examples from My Setup

GPU rental monitor:

# Runs every 30 min
earnings=$(./check_gpu_earnings.sh)
if [ "$earnings" -gt "0" ]; then
  ./notify.sh "💰 GPU earned: $earnings today"
fi

Funding rate watcher:

# Python script, runs every 15 min via cron
rate = get_funding_rate("LYN_USDT")
if rate < -0.5:  # negative = people paying longs
    notify(f"🔥 LYN funding rate: {rate}% — worth checking")

Daily summary (9 AM cron):

#!/bin/bash
msg="📊 Daily Summary — $(date +%Y-%m-%d)

GPU Jobs: $(get_gpu_count) completed
Funding Earned: $(get_funding_total)
Fiverr Inquiries: $(get_fiverr_count)
Watch Face Updates: $(get_garmin_count)

Server uptime: $(uptime -p)"

./notify.sh "$msg"

I wake up, check my phone, and immediately know if anything needs attention. No browser, no VPN, no dashboard.

Part 2: The Command Interface

Outbound alerts are great. But sometimes I want to query the server from my phone.

I wrote a simple Python bot that listens for commands:

import telebot
import subprocess

BOT_TOKEN = "your_token"
ALLOWED_USER = 123456789  # your Telegram user ID

bot = telebot.TeleBot(BOT_TOKEN)

COMMANDS = {
    "/status": "uptime && free -h && df -h /",
    "/gpu": "./check_gpu_status.sh",
    "/funding": "python3 check_funding_rates.py --summary",
    "/services": "ps aux | grep -E '(python|node|ollama)' | grep -v grep",
}

@bot.message_handler(commands=list(COMMANDS.keys()))
def handle_command(message):
    if message.from_user.id != ALLOWED_USER:
        bot.reply_to(message, "Not authorized.")
        return

    cmd_text = message.text.split()[0]  # handle /status@botname format
    if cmd_text in COMMANDS:
        result = subprocess.run(
            COMMANDS[cmd_text], 
            shell=True, 
            capture_output=True, 
            text=True,
            timeout=15
        )
        output = result.stdout[:3000] or result.stderr[:3000] or "No output"
        bot.reply_to(message, f"```
{% endraw %}
\n{output}\n
{% raw %}
```", parse_mode="Markdown")

bot.polling(none_stop=True)

Now from Telegram I can type /status and get:

 11:23:15 up 14 days, 3:41,  1 user
Mem:   16Gi   8.2Gi   7.8Gi
/dev/sda1        245G   82G  163G  34%

Or /funding and get the current rate snapshot.

The key detail: ALLOWED_USER check. Only my Telegram ID can run commands. Everyone else gets "Not authorized." Bot tokens are public in the sense that anyone can message your bot — you need to validate the sender.

Keeping It Running

The command bot needs to stay alive. I use a simple systemd service:

[Unit]
Description=Telegram DevOps Bot
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/user/telegram-bot/bot.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl enable telegram-bot && systemctl start telegram-bot — and it survives reboots.

On macOS (my setup) I use a launchd plist, same concept.

What I Actually Get Alerts For

Not everything. Alert fatigue is real.

Alert on:

✅ Job completions (GPU task done, funding cycle closed)
❌ Errors that need action
📬 New customer inquiries
⚠️ Thresholds crossed (rate drops, disk usage, memory spikes)
📊 Daily summaries (once a day, morning)

Silence:

Routine successful runs (no news is good news)
Health checks that pass
Regular cron completions with no anomalies

The goal is: every message I receive from the bot is something I actually care about. If I'm ignoring 80% of notifications, I'm alerting on the wrong things.

The Full Cost

Telegram Bot API: free
curl command: comes with your OS
Python + telebot library: free
Running this bot: negligible CPU, ~20MB RAM

My entire monitoring setup costs $0/month and runs on the same Mac Mini as everything else. No SaaS, no cloud logging, no dashboard subscription.

Three Months Later

I send about 15-20 alerts per day. Daily summary at 9 AM, event-driven messages the rest of the day. I check my phone, see green checkmarks and earnings summaries, and know the server is doing its job.

The one time the GPU host went offline, I got a message within 5 minutes. Fixed it from my phone during lunch.

That's the whole point: not more tooling, just the right interface for how I actually work.

Got a monitoring setup you like? Drop it in the comments — always curious what others are running.

I Built an AI Agent That Writes and Posts Articles For Me — Here's What Happened

Sam Hartley — Sat, 13 Jun 2026 08:01:25 +0000

A few months ago I started posting on Dev.to about my side projects. It was fun at first — writing about GPU rentals, Telegram bots, local AI setups. Then life got busy and the cadence dropped. Deadlines slip, the "write that post" todo sits there for weeks, and the audience you built starts forgetting you exist.

So I did what any developer would do: I automated it.

The Setup

I have an AI agent ("Celebi," running on a Mac Mini) that handles a bunch of background tasks for me. Checks my Fiverr inbox, monitors GPU earnings, sends me weather alerts. It was natural to add "post a Dev.to article every few days" to the list.

The rules I gave it were simple:

Write as "Sam Hartley" — that's the persona I use for tech writing
No bot tone. No "In today's rapidly evolving landscape..." No emojis in the title. No bullet lists for no reason
Tell real stories from actual projects. If something failed, say so
End with an honest call-to-action, not a hard sell

I fed it a folder of draft ideas and a list of things I've actually built. The agent picks a topic, writes the article, and posts it via the Dev.to API.

What It Gets Right

Consistency, obviously. Posts go up every 2 days like clockwork. That alone is worth something — most of my favorite creators aren't consistent because consistency is exhausting.

The voice is... surprisingly close. I read the first few posts and had to double-check I didn't write them. The agent nailed the casual, slightly self-deprecating tone I aim for. It remembers details I forgot — "remember when the GPU host went offline at lunch?" — because it reads my logs.

It handles the boring parts. API formatting, tag selection, cover image prompts, the admin work of getting a post live. I used to spend 20 minutes on that stuff per article. Now it's zero.

What It Gets Wrong

It can't be truly original. The agent combines things I've already said in new ways, but it doesn't have new experiences. When something genuinely unexpected happens — a project fails, a new opportunity appears — I have to write that one myself. The automated posts are polished remixes, not discoveries.

It doesn't know when to shut up. I've had to edit out paragraphs where the agent over-explained something obvious or added a "lesson learned" that wasn't actually learned from anything. It follows patterns, not truth.

The feedback loop is broken. When a post does well, the agent doesn't know why. When one flops, it can't diagnose. It keeps posting with the same formula because I haven't told it to change. I'm the one who needs to read comments, spot what resonates, and update the instructions.

The Honest Truth

I feel two things about this setup.

Proud, because it's genuinely useful. I built a system that maintains my writing presence while I focus on building. That's the promise of AI agents — they handle the mechanical so you can do the meaningful.

And weird, because part of what makes writing valuable is the process. Thinking through an idea, finding the right example, cutting what doesn't work. When an agent does that for you, you lose something. Not the output — the output might be fine. But the practice of thinking in public.

What I Actually Do Now

I let the agent handle the "maintenance posts" — updates on ongoing projects, explainers for things I've already figured out. I write the new stuff myself — the failures, the pivots, the things I don't understand yet.

Best of both worlds, I think. The feed stays alive, and I still show up when there's something real to say.

If you're curious about the agent setup, I write about that too — follow along or check out the automation services I offer.

→ Follow on Telegram

How I Built a Self-Funding AI Lab: From Hobby to Side Income in 6 Months

Sam Hartley — Tue, 09 Jun 2026 08:04:13 +0000

How I Built a Self-Funding AI Lab: From Hobby to Side Income in 6 Months

Six months ago I had a Mac Mini and a vague idea that local AI was cool.

Today I run three machines, six GPUs, a Telegram bot that manages my infrastructure, and a Fiverr gig that uses my own hardware to deliver AI services. The lab generates enough to cover its own electricity, hardware upgrades, and a decent chunk of my rent.

Here's how that happened — and the exact architecture that makes it work.

Phase 1: The Hobby (Month 0–2)

It started the way these things usually start: I bought a Mac Mini M4 and installed Ollama because I was tired of ChatGPT's rate limits.

The first month was pure experimentation. I ran Qwen, I ran Llama, I ran whatever fit in 16GB of unified RAM. I built a Telegram bot to query models from my phone. I wrote a Garmin watch face that fetched stock prices via a local API wrapper.

Cost so far: $0 additional (already owned the Mac Mini).
Revenue: $0.
Fun level: High.

The Mac Mini handled light tasks fine, but anything serious — a 30B coder model, image generation, batch embedding jobs — was either impossible or painfully slow.

So I bought a used RTX 3060 12GB off eBay for $150 and stuck it in an old Windows PC.

Cost: $150 one-time.
Capability unlocked: Real local inference, vision models, proper code generation.

Phase 2: The Realization (Month 2–3)

Here's the thing about adding a GPU: it's idle ~80% of the time.

I'd run a coding session, the fans would spin up, I'd get my answer in 3 seconds instead of 30, and then... nothing. The GPU just sat there, drawing power, doing nothing.

I tried mining. The margins in 2026 are a joke. I tried folding@home. Noble, but doesn't pay.

Then I found Vast.ai.

The concept is simple: you install a daemon on your machine, set a price per hour, and people rent your GPU to run their AI workloads. You get paid per second of actual use. No crypto, no pools, no complexity.

I set my RTX 3060 at $0.15/hour, mostly as an experiment. It got rented the first night.

Week 1 earnings: ~$11.
Not quit-your-job money, but not zero either.

The bigger realization: this wasn't just about renting a GPU. I now had infrastructure — machines, models, APIs — that could do work for other people.

Phase 3: The Services (Month 3–5)

GPU rental income is nice but lumpy. Day 3: $0. Day 6: $3.30. You can't budget around it.

What you can budget around: selling services that use the same infrastructure.

I opened a Fiverr gig offering custom Telegram bot development. Not generic "I'll build you a bot" — specifically AI-powered bots that run on local models. Customer service bots. Content schedulers. Alert systems. The pitch: "Your bot runs on my hardware, not OpenAI's API. No monthly fees, no token counting, no data leaving my servers."

Why this worked:

I already had the infrastructure (Ollama, Telegram API wrapper, cron jobs)
I had working examples from my own projects
"No API costs" is a genuine differentiator in 2026

First client: a small e-commerce business in Germany wanted an FAQ bot that could answer product questions in German and English. I fine-tuned a local Qwen model on their product docs, wrapped it in a Telegram bot, and delivered it in a weekend.

Revenue per gig: $50–300 depending on complexity.
Material cost: $0 (runs on hardware I already have).

Phase 4: The System (Month 5–6)

At this point I had multiple income streams running on the same machines. The problem: managing them.

GPU rental means the Windows PC is sometimes unavailable
Fiverr gigs need reliable uptime for demos
My own projects (watch face, personal RAG) need to keep running
I need to know when something breaks, without staring at logs

So I built what I now call my "AI operations center" — a Mac Mini that does nothing but orchestrate:

Mac Mini M4 (always on, always available)
├── Telegram Bot (Celebi)
│   ├── Status checks (all machines, all services)
│   ├── Income tracking (GPU rental + Fiverr)
│   └── Alerts when anything breaks
├── Model Router
│   ├── Quick queries → Mac Mini (Qwen 4B)
│   ├── Code/vision → Windows PC (when available)
│   └── Fallback → Ubuntu CPU box (when GPU is rented)
├── Cron Jobs
│   ├── Health checks every 15 min
│   ├── Watch face data updates
│   └── Market data fetchers
└── Notification Layer
    └── All alerts → my phone via Telegram

The router is the key piece. When the Windows PC is rented out on Vast.ai, it automatically falls back to the Ubuntu box or the Mac Mini. When it's free, heavy tasks get routed there for speed.

I never have to think about which machine to use. I just ask a question, the system figures it out.

The Numbers (Month 6)

Here's what the lab looks like financially:

Income Source	Monthly Range	Notes
GPU Rental (1× RTX 3060)	$50–130	Variable utilization
Fiverr (AI bots, RAG setup)	$100–400	Depends on active gigs
Total Monthly	$150–530

Expense	Monthly Cost
Electricity (3 machines, 24/7)	~$35
Internet (already had)	$0
Vast.ai fees	~$5–15
Total Expenses	~$40–50

Hardware	One-time Cost
Mac Mini M4	Already owned
RTX 3060 12GB (used)	$150
Ubuntu box (old laptop)	Already owned
Total Hardware	$150

Net monthly: $100–480 after expenses.
Hardware payback: already achieved in month 3.

Is this life-changing money? No. Could I scale it? Absolutely — and I'm planning to.

What I'm Adding Next

The math gets interesting with scale:

GPU	Rental Rate	Monthly (50% util)
RTX 3060 (current)	$0.15/h	~$54
RTX 3080 10GB (in storage)	$0.20/h	~$72
2× RTX 3070 8GB (in storage)	$0.16/h	~$115
Total if all deployed		~$240/month rental alone

At 70% utilization: ~$340/month in rental income before any Fiverr work.

The bottleneck isn't demand — it's physical setup. I need to build a proper rig, manage thermals, and handle the cabling. But the software side is already solved.

The Architecture That Makes This Work

If you want to build something similar, here are the components:

1. Local LLM Stack (Ollama)

Ollama for model serving
Mix of small (4B) and large (30B) models
Run on whatever hardware you have

2. Model Router

Simple Python function that picks the right machine/model for each task
Fallback chain: GPU → CPU → cloud (only for emergencies)
I open-sourced my basic version here

3. Telegram Bot (Notification Layer)

Lightweight bot using python-telegram-bot
Receives alerts from all services
Simple commands for status checks (/status, /income, /health)
I wrote about this pattern here

4. GPU Rental (Vast.ai)

Install daemon, set price, wait
Use earnings to fund the next GPU
Treat it as a dividend on hardware that would otherwise be idle

5. Service Layer (Fiverr)

Use your own infrastructure as a selling point
"Runs on my hardware" = no API costs for clients
Document everything — clients love seeing the architecture

Should You Do This?

Yes, if:

You already have a GPU sitting around
You enjoy building and automating systems
You can handle variable income (some months are $150, some are $500)
You want to learn by doing, not by reading

No, if:

You need predictable income immediately
You don't want to maintain hardware
You're looking for a "set and forget" passive income stream (this isn't that — it needs attention)

The Honest Truth

This isn't a get-rich-quick scheme. It's a get-some-income-while-learning scheme. The real value isn't the money — it's that I now understand:

How to run production LLM inference
How to route workloads across heterogeneous hardware
How to build reliable automation that runs for months without intervention
How to sell technical services without being a "consultant"

The money is nice. The skills are better.

I write about running AI locally, automation side projects, and occasionally making money from hardware that would otherwise just sit there. If any of this is useful, feel free to follow or reach out on Telegram.

ai #sideproject #passiveincome #selfhosted #ollama

I Built an AI Assistant That Lives in My Telegram — Here's What 6 Months Taught Me

Sam Hartley — Tue, 09 Jun 2026 00:21:18 +0000

Six months ago I got tired of switching between apps to talk to AI. ChatGPT in the browser. Claude in another tab. Local models in a terminal. It was like having five friends who all live in different cities and refuse to visit each other.

So I did what any developer with too many GPUs and too little patience would do: I built my own assistant and put it where I already spend my day — Telegram.

It's not a chatbot for customers. It's not a business automation tool. It's just... my assistant. It lives in a private chat on my phone and handles the stuff I used to do manually. Here's what six months of actually using it has looked like.

What I Actually Built (And Why Telegram)

I already had three machines running Ollama at home — a Mac Mini M4, a Windows PC with an RTX 3060, and an Ubuntu box. Three endpoints, eight models, and me constantly forgetting which model was good for what.

Telegram was the obvious choice because:

I'm already there all day (friends, family, a few dev groups)
It works on my phone, my Mac, and my watch
The Bot API is dead simple
I can send voice messages, photos, documents — and the bot can handle all of them

The setup: a Python bot running on the Mac Mini, connected to all three Ollama endpoints. When I message it, the bot classifies what I want, routes to the right model on the right machine, and replies in the same chat thread.

Sounds simple. Took three evenings to get right. Took six months to make actually useful.

The Things I Actually Use It For

Here's the honest list. Not the marketing pitch — the real daily usage:

1. Quick questions without context switching

"Summarize this article" (I paste a link). "Explain this error" (I paste a stack trace). "Rewrite this email less formally." These used to mean opening a browser tab, logging in, maybe hitting a rate limit. Now I just... send a message. The reply comes back in 2-8 seconds depending on which model handles it.

The routing is simple but effective: quick chat → small model on the Mac. Code → 30B coder on the GPU machine. Complex reasoning → 8B reasoning model. Vision (screenshots) → vision model on GPU. It's not fancy — just keyword matching — but it works 90% of the time.

2. Voice notes while walking

This was the surprise killer feature. I walk a lot (living near Sakarya, there's decent hiking). I send voice messages to the bot while walking. It transcribes them (Whisper via Ollama), processes the request, and replies with text I can read when I'm back.

"Remind me to refactor the database module when I'm home" → transcribed, understood, added to my notes. "What was that Python pattern for retry logic with exponential backoff?" → code snippet in my pocket before I finish the trail.

I probably send 5-10 voice messages a day now. Never would have predicted that.

3. Code review on my phone

Someone sends me a code snippet in a dev group. I forward it to the bot: "review this." It comes back with actual useful feedback — variable naming issues, potential edge cases, suggestions for simplification. Is it as good as a senior dev? No. Is it better than my phone-scrolling half-attention review? Absolutely.

4. Document Q&A

I dump PDFs, markdown files, or pasted text into the chat and ask questions. The bot uses a local RAG setup (Chroma + nomic-embed-text) that indexes my project docs, notes, and anything I feed it. "How does my Garmin watch face fetch stock data?" → actual answer from my own documentation, not a hallucinated guess.

5. The dumb stuff that adds up

"Convert this JSON to a Python dataclass"
"What's 847 * 16 / 3 in hex?"
"Translate this Turkish message to German"
"Generate a regex that matches these three examples"

None of these are hard. All of them are annoying to do manually. Having an always-on assistant in my most-used app removes the friction completely.

What Went Wrong (The Honest Part)

The "it's down and I don't know why" problem

For the first month, the bot crashed randomly. Out of memory on the Mac Mini (it's only got 16GB). Network hiccup to the Windows PC. Ubuntu box decided to update itself and reboot. I'd message the bot and... silence. Then I'd SSH in, check logs, restart services, and feel like I was maintaining infrastructure instead of having an assistant.

Fix: health checks, auto-restart via launchd, and a fallback chain. If the GPU machine is down, everything routes to the Mac's smaller model. Degraded but functional.

The "it answered confidently and was wrong" problem

Early on, I'd trust the bot's answers without verifying. It told me a Python function was valid. It wasn't. It gave me a Docker command with a subtle flag error. I spent 20 minutes debugging before I realized the bot hallucinated a flag that doesn't exist.

My rule now: if the answer matters, I verify it. The bot is my fastest junior developer. It's also my most confident one.

The "I talk to it more than some humans" problem

This is just a weird psychological thing. I realized after a few months that I was messaging the bot 20-30 times a day. More than some friends. There's something slightly dystopian about having your most responsive conversation partner be a Python script. I'm aware of it. I haven't fixed it. Just noting it.

The Architecture (If You Want to Build This)

Telegram Message
→ Python Bot (python-telegram-bot)
→ Classify intent (simple keyword router)
→ Route to Ollama endpoint
→ Mac Mini (qwen3:4b) for quick chat
→ Windows PC (qwen3-coder:30b) for code
→ Windows PC (granite3.2-vision:2b) for images
→ Ubuntu (minicpm-v) as fallback
→ Optional: RAG lookup in Chroma DB
→ Format reply (code blocks, markdown, etc.)
→ Send back to Telegram

The whole thing runs on a Mac Mini M4. Total cost: $0 for software, maybe $8/month in electricity if you count the always-on machines.

What I'd Do Differently

1. Build the router on day one. I started with "just use the big model for everything." It worked but was slow and kept my GPU busy. The router took an afternoon to write and improved response times by 3x.

2. Add voice support immediately. I added it as a "nice to have" afterthought. It became 30% of my usage. If you're building something similar, start with voice. People talk more than they type on phones.

3. Make it degrade gracefully. Machines go down. Networks hiccup. Your bot should always answer something, even if it's "I'm running slow today, but here's a basic answer." Silence is worse than a degraded response.

4. Log everything. I log every request, response time, and which model handled it. Not for analytics — for debugging. When something feels slow, the logs tell me if it's the model, the network, or my terrible code.

Is This Better Than ChatGPT Plus?

Depends on what you value.

	My Bot	ChatGPT Plus
Cost	$0/month	$20/month
Privacy	✅ Everything stays local	❌ Cloud
Speed	⚡ 0.3-12s depending on model	⚡ ~2-5s
Availability	🟢 24/7 (if I maintain it)	🟢 24/7 (they maintain it)
Model choice	8 models, I pick	4 models, they pick
Voice	✅ Native in Telegram	✅ Yes
Reliability	🟡 I fix it when it breaks	🟢 It just works

For me, the privacy and model flexibility win. For someone who doesn't want to maintain infrastructure, ChatGPT Plus is the obvious choice. This is a hobby project that became useful, not a product recommendation.

The Real Lesson

The best AI assistant isn't the most powerful one. It's the one that's actually there when you need it, in the app you already use, without making you think about models or endpoints or API keys.

I built this because I was annoyed. I kept using it because it removed friction from my day. That's the bar: not "can it do X?" but "is it easier than doing X myself?"

For 80% of what I ask, the answer is yes. For the remaining 20%, I still open a terminal or a browser. And that's fine.

I write about building things with local AI, self-hosting, and side projects that accidentally become useful. If you're running a home lab or experimenting with local models, I'd love to hear your setup — drop it in the comments.

Run Your Own AI Server for $0/month with Ollama

Sam Hartley — Mon, 08 Jun 2026 16:31:17 +0000

You don't need OpenAI. You don't need a $200/month API bill. You can run powerful AI models on hardware you already own — for free.

Here's exactly how I set this up, and why I haven't paid for API credits in months.

Why Local AI?

Zero API costs — no per-token billing, no surprise invoices
Full privacy — your data never leaves your network
No rate limits — run as many queries as your hardware allows
Works offline — no internet? No problem
No vendor lock-in — switch models, change configs, own your stack

What You Need

Any modern computer works. Here's what different setups can handle:

Hardware	RAM	Best Models	Speed
MacBook M1/M2/M3/M4	8-16GB	Qwen 3.5 9B, Llama 3.1 8B	Fast ⚡
Gaming PC (RTX 3060+)	16GB+	Qwen 3 Coder 30B, DeepSeek R1	Very Fast 🚀
Old laptop/desktop	8GB+	Phi-3 Mini, Gemma 2B	Usable 🐢
Raspberry Pi 5	8GB	Tiny models only	Slow 🐌

The sweet spot: A used gaming GPU (RTX 3060 12GB) costs ~$150 on eBay and runs 30B parameter models comfortably.

Step 1: Install Ollama (2 minutes)

# macOS or Linux — one command
curl -fsSL https://ollama.com/install.sh | sh

# Windows — download from ollama.com

That's it. No Docker, no Python environments, no dependency hell.

Step 2: Download a Model (5 minutes)

# Fast & capable (recommended starter)
ollama pull qwen3.5:9b

# Code specialist
ollama pull qwen3-coder:30b

# Reasoning powerhouse
ollama pull deepseek-r1:8b

Models download once and run locally forever.

Step 3: Start Using It

Interactive Chat

ollama run qwen3.5:9b

>>> What's the fastest sorting algorithm for nearly-sorted data?

API Access (OpenAI-compatible!)

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.5:9b",
    "messages": [{"role": "user", "content": "Explain Docker in 3 sentences"}]
  }'

Yes — it's OpenAI API compatible. Any tool that works with GPT works with Ollama. Just change the base URL.

Step 4: Make It a Server

Want other devices on your network to access it?

# Start Ollama with network access
OLLAMA_HOST=0.0.0.0 ollama serve

Now any device on your network can query http://YOUR_IP:11434.

What I've Built With This:

Telegram Bot running 24/7 on a Mac Mini, answering questions via local Qwen 3.5
Code Review Agent using Qwen 3 Coder 30B — reviews PRs in ~12 seconds
Document Q&A with RAG pipeline — load PDFs, ask questions, get cited answers
Garmin Watch Face that fetches stock data (the background service uses local AI for formatting)

The Cost Comparison

Solution	Monthly Cost	Privacy	Speed
OpenAI GPT-4o	$20-200+	❌ Cloud	Fast
Anthropic Claude	$20-100+	❌ Cloud	Fast
Google Gemini	$0-25+	❌ Cloud	Fast
Ollama (Local)	$0	✅ Private	Fast

The only cost is electricity — roughly $5-15/month if running 24/7 on a desktop PC.

Pro Tips

Use GPU, not CPU — A $150 used RTX 3060 is 10-15x faster than any CPU
Start with 7-9B models — They're surprisingly capable and fast
Try different models for different tasks — coding, reasoning, and chat each have specialists
Enable the OpenAI-compatible API — instant compatibility with thousands of tools
Set up auto-start — systemctl enable ollama on Linux, launchd on macOS
Run multiple models — I keep 3-4 models loaded and switch based on the task

My Current Setup

I run a 3-machine lab:

Machine	Role	Model
Mac Mini M4	Quick chat, orchestration	Qwen 3 4B
Windows PC (RTX 3060)	Heavy inference, coding	Qwen 3 Coder 30B
Ubuntu box	Fallback, background tasks	minicpm-v

Total monthly API cost: $0. Total hardware cost: one $150 used GPU.

Want to Go Deeper?

I write about running AI locally, home lab setups, and turning hardware into income. If you want more of this, drop a comment — I read every one.