Detailed content
🔄 The paradigm shift
Almost everyone uses AI in on demand: you open the chat, ask a question, read the answer, and close it. AI only “exists” while you’re there, typing. Local AI unlocks a second mode, much more powerful and almost unknown to anyone who has only used the cloud: the agent that never closes — the always-on setup.
The logic is simple. Your machine is already on. The local model doesn't charge per use. So there's no reason for the AI to sit idle waiting for you. It can work in the background all the time: scanning a repository for bugs, monitoring web sources, summarizing what's arrived in your inbox, organizing files. Tasks that run continuously, without anyone asking anything.
🆕 New here?
"Always-on" (always-on) is AI running continuously in the background, even when you're not looking. "Worker" is each process dedicated to a repetitive task — think of an employee who does a thing, nonstop. An always-on agent is usually built as one (or several) workers.
🔑 The central idea
Local = unlimited + always on. This combination enables a whole class of uses that the cloud makes too expensive:
- •Environment usage: the AI stays in the environment, working in the background instead of only responding when called.
- •Ongoing, not one-time: thousands of runs per day stop being a billing problem.
- •Don’t fear the meter: you experiment, leave it running, forget about it — only the electricity counts.
📊 Two modes, side by side
- On demand: you start, the AI responds, and you end the session. Great for a one-off question.
- Always-on: a trigger starts the AI on its own; it acts, logs what it did, and goes back to sleep — forever. Great for monitoring, scanning, and keeping something up to date.
- It’s not “one or the other”: always-on is a new layer you get by running locally.
💸 Why it only works locally
Always-on isn’t a matter of personal preference — it’s savings. In the cloud, each model call comes with a toll. For one question a day, nobody notices. For an agent that runs every few minutes, day and night, the bill explodes. Locally, the same workload costs only the electricity the machine would use anyway.
🧮 The calculation that changes everything
A worker that triggers every 5 minutes runs:
In the cloud, multiply that by the price per call—and by the number of workers you have. Locally, the number of calls is irrelevant for the bill: it doesn't exist.
Compare the two cost models side by side:
✓ Local (always-on)
- ✓Marginal cost per call ≈ zero
- ✓Running 24/7 doesn’t change the bill—just the electricity
- ✓No rate limits: run it as many times as you want
- ✓Data stays on the machine — nothing leaks by default
✗ Cloud (toll per call)
- ✗Each call costs money — 24/7 adds up fast
- ✗Multiple workers = the bill adds them all up
- ✗Rate limits and quotas hold you back at the worst moment
- ✗Each run sends your data outside
💡 Practical tip
Power isn't free, but it's low and predictable. A small model (3–8B) on a modest PC uses little power while it's just waiting for the next trigger—the GPU/CPU only "wakes up" at inference time. The real cost of always-on is idle machine time, which you’re already paying for anyway.
🧬 Anatomy of a continuous worker
Every always-on worker, no matter how sophisticated it seems, has the same four-part anatomy. Once you see the skeleton, building any of them (and following the step-by-step guides in upcoming lessons) becomes a matter of fitting together familiar pieces.
Read the cycle clockwise: the timer (in amber) triggers the agent, which thinks, runs the action and records a log. The cyan arrow closes the loop: everything goes back to the beginning and repeats nonstop, 24/7.
The four pieces in practice:
Scheduler (the trigger)
What decides when run: a cron job on a schedule, a loop that sleeps between runs, a "watch" that reacts to a new file. It’s the worker’s alarm clock.
The task
The concrete, well-defined task: collect data, scan a repo, read a folder. Usually a deterministic part (no AI) that prepares the material.
The local model
The intelligence: the agent calls the local API (the one from module 3.5) to triage, classify, summarize, or decide. This is where the LLM adds value to what the task collected.
The output
The result that survives the cycle: a file (relatorio.md), a notification, a line in the log. Without persistent output, the work disappears.
⏰ Triggers: cron, watch, queue
The piece that turns an ordinary script into an always-on worker is the trigger. There are three flavors, and you choose based on what triggers the task: the clock, an event, or a job in the queue.
🆕 New here?
- Cron: task scheduler by time, built into Linux/macOS. You describe "every X" and the system runs it automatically—even if you're not logged in.
- Watch: instead of on a schedule, triggers on event — typically “a file appeared/changed in this folder.” It reacts right away.
- Queue: a list of jobs to do; the worker picks them up one at a time and processes them. Useful when more work comes in than you can handle right away.
⏱ Cron / loop
Triggered by time. "Every 20 min", "every day at 3 a.m." The workhorse of always-on.
👁 Watch
Triggered by event. New file in a folder, change detected. Reactive, without needless checking.
📥 Queue
Triggered by demand. Jobs go into a queue; the worker processes them one by one without losing any.
⌨️ Practical example: one task every 20 minutes
Objective: trigger a call to your local model every 20 min. We show two approaches — cron (official) and a bash loop (easier to test now).
How to check: run tail -f worker.log in another terminal—you should see a new model response every 20 min and the line "ciclo concluído". If nothing appears, check whether the local API is responding (curl http://localhost:11434/api/tags).
💡 Practical tip
The bash loop disappears when you close the terminal. For a true always-on setup, prefer the cron or a service (systemd on Linux, launchd on macOS): they survive logout and restart. Start by testing with the loop, then move to cron once it works.
🛡️ Worker reliability
An always-on agent runs without anyone watching — which is why it can't give you a headache. The difference between a useful worker and one that becomes a problem comes down to four habits: log everything, be idempotent, set limits, and know how to recover from a failure.
🆕 New here?
"Idempotency" is the property of being able to run the same thing multiple times without causing extra harm. A worker that processes the same item twice and is idempotent no duplicates the work or sends two identical alerts—it detects “this has already been done” and moves on. Crucial for something that runs over and over.
✓ Reliable worker
- ✓Logs: records what it did, when, and the result—you can audit it later
- ✓Idempotent: running it again on the same item doesn’t duplicate anything
- ✓Limits: timeout per run and item cap per cycle
- ✓Resume: saves where it left off and continues after a crash/restart
✗ A worker that causes headaches
- ✗Runs silently — when it fails, you don’t even know
- ✗Reprocesses everything and triggers the same alert 50 times
- ✗Gets stuck on a heavy item and holds up the entire queue
- ✗It crashes and starts over from scratch, losing progress
✅ Reliability checklist
- ▸Each cycle writes a log line with the date/time and what happened.
- ▸Before acting on an item, check “Have I processed this one already?” (hash, ID, marker).
- ▸Per-request model timeout and the maximum number of items per run.
- ▸State saved to disk (last item viewed) so you can pick up where you left off.
- ▸Alert only on what's new — silence when there’s nothing new.
💡 Practical tip
The simplest way to get idempotency: save a file with the IDs (or hashes) already processed and check against it at the start of each cycle. Skip what you've already seen, process only the new items, and append the new ID. Simple, on disk, and it solves 90% of duplicates.
👥 The employee fleet
One worker is an employee. Several workers, each on one task, are a fleet — and this is where the orchestrator from Module 4.1 reappears: it loads the models, routes between machines, and coordinates who does what. You stop having “an AI” and start having a quiet team working for you, for free, nonstop.
🎯 Your fleet in the upcoming lessons
- •4.3 — Security scanner: a worker that scans your codebase for secrets and vulnerabilities, 24/7.
- •4.4 — Web watcher: a worker that monitors sources and extracts ranked opportunities.
- •4.5 — Personal buddy: an always-available assistant with a name, face, and voice.
Notice: all three have the same anatomy of this module — scheduler, task, local model, and output. You already have the skeleton; the next lessons just add the substance.
🧭 How to think about the fleet
- One worker = one well-defined task. Don’t try to make one worker do everything.
- Workers share the same local API and the same tailnet (modules 3.5 and 2.4).
- The orchestrator (4.1) is optional at first: cron + scripts already make up a small fleet.
Self-check (optional): why does running a 24/7 agent usually only make financial sense with local AI?
📌 Module summary
Next module:
4.3 — 24/7 security scanner for your codebase