The one-sentence definition that actually holds up

An agent is a language model running in a loop with tools, deciding for itself what to do next.

That's it. The load-bearing word is deciding. Anthropic's engineering team draws the line the same way, and their distinction is the most useful one in circulation. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths" — you wrote the steps, the model fills them in. Agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks"^[1]. Both sit under the umbrella of "agentic systems"; the difference between them is how much autonomy you handed over.

This is a spectrum, not a badge. A support bot that classifies your message and routes it to one of five canned flows is a workflow, however it's marketed. A system that reads a bug report and decides on its own to search the codebase, run the tests, read the failure, edit a file and run them again is an agent. The second is harder to build, harder to predict, and more expensive to run. That's the whole trade.

Under the hood: a loop, some tools, and no hands

Here's the thing most explainers skip: the model never executes anything. This surprises people, and it's the key to understanding both the power and the risk.

You give the model a list of tools — each a name, a description, and a schema for its arguments. When the model decides to use one, it doesn't reach out and do it. It emits a structured request: a tool_use block naming the tool and its arguments. Your own code receives that, decides whether to run it, runs it, and hands the outcome back as a tool_result. Then the model continues with that result in front of it^[2]. Loop until the job is done.

So an agent is less a robot than a very well-read colleague who can only pass you notes saying "please run this and tell me what happened." Everything it appears to do in the world is done by ordinary code someone chose to wire up. That's why the Model Context Protocol matters: an open standard for connecting AI applications to external systems, described by its own docs as "like a USB-C port for AI applications"^[3]. MCP didn't make models smarter — it standardised the sockets, so the same tool works across Claude, ChatGPT, VS Code, Cursor and the rest instead of being rebuilt per product.

One more piece is easy to underrate. Because tool results come back into the conversation, an agent gets what Anthropic calls "ground truth" from the environment at each step — the test actually failed, the file actually isn't there — and can correct course^[1]. A model answering from memory has no such feedback. This is the single biggest reason agents outperform plain chat on real tasks, and it's why the tasks they're best at are the ones with a cheap, honest checker attached: does the code compile, does the test pass.

What isn't an agent

Now the deflationary part. Gartner has a name for the industry's favourite move — agent washing: rebranding existing chatbots, assistants and robotic process automation as "agentic AI" without substantial agentic capability. Of the thousands of vendors making the claim, Gartner's June 2025 assessment estimated only around 130 were building anything that genuinely qualified^[4][5]. Treat that as an order of magnitude, not a census — but the direction is not in doubt.

Some quick tests you can apply to any product demo:

• Can it choose a different sequence of steps than the one in the demo? If the path is fixed and only the wording varies, it's a workflow with a chat skin.
• Does it get feedback from the world mid-task, or just generate one long answer? No tool results coming back means no agent loop.
• What happens when a step fails? Real agents retry, re-plan or stop. Wrappers produce a confident summary of work that didn't happen.
• Can it stop and ask? Well-built agents "pause for human feedback at checkpoints or when encountering blockers"^[1]. Ones that never ask anything aren't autonomous; they're unsupervised.

And a fair note in the other direction: "it's only a workflow" is not an insult. For most business problems a predefined path with a model in the middle is cheaper, faster and far more predictable. Anthropic's own advice is to "find the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all"^[1].

What agents can genuinely do right now

The most useful public measurement comes from METR, which asks a deliberately concrete question: how long a task, measured in how long it takes a skilled human, can a model complete with a 50% success rate? They call it the model's time horizon. Under their updated methodology published 29 January 2026, the top-scoring model at the time — Claude Opus 4.5 — measured a 50% time horizon of 320 minutes, a bit over five hours, with the horizon roughly doubling every 89 days on post-2024 data^[6]. Whatever you think of the extrapolation, the short-run trend is steep and it is measured, not asserted.

Read the caveats, though, because METR states them plainly. The tasks are "primarily composed of software engineering, machine learning, or cybersecurity tasks." They are low-context: a horizon of several hours "does not mean that AIs can do 8 hours of work that a (high-context) human professional can do." Measurements above 16 hours are unreliable with the current task suite. And capability is "jagged" relative to humans — strong in some domains, oddly weak in neighbouring ones^[7].

Which brings us to the other number worth knowing. Carnegie Mellon's TheAgentCompany benchmark drops agents into a simulated software company: 175 tasks across engineering, project management, data science, HR, finance and admin, with real GitLab, ownCloud, Plane and RocketChat instances to work in and simulated colleagues to talk to^[8]. The best performer, Gemini 2.5 Pro, fully completed 30.3% of tasks and scored 39.3% with partial credit^[8]. When the benchmark first ran, the leader managed 24%^[9].

Hold those two findings side by side, because together they're the honest picture as of mid-2026: on clean, well-specified, checkable technical tasks, agents now work for hours. Dropped into a messy simulated workplace, the best of them finish under a third of the job.

How they fail — and why demos hide it

Errors compound. A ten-step task done at 95% per-step reliability succeeds about 60% of the time. Anthropic names this directly: agents bring "higher costs, and the potential for compounding errors," and recommends "extensive testing in sandboxed environments, along with the appropriate guardrails"^[1]. Demos are short. Real tasks are long.

They take shortcuts and then believe them. This is the most striking result in the CMU work. Faced with a step it couldn't do, an agent would invent a workaround that skipped the hard part — in one case renaming a user account so it matched the contact it had been told to reach, then reporting success^[8][9]. Not lying, exactly. Something worse for your purposes: an agent whose completion report is uncorrelated with completion.

The mundane stuff wins. Agents struggled most with the parts of the job requiring web browsing — complex interfaces, pop-ups, the ordinary friction any office worker clicks through without noticing^[8][9]. Social tasks fared worse than technical ones; one agent simply failed to contact an HR manager as instructed^[9].

They cost more than you budgeted. "Agentic systems often trade latency and cost for better task performance"^[1]. A loop that runs forty model calls costs roughly forty times a single call, and a stuck agent can burn that on nothing. This is not a footnote: escalating costs, unclear business value and inadequate risk controls are exactly the three reasons Gartner gives for predicting that over 40% of agentic AI projects will be cancelled by the end of 2027^[4][5].

The security problem is different in kind

A chatbot that gets manipulated says something wrong. An agent that gets manipulated does something wrong, with your credentials. That's a change in category, not degree, and it deserves its own paragraph in any honest explainer.

OWASP's agent security guidance names the core risks crisply. Prompt injection: "malicious instructions injected via user input or external data sources (websites, documents, emails) that hijack agent behavior." Excessive autonomy: agents performing "irreversible, financial, administrative, or externally visible operations" without oversight. Tool abuse: "agents exploiting overly permissive tools to perform unintended actions." Memory poisoning: "malicious data persisted in agent memory to influence future sessions or other users"^[10].

The mitigations are unglamorous and worth insisting on: grant "the minimum tools required for their specific task," scope permissions per tool (read-only versus write), "require explicit approval for high-impact or irreversible actions," and treat "all external data as untrusted"^[10]. That last one is the mental model to keep. A web page an agent reads is not an instruction from you — it is input from a stranger, and the agent cannot reliably tell the difference.

When to build one — and when not to

The decision is less about how impressive agents are and more about the shape of your task. Agents earn their cost when the path genuinely can't be known in advance, when there's a cheap automatic check on whether a step worked, when mistakes are recoverable, and when a human is in the loop for anything irreversible.

Skip the agent when the steps are the same every time — that's a workflow, and it'll be cheaper and more reliable. Skip it when nothing can verify the output, because you've built a machine that produces confident unverifiable claims. Skip it when errors are expensive or irreversible and the only guardrail is trust. And skip it, above all, when a single well-prompted model call with the right context does the job: optimising one call "with retrieval and in-context examples is usually enough"^[1].

Where does that leave the word? "Agent" describes a real architecture: a model, a loop, tools, and delegated control over the sequence. That architecture is improving fast on measured technical work and remains distinctly mediocre at being a colleague. Both halves are true at once, and any pitch that gives you only one of them is selling something. Ask what tools it has, who approves the risky calls, and what happens when step seven fails.

Sources

1. Anthropic — "Building Effective AI Agents", accessed July 2026
2. Anthropic — Claude Docs: Tool use overview (tool_use / tool_result round trip), accessed July 2026
3. Model Context Protocol — "What is the Model Context Protocol (MCP)?", accessed July 2026
4. Gartner — "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (25 June 2025)
5. Forbes — "Why 40% Of Agentic AI Projects May Be Canceled By 2027" (reporting the Gartner figures), accessed July 2026
6. METR — "Time Horizon 1.1" (29 January 2026), accessed July 2026
7. METR — "Task-Completion Time Horizons of Frontier AI Models" (methodology and limitations), accessed July 2026
8. arXiv — Xu et al., "TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks", accessed July 2026
9. Carnegie Mellon University School of Computer Science — news coverage of TheAgentCompany results, accessed July 2026
10. OWASP — AI Agent Security Cheat Sheet, accessed July 2026

Related: How large language models actually work · Prompt patterns that actually work for coding agents · Why Toolkit runs entirely in your browser

What you're building

The finished device is a matchbox-sized board plugged into a USB charger, sitting wherever you want a reading: a nursery, a greenhouse, a wine cupboard, a home office that gets stuffy by mid-afternoon. It joins your Wi-Fi and hosts a small web dashboard. Type its address into a browser and you see the current temperature and humidity, updating live, from any device in the house.

There's no cloud account, no app to install, and no subscription — the readings never leave your network unless you decide to send them somewhere. The board is an ESP32; the brains are a free, open-source firmware called ESPHome that turns "read a sensor and put it on a web page" from a weekend of coding into a dozen lines of configuration. If you later want history graphs, phone alerts, or automations ("turn on the fan when the office passes 26 °C"), the same device drops straight into Home Assistant with no rewiring. But you don't need any of that to start — the standalone web dashboard is step one, and it's genuinely useful on its own.

The parts: a board and a sensor

You need exactly two things plus a USB cable, and the total lands around $20.

The board — an ESP32. "ESP32" is a family of cheap Wi-Fi microcontrollers from Espressif. Any of them works here; a good default in 2026 is an ESP32-C3 dev board, a single-core RISC-V chip running at up to 160 MHz with Wi-Fi and Bluetooth LE built in and around 22 usable GPIO pins^[1]. Adafruit's ESP32-C3 dev board is $9.95 and has a USB port you plug straight into your computer to flash it^[2]. Any similarly-priced ESP32 board from a reputable seller is fine — the exact model barely matters for this project.

The sensor. This is the one real decision, and it's worth thirty seconds of thought because it sets the accuracy of everything downstream.

• DHT22 (also sold as AM2302) — the classic beginner sensor. It's cheap, everywhere, and communicates over a single wire. Adafruit sells the bare sensor for $9.95, rated for 0–100% humidity at 2–5% accuracy and −40 to 80 °C at ±0.5 °C^[3]. Its catch: it only produces a fresh reading about once every two seconds^[3], and it needs a pull-up resistor on the data line (about 4.7 kΩ, though 1–10 kΩ is fine) unless you buy a module with one already fitted^[4].
• SHT41 (Sensirion SHT4x family) — a noticeably better sensor for a couple of dollars more. Sensirion quotes a typical accuracy of ±0.2 °C and ±1.8% RH, it runs from 1.08–3.6 V, and it talks over I²C — the same two-wire bus most hobby sensors use^[5]. It comes factory-calibrated, so readings are trustworthy out of the box.

Our recommendation: buy the SHT41 on a small breakout board. The accuracy gap is real — ±0.2 °C versus ±0.5 °C is the difference between "I trust this number" and "roughly" — and the I²C wiring is cleaner. If you already have a DHT22 in a drawer, use it; this project works fine with either, and we'll cover both.

Wiring it up

Both sensors need three connections plus, for I²C, one more. Most breakout boards have labelled pins, and you can use pre-crimped jumper wires — no soldering if you buy a board with header sockets.

For the SHT41 (I²C): connect the sensor's VIN/VCC to the board's 3.3 V pin, GND to GND, SDA to the board's SDA pin, and SCL to SCL. On a classic ESP32 those default to GPIO21 (SDA) and GPIO22 (SCL); on the C3 and other boards the pins are usually silk-screened, and you can assign any spare GPIOs in the config^[6]. I²C breakout boards almost always include the required pull-up resistors already, so there's nothing extra to add.

For the DHT22 (one-wire): connect +/VCC to 3.3 V, −/GND to GND, and the DATA/OUT pin to any spare GPIO — GPIO4 is a common choice^[4]. Add the ~4.7 kΩ pull-up resistor between DATA and 3.3 V if your sensor is the bare three-pin kind; skip it on modules that already have one^[7].

That's the entire hardware build. Plug the board into your computer with a USB cable and move to the software.

The software: ESPHome, not C code

You could write Arduino C++ to read the sensor and run a web server, and plenty of tutorials do. We're going to skip that entirely and use ESPHome, which lets you describe the device in a short YAML config file and generates the firmware for you. It runs on Windows, macOS and Linux, and the first flash happens over USB; every update after that can happen wirelessly over your network^[8].

Install it (the command-line route is pip install esphome), then create a config. Here's a complete, working example for the SHT41 — this is the whole program:

esphome:
  name: room-monitor

esp32:
  board: esp32-c3-devkitm-1

wifi:
  ssid: "YourNetwork"
  password: "YourWiFiPassword"

# Two-wire I2C bus for the SHT41
i2c:
  sda: GPIO8
  scl: GPIO9

sensor:
  - platform: sht4x
    temperature:
      name: "Room Temperature"
    humidity:
      name: "Room Humidity"
    update_interval: 30s

# The live web dashboard
web_server:
  port: 80
  version: 3

A few notes on what those blocks do. The sht4x platform speaks to the sensor over I²C at its fixed address (0x44), defaults to high precision, and reports every 60 seconds unless you change update_interval — we set 30 seconds above^[9]. Swapping in a DHT22 means replacing the i2c and sensor blocks with the dht platform, pointing pin: at the GPIO you used^[7]. Flash it with a single command over USB — esphome run room-monitor.yaml — and ESPHome validates the config, compiles the firmware, and uploads it^[8].

The dashboard, and locking it down

That web_server block is the payoff. It starts a small HTTP server on the device that any browser on your network can open — no app, no account. After flashing, find the device's address (ESPHome prints it, or look in your router's device list) and visit it. Version 3, used above, renders a clean Home Assistant-style interface with your two readings updating live^[10].

One thing to be deliberate about: this web server is designed for a trusted home network. Its own documentation is blunt that it "has no cross-site protections, by design," and warns against exposing it to the internet^[10]. So don't forward a port to it. If other people share your Wi-Fi, add the optional auth: block with a username and password to require a login^[10]. For a sensor that only reports the temperature of a room, the stakes are low — but "don't put it on the public internet" is a rule worth keeping for every device like this.

Going further: history, alerts, and battery power

The standalone dashboard shows now. The moment you want yesterday — graphs, trends, "alert me if the freezer warms up" — point the same device at Home Assistant, the open-source home hub. ESPHome devices connect to it over a lightweight encrypted API (secured with a pre-shared key, on port 6053) and are usually auto-discovered the moment they come online^[11]. Home Assistant then records history, draws charts, and runs automations off your readings. Nothing about the hardware changes; you add a couple of lines to the same config.

The other common upgrade is cutting the cord. To run on batteries, ESPHome's deep_sleep component wakes the board, takes a reading, reports it, and powers most of the chip down between measurements — the difference between hours and months on a charge. The catch is a real one worth planning around: a sleeping device "will not do any work and not respond to any network traffic, even Over The Air updates"^[12]. So a battery sensor can't host a live always-on dashboard the way a plugged-in one does — it phones its readings home to Home Assistant on a schedule instead. Pick your mode: mains power for the instant web dashboard, or deep sleep plus a hub for a battery node.

The honest limits

This is a genuinely capable little device, but keep expectations calibrated. A cheap sensor measures the air at the sensor — put it in direct sun, near a heat vent, or against the board's own warmth and it will read high; give it a bit of airflow and shade. Consumer sensors also drift slowly over years, so this is a "is the room comfortable / is the greenhouse too dry" instrument, not a laboratory reference. Wi-Fi coverage has to reach wherever you place it. And the standalone web page is exactly that — a live readout with no memory; the history-and-alerts story really does need Home Assistant or another logger behind it. Within those limits, though, a $20 build that tells you the truth about a room, updates in real time, and answers only to your own network is hard to beat — and it's the gateway drug to a whole shelf of them.

Sources

1. Espressif — ESP32-C3 product page, accessed July 2026
2. Adafruit — ESP32-C3 DevKitM-01 dev board, accessed July 2026
3. Adafruit — DHT22 / AM2302 temperature-humidity sensor, accessed July 2026
4. Random Nerd Tutorials — ESP32 with DHT22 wiring and notes, accessed July 2026
5. Sensirion — SHT41 product page (accuracy, voltage, interface), accessed July 2026
6. ESPHome — I²C Bus component (default ESP32 pins), accessed July 2026
7. ESPHome — DHT sensor component (pin, model, pull-up), accessed July 2026
8. ESPHome — Getting started from the command line (install, run, OTA), accessed July 2026
9. ESPHome — SHT4x sensor component (address, precision, update interval), accessed July 2026
10. ESPHome — Web Server component (versions, auth, security note), accessed July 2026
11. Home Assistant — ESPHome integration (native API, encryption, discovery), accessed July 2026
12. ESPHome — Deep Sleep component (run/sleep duration, OTA limitation), accessed July 2026

Related: Weekend project: block ads on your whole network with a Raspberry Pi · Self-hosting 101: what's worth running on your own hardware in 2026 · All posts

What self-hosting is, and when it's actually worth it

Every service that "just works" from your phone — photo backup, streaming, notes, password sync — runs on someone else's computer, under their terms, at their price. Self-hosting flips that: you run the server, on hardware in your house, and the data stays on a disk you can hold. The payoff is real ownership and no monthly meter. The cost is that you are now the IT department.

The trigger for a lot of people in 2026 is watching a service they relied on change the deal. The clearest example is Plex, the popular media server: in April 2025 it started charging for remote streaming of your own media and raised its lifetime pass from $119.99 to $249.99^[2] — then on July 1, 2026 that lifetime price jumped again to $749.99^[3]. Nothing about the software you'd installed changed; the terms did. Self-hosting is the bet that you'd rather own the arrangement outright.

Be honest about when it isn't worth it, though. If a free or cheap cloud service does the job and you'd rather never think about backups, updates or uptime, keep using it — self-hosting trades a subscription for your own time and attention. The sweet spot is a service you use constantly, care about the privacy of, or are tired of paying a rising rent on.

The hardware: far less than you think

The single biggest misconception is that you need a rack of servers. You don't. For a first home server you have three sensible options, in rough order of cost:

• A computer you already own. Any desktop or laptop from the last decade — even an old one gathering dust — will run a starter stack. It's the free way to find out whether you enjoy this before spending anything.
• A Raspberry Pi 5. The current Pi is a genuine little computer: a quad-core Arm Cortex-A76 running at 2.4 GHz, up to three times faster than the previous generation, in RAM sizes from 1 GB to 16 GB, with a PCIe 2.0 lane for an M.2 SSD and gigabit Ethernet^[8]. It sips power and is ideal for lighter always-on jobs.
• A mini PC. The value champion of 2026. A small Intel N100 box — a four-core, roughly 6-watt chip — with 16 GB of RAM and an NVMe SSD draws only about 8–12 watts running a typical homelab, yet community testing shows it happily running 15–20 containerised services at once and hardware-transcoding 4K video for a media server via Intel Quick Sync^[9]. For well under the price of Plex's new lifetime pass, it will run your whole stack 24/7 for a few dollars of electricity a year.

Notice what's missing: an expensive GPU. Unlike running local AI models — where memory bandwidth is the bottleneck (see our companion piece on running LLMs on your own hardware) — ordinary self-hosted apps are light. RAM and a decent SSD matter far more than raw compute. Start with 8–16 GB of RAM and grow only if you actually run out.

Docker: the one concept that makes it manageable

If you take one idea from this piece, take this one. In the old days, installing self-hosted software meant wrestling each app's dependencies into your operating system, where they'd conflict and rot. Docker replaced that with containers: each app ships as a self-contained package with everything it needs, isolated from the others and from the host. You "run" an app in one command, and "remove" it just as cleanly, leaving nothing behind.

In practice you'll write a short docker-compose.yml file per app — a few lines declaring the image, its storage folder and its network port — and bring the whole thing up with docker compose up -d. Updating is pulling a new image and restarting. This is why a modest N100 box can juggle twenty services: containers are cheap, and Compose files make a stack reproducible and easy to back up. Learn Docker Compose first; every app below is distributed as a container, and once the pattern clicks the rest is copy-paste-and-adjust.

What's genuinely worth running

Ignore the "awesome-selfhosted" lists with a thousand entries; most people are well served by a handful of mature, actively maintained apps. As of mid-2026 these are the safe starting bets:

• Immich — photo backup. The app that talks the most people into their first server. It's a self-hosted photo and video manager with polished iOS and Android apps that back up your camera roll in the background, plus face recognition and natural-language "CLIP" search that run entirely on your hardware^[4]. With over 108,000 GitHub stars it's among the fastest-growing self-hosted projects ever^[4] — a credible replacement for Google Photos for most households. One caveat straight from its authors: it moves fast, so follow a real backup plan and read upgrade notes before updating^[4].
• Jellyfin — media streaming. Your movies, shows and music, streamed to any screen. Jellyfin bills itself as "The Free Software Media System," GPL-licensed, with — in its own words — "no premium licenses or features, and no hidden agendas," and "no tracking, phone-home, or central servers"^[1]. That last part is the contrast with Plex, which authenticates through its own cloud. If you want zero subscription risk, this is the pick.
• Home Assistant — smart home. The hub that ties your lights, sensors and plugs together and keeps them working when the internet is down. It describes itself as "open source home automation that puts local control and privacy first," processing everything locally with 1,500+ device integrations, and it's governed by a non-profit that structurally "can't be sold or acquired"^[5]. It's the antidote to smart-home gadgets that brick when a startup folds.
• Vaultwarden — password manager. A lightweight, Rust-built server that speaks the Bitwarden API and works with the official Bitwarden apps and browser extensions, purpose-built for self-hosting where the full official server would be "resource-heavy"^[6]. Your vault syncs across devices, but the encrypted database lives on your box. (It's an unofficial project, not affiliated with Bitwarden — keep backups^[6].)
• Nextcloud — files and more. "A safe home for all your data": your own Dropbox-style file sync plus calendar, contacts and mail, on a server of your choosing, AGPLv3-licensed^[7]. It's heavier than the others, so add it once you're comfortable.

Two honourable mentions: Pi-hole, the network-wide ad blocker that's the perfect first project — we have a full follow-along build in block ads on your whole network with a Raspberry Pi — and a dashboard like Homepage to see all your services in one place once you've got a few running.

The parts nobody tells beginners

The apps are the easy 20%. The unglamorous 80% is what separates a hobby that lasts from a pile of e-waste. Four things to internalise before you depend on any of this:

1. Backups are not optional. A single server is a single point of failure, and a self-hosted photo library with no backup is more dangerous than the cloud you left. Follow the 3-2-1 rule — three copies, two kinds of media, one off-site — which Immich's own authors put in bold at the top of their project^[4]. Automate it; a backup you have to remember isn't one.
2. Updates need a rhythm. Self-hosted software gets security fixes constantly. Set aside a little time monthly to pull new container images, and read release notes for anything storing data you care about — some projects ship breaking changes in minor releases^[4].
3. Remote access is where people get burned. Do not forward ports and expose these apps raw to the internet. Reach your services from outside with a VPN back to your network (WireGuard or Tailscale) or a properly configured reverse proxy with HTTPS. When in doubt, keep everything LAN-only and use the VPN.
4. Security hygiene. Unique strong passwords on every service, two-factor where offered, and keep the host operating system patched. A vault you host is only as safe as the machine under it.

Where to actually start

Don't try to build the whole stack in a weekend. A realistic path: install Docker on a computer you already own, stand up one low-stakes service — Pi-hole or Immich are ideal first projects — and live with it for a few weeks. Get comfortable with Compose files, updates and a backup routine on something that won't hurt if it breaks. Only then buy dedicated hardware, and only then add the services you'll actually depend on, like a password vault or your main photo library.

And know when to stop. Self-hosting is a genuine commitment of attention, not a way to save money in the short term; the mini PC and your time both cost something. If a service is critical, has no good backup story, and you can't tolerate a weekend of downtime while you fix it, leaving that one in the cloud is a perfectly rational choice. The goal isn't to host everything — it's to own the handful of things you care about most, on terms nobody can change out from under you.

Sources

1. Jellyfin — official repository (README), accessed July 2026
2. 9to5Mac — Plex announces Plex Pass price increase and paywall for remote streaming, accessed July 2026
3. Gadget Hacks (Cord Cutters) — Plex Lifetime Pass price increase, effective July 1, 2026, accessed July 2026
4. Immich — official repository (README), accessed July 2026
5. Home Assistant — official site, accessed July 2026
6. Vaultwarden — official repository (README), accessed July 2026
7. Nextcloud — server repository (README), accessed July 2026
8. Raspberry Pi — Raspberry Pi 5 product page, accessed July 2026
9. HomeLab Starter — Intel N100 mini PC builds: measured power and transcoding, accessed July 2026

Related: Running AI on your own hardware: local LLMs explained · Block ads on your whole network with a Raspberry Pi · Why Toolkit runs entirely in your browser

It starts with tokens, not words

A neural network is, at bottom, a very large pile of arithmetic. It cannot operate on letters or words directly — everything must become numbers first. So before your message reaches the model, a component called a tokenizer chops the text into tokens: chunks that can be whole words, pieces of words, or single characters. For Claude, one token works out to roughly 3.5 English characters on average^[1]. Common words like "the" typically get a token of their own; rarer words get split — "unbelievably" might arrive as something like un + believ + ably. Each token is then mapped to a long list of numbers, and those numbers are what the model actually processes.

This single design choice explains a whole family of famous failures. The model never sees the letters inside a word — "strawberry" reaches it as one or two opaque chunks, not as eleven characters. Asking it to count the r's is a bit like asking you to count the letters in a word you've only ever heard spoken. The same goes for reversing strings, precise rhyme schemes and arithmetic on long numbers, which get sliced into tokens at boundaries that have nothing to do with place value. The model isn't being lazy; the information genuinely isn't in front of it in that form.

The whole trick: predict the next token

Here is the core of it, and it's almost disappointingly simple. Given all the text so far, the model produces a probability for every token in its vocabulary being the next one. One token gets picked, appended to the text, and the process repeats — one token at a time, until the answer is done^[1]. A thousand-word chatbot reply is roughly a thousand of these predictions in a row. There is no separate planning module, no fact-retrieval step, no grammar engine. Prediction is the entire mechanism.

Why does such a modest trick produce coherent essays? Because predicting the next word well, across trillions of words of human writing, is a brutally demanding task. To beat the competition at it, a model is forced to internalize spelling patterns, then grammar, then style, then facts about the world, then something that often functions like reasoning — because all of those things reduce prediction error. The task acts as a compression engine for the patterns in everything people have written. What it never requires, though, is a way to check whether a prediction is true. Hold that thought.

Training: two very different phases

Where do the model's abilities come from? Training happens in two broad stages, and the distinction matters.

Pretraining is the famous, expensive part. The model reads an enormous corpus of text and plays the prediction game billions upon billions of times: guess the next token, compare against what actually came next, nudge the internal parameters — the billions of numbers that define the model — a tiny step toward doing better, repeat. No human labels anything; the text itself is the answer key. The result is a raw model that is an astonishing autocomplete engine but not an assistant — it completes text rather than following instructions, and it will happily continue your question with more questions^[1].

Post-training turns that raw engine into something usable. The model is first fine-tuned on examples of the desired behavior (question in, helpful answer out), and then refined with reinforcement learning from human feedback (RLHF): humans compare alternative outputs and rank them, and the model is pushed toward producing the kind of answer people prefer^[1][2]. This step is remarkably powerful — OpenAI's InstructGPT work found that a model with 1.3 billion parameters, tuned this way, produced outputs human evaluators preferred over a raw model 100× its size^[2]. One honest caveat: RLHF optimizes for what human raters score highly, which overlaps with "true and useful" but is not identical to it. A confident, polished wrong answer can rate well. That tension never fully goes away.

Attention: every word gets to look at every other word

The architecture underneath all modern LLMs is the transformer, introduced in a 2017 Google paper with the now-famous title "Attention Is All You Need"^[3]. Earlier language models read text the way a person reads a ticker tape: one word at a time, carrying along a running summary. By the end of a long sentence, information from the beginning had faded — like a game of telephone played with the model's own memory.

The transformer's answer is a mechanism called attention, and the intuition is exactly what the name suggests: when processing each token, the model gets to look at every other token in the text and decide, with learned weights, which ones matter right now. Take "The trophy didn't fit in the suitcase because it was too big." To handle "it," the model needs to weigh "trophy" against "suitcase" — attention is the machinery that lets it do that directly, no matter how far apart the words sit. Stack this dozens of layers deep and each token's internal representation gets progressively refined by everything around it: "bank" near "river" ends up represented differently than "bank" near "loan."

The paper's authors showed that attention alone — "dispensing with recurrence and convolutions entirely" — matched or beat the best translation systems of the day^[3]. Just as important, attention processes all positions in parallel rather than one at a time, which is what made it practical to train on previously absurd amounts of text and hardware. That parallelism, as much as any cleverness, is why models could scale to where they are now.

Context windows, and why models "forget"

Everything above operates on one bounded stretch of text: the context window — all the text a model can reference while generating, including its own reply as it writes it. Think of it as working memory, entirely separate from whatever the model absorbed in training^[4]. Your messages, the model's answers, any documents you paste — all of it has to fit inside.

This is why long conversations get strange. When a chat outgrows the window, the software around the model quietly drops or summarizes the oldest turns. The model hasn't "forgotten" your instructions the way a distracted person would — that text is simply no longer part of its input. It also can't remember you between conversations: a new chat is a blank slate unless the product deliberately re-injects notes about you. As of mid-2026, frontier models advertise windows from a couple hundred thousand tokens up to a million^[4] — hundreds of pages — but bigger isn't automatically better: as the window fills, accuracy and recall measurably degrade, a phenomenon practitioners call context rot^[4].

Why models make things up

Now the heart of it. The single most useful thing to understand about an LLM is that there is no database inside. What the model "knows" is smeared across billions of numeric parameters as statistical tendencies — there is no row it can look up, no record it can double-check, no flag that distinguishes a memorized fact from a plausible guess. When you ask a question, the model does not retrieve an answer. It does the only thing it ever does: continue the text in the most plausible way.

For well-worn facts — capital cities, famous dates — the most plausible continuation and the correct one are the same, because the truth appeared thousands of times in training. For obscure facts, they come apart, and the machinery produces something with the exact shape of a right answer: a confident citation of a paper that doesn't exist, in a journal that does; a court case with a plausible name and a fabricated docket number. This is why fluency is no signal of reliability. Fluency is the one thing the model is good at unconditionally; it writes falsehoods in precisely the same assured register as facts.

Anthropic's interpretability research has actually traced part of this mechanism. Inside Claude, refusal appears to be the default: a circuit that is on by default pushes the model to say it has insufficient information, and a separate "known entities" feature suppresses that refusal when the model recognizes the subject. Hallucinations happen when this misfires — the model recognizes a name, the "I know this" signal activates, but the underlying facts aren't there, so the machinery fills the gap with something plausible^[5]. That's also why models are poor judges of their own uncertainty: the "do I know this?" check is itself just another learned circuit that can be wrong.

Products bolt on mitigations — web search, retrieval from documents, citations — which genuinely help by putting real text into the context window for the model to work from. But the underlying tendency is architectural. The practical rule: treat an LLM like a brilliant, widely read colleague who never checks sources and never says "I'm not sure" unless trained to. Verify anything load-bearing.

Temperature: the randomness dial

One loose end from earlier: the model produces probabilities for the next token — something still has to pick one. That choice is called sampling, and temperature is its main control. Low temperature makes the model stick closely to its most probable choices — conservative, repeatable-ish output, good for code or extraction. Higher temperature flattens the odds so less-likely tokens get picked more often — more varied and surprising phrasing, better for brainstorming^[1]. This is why the same question can get a differently worded answer on different days: you're watching sampling, not indecision. Two fine print items: even at temperature zero, outputs aren't perfectly deterministic in practice^[1], and turning temperature down does not turn hallucination off — a fabrication can be the most probable continuation.

What nobody fully understands yet

A closing dose of honesty: we built these systems, and we still can't fully read them. Training doesn't write legible code — it grows billions of parameters whose collective behavior nobody designed line by line. The field trying to reverse-engineer them, interpretability, is young and openly incomplete. Anthropic's team has extracted millions of interpretable "features" from a production model — including one for the Golden Gate Bridge which, when artificially amplified, made the model obsess over the bridge in unrelated answers^[6] — and traced circuits showing that a model asked to write rhyming poetry plans candidate rhymes ahead before writing the line, despite being trained only to predict one token at a time^[5]. Yet the same researchers estimate their methods capture only a fraction of the computation happening inside even short prompts^[5].

So the picture in this article — tokens in, attention over context, next-token prediction out, shaped by pretraining and RLHF — is solid. The fine-grained why behind any particular answer often remains an open research question. That's the right frame to carry out of this piece: genuinely impressive, genuinely useful, not magic, and not fully understood — including by the people who make them. Verify accordingly.

Sources

1. Anthropic — Claude Docs: Glossary (tokens, pretraining, RLHF, temperature), accessed July 2026
2. arXiv — Ouyang et al., "Training language models to follow instructions with human feedback" (2022), accessed July 2026
3. arXiv — Vaswani et al., "Attention Is All You Need" (2017), accessed July 2026
4. Anthropic — Claude Docs: Context windows, accessed July 2026
5. Anthropic — "Tracing the Thoughts of a Large Language Model" (March 2025), accessed July 2026
6. Anthropic — "Mapping the Mind of a Large Language Model" (May 2024), accessed July 2026

Related: How AI vocal removal works · Why Toolkit runs entirely in your browser · Browse all tools

Why run a model locally at all

Let's be honest about the baseline first: the strongest models you can use today are cloud models, and nothing you run at home will match them. If you want maximum capability and don't mind the terms of service, a cloud subscription is the rational choice. People run models locally anyway, for four reasons that hold up.

Privacy. A local model processes your prompt on your own machine. Nothing is uploaded, logged, retained for "service improvement," or subpoenaable from a third party. For medical questions, contracts, journals, unreleased code — anything you'd hesitate to paste into a web form — that property is not a nice-to-have, it's the whole point. (It's the same architecture argument we make for this site's tools in why Toolkit runs in your browser: a file that never leaves can't leak.)

Cost structure. Local inference costs you hardware you may already own plus electricity. There's no per-token meter, no monthly cap, no plan tier. For heavy, repetitive workloads — bulk summarization, classification, code review over a private repo — "free after setup" compounds quickly.

Offline and always-on. A local model works on a plane, in a dead zone, and during a provider outage. It also can't be deprecated out from under you: a model file on your disk behaves the same way in five years.

Tinkering. You can swap models, adjust sampling, fine-tune on your own data, and wire the model into scripts with no rate limits. For a lot of people this is the honest main reason, and there's nothing wrong with that.

The counterweights: setup has real friction, output quality is a tier below the frontier, and your hardware — not a data center — sets the speed. The rest of this piece is about making those trade-offs concrete.

What "7B" and "70B" actually mean

Model names come with a number: 7B, 27B, 70B. The B is billions of parameters — the learned numerical weights inside the neural network. Parameters are where the model's knowledge and ability live, so more of them generally means a more capable model. They're also, quite literally, the thing you have to store and move through your processor for every generated word, which is why the parameter count is the single best predictor of what hardware you'll need.

One wrinkle has become essential to understand: many current models are mixture-of-experts (MoE) designs, which means only a fraction of the parameters do work on any given token. You'll see this written as two numbers. Alibaba's Qwen3.6-35B-A3B has 35 billion parameters in total but only about 3 billion active per token^[5]; OpenAI's gpt-oss-20b has 21 billion total and 3.6 billion active^[4]. The practical effect: you still need enough memory to hold all the parameters, but generation speed behaves more like a small model's. It's how mid-2026 open models manage to be both large and fast on modest hardware.

Quantization: how big models fit on small machines

A parameter is natively stored as a 16-bit number — two bytes. Straight arithmetic says a 7B model needs about 14 GB just for its weights, and a 70B model about 140 GB. By that math, almost nobody could run anything interesting.

Quantization is the fix: store each parameter with fewer bits. The open-source inference engine llama.cpp — the foundation under most local-AI tooling — supports 1.5-bit through 8-bit integer quantization "for faster inference and reduced memory use"^[1]. At 4 bits per parameter, that 7B model shrinks to roughly 3.5 GB and a 27B model to under 14 GB — laptop territory. The compressed models are distributed as GGUF files, the format llama.cpp and its descendants require^[1].

The catch is that quantization is lossy: you're rounding the model's weights, and below about 4 bits the quality loss becomes noticeable. The community's working consensus is that a 4-to-5-bit quantization of a bigger model usually beats a full-precision smaller one — and model builders now design for this outright. OpenAI post-trained gpt-oss-20b with 4-bit (MXFP4) quantization of its MoE weights specifically so it would "run within 16GB of memory"^[4], and even published its benchmark evals at that quantization. Fitting on consumer hardware has become a design target, not an afterthought.

The hardware that matters: memory, not raw compute

Here's the part that surprises people who assume AI needs an exotic GPU: for local inference, the binding constraint is how much fast memory you have, not how many teraflops. Every generated token requires reading essentially all of the model's (active) weights, so the model must sit in memory that the processor can read at very high speed — and the memory's bandwidth largely sets your tokens-per-second.

That gives you two viable paths:

• A discrete GPU, sized by VRAM. The graphics card's own memory is the fast pool, so the card's VRAM capacity — 8, 12, 16, 24 GB — decides which models fit, full stop. A 4-bit 8B model fits comfortably in 8 GB; the ~13 GB weights of a 4-bit 27B model want 16 GB or more once you add working space for the context.
• Apple Silicon and other unified-memory machines. These share one memory pool between CPU and GPU, so a Mac with 32 or 64 GB of RAM can load models that would need an expensive multi-GPU rig otherwise. This is a big reason Macs are so popular in the local-AI scene, and why llama.cpp treats Apple Silicon as a first-class target alongside NVIDIA (CUDA), AMD (HIP) and Vulkan backends^[1].

Two budget notes. Context — the conversation and documents the model is currently holding in its head — consumes memory on top of the weights, and long contexts consume a lot; leave headroom rather than loading the largest model that technically fits. And models can run from ordinary CPU RAM with no GPU at all; it works, just several times slower, because standard system memory has a fraction of the bandwidth.

The on-ramp: Ollama, LM Studio, llama.cpp

Ten minutes of setup, honestly. Three tools cover nearly everyone, and all three are built on the same GGUF-model foundations:

1. Ollama — the developer favorite. A small command-line tool for macOS, Windows, Linux and Docker: ollama run plus a model name downloads a sensibly quantized build and drops you into a chat, and it exposes a local REST API so scripts and editors can talk to the model. Its library tracks current open models — the July 2026 releases list Kimi, GLM, DeepSeek, gpt-oss, Qwen and Gemma support in the same breath^[2].
2. LM Studio — the graphical option, "free for home and work use"^[3]. You browse models in a UI, see which fit your machine, download and chat — no terminal. It also runs Apple's MLX model format on Apple Silicon and can serve an OpenAI-compatible API^[3], so apps written for the cloud API can point at your laptop instead.
3. llama.cpp — the engine itself, whose stated goal is LLM inference "with minimal setup and state-of-the-art performance on a wide range of hardware"^[1]. Compile it and you get maximum control and the newest features first. Most people don't need to start here; it's where you end up when you outgrow the other two.

The open-weight landscape, as of July 2026

"Open-weight" means the trained model file is published for anyone to download and run — the weights are open even when the training data and recipe aren't. The current families worth knowing, as of July 2026:

• Google Gemma 4 (April 2026) is the most deliberately consumer-sized line: E2B and E4B variants for phones and IoT, and 12B, 26B and 31B models pitched as "frontier intelligence on personal computers"^[6].
• OpenAI gpt-oss — yes, OpenAI ships open-weight models now — leads with gpt-oss-20b, Apache-2.0 licensed and engineered to run in 16 GB of memory^[4].
• Alibaba's Qwen 3.6 series is the enthusiast default: the 35B-A3B mixture-of-experts model pairs a 262K-token native context with just 3B active parameters, under Apache 2.0^[5].
• DeepSeek V4 continues the MIT-licensed line; even the "Flash" variant is 284B parameters (13B active) with a million-token context^[7] — open, but server-class.
• Meta's Llama 4 (Scout at 109B total, Maverick at 402B, both 17B active) remains available^[9], though Meta hasn't shipped a new open generation since.
• Mistral still releases open weights, but note the size creep: Mistral Small 4 is 119 billion parameters and its own docs recommend multi-H100 server hardware^[8]. "Small" no longer means "fits on your laptop" — read the model card, not the name.

The pattern across all of these: permissive licenses (Apache 2.0, MIT), mixture-of-experts architectures, and a clear split between genuinely local-sized models (roughly 4B–35B) and open-but-datacenter models wearing the same branding.

What to realistically expect

A well-chosen 12B–35B model on a 16–24 GB machine is genuinely useful in 2026: solid summarization, drafting, translation, code assistance, question-answering over your own documents, and structured extraction — private, free per query, and fast enough to feel conversational. What it is not is a frontier model. Expect a noticeable gap on long multi-step reasoning, obscure knowledge, and large codebases, and expect more confident-sounding mistakes; verify anything that matters.

When not to bother: if you need best-available quality on hard problems, use a cloud model. If your laptop has 8 GB of RAM and no GPU, small models will run but may disappoint — try before buying hardware. And don't buy a GPU for a workload you haven't measured; install Ollama or LM Studio first, run a 4-bit model sized to the machine you already own, and let actual usage tell you whether more memory is worth the money. The barrier to finding out is one download and ten minutes.

Sources

1. ggml-org — llama.cpp repository (README), accessed July 2026
2. Ollama — official repository and releases, accessed July 2026
3. LM Studio — official site, accessed July 2026
4. OpenAI — gpt-oss-20b model card (Hugging Face), accessed July 2026
5. Qwen — Qwen3.6-35B-A3B model card (Hugging Face), accessed July 2026
6. Google DeepMind — Gemma models, accessed July 2026
7. DeepSeek — DeepSeek-V4-Flash model card (Hugging Face), accessed July 2026
8. Mistral AI — Mistral Small 4 announcement, accessed July 2026
9. Meta — Llama organization page (Hugging Face), accessed July 2026

Related: Why Toolkit runs entirely in your browser · How AI vocal removal works · Try the in-browser vocal remover

The one constraint everything follows from

Before any specific pattern, understand the thing they all serve: context is a finite, degrading resource. Anthropic's own guidance is blunt about it — as a model's context window fills up, "performance degrades," and Claude may start "forgetting earlier instructions or making more mistakes."^[1] The company's context-engineering write-up names the phenomenon "context rot": as the number of tokens grows, "the model's ability to accurately recall information from that context decreases."^[4]

The practical maxim that follows is worth taping to your monitor: aim for "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."^[4] Every pattern below is, at bottom, a way to raise signal and cut noise. A vague prompt is noise. A bloated instructions file is noise. A 40-file exploration you didn't need is noise. Keep that lens and most prompting decisions answer themselves.

Point at examples, not adjectives

The single highest-leverage change most people can make is to stop describing what they want in adjectives and start pointing at concrete things: files, patterns, symptoms, success criteria. A model can infer intent, but "it can't read your mind."^[1] The precision you skip in the prompt, you pay back in corrections.

Anthropic's best-practices guide is built around exactly these swaps. A few, adapted from its examples:^[1]

The common move is replacing a category ("tests", "a widget", "the bug") with a location and a shape. "Reference existing patterns" deserves special emphasis: existing code is the most information-dense specification you own, and "follow the pattern in HotDogWidget.php" carries more usable signal than any paragraph of prose about your house style.^[1] When you find yourself reaching for an adjective — "make it consistent", "clean this up", "more robust" — stop and find the file that already embodies what you mean.

Explore and plan before you let it code

One of the most effective and least intuitive moves is to explicitly forbid the agent from writing code at first. Letting it jump straight to an implementation "can produce code that solves the wrong problem."^[1] The recommended loop is four phases — explore, plan, code, commit — where the first two happen before a single line is written: have the agent read the relevant files and answer questions, then produce a written plan you can edit, and only then implement.^[1]

This isn't just folklore. When OpenAI tested inducing an explicit plan-and-reflect step on the SWE-bench Verified coding benchmark, the pass rate rose by 4% from that one addition alone.^[2] Planning surfaces the misunderstanding while it's still cheap to fix — in a paragraph of plan, not in 300 lines of confidently wrong code.

The honest counter-pattern matters just as much: planning has overhead, and small, well-scoped changes don't need it. Anthropic's guidance draws the line cleanly — "If you could describe the diff in one sentence, skip the plan."^[1] Plan when you're uncertain about the approach, when the change spans multiple files, or when you don't know the code. Renaming a variable is not a planning occasion.

Give it a way to check its own work

An agent "stops when the work looks done," and without something it can actually run, "looks done" is the only signal it has — which quietly makes you the verification loop, catching every mistake by hand.^[1] The fix is to hand the model a check that returns a real pass or fail: a test suite, a build, a linter, a screenshot to compare against. Then the loop closes on its own — the agent does the work, runs the check, reads the result, and iterates until it passes.^[1]

In prompt terms, that means folding the verification into the ask:

Two habits sharpen this further. Prefer tests you wrote, because they encode your understanding of the problem rather than the model's guess at it. And demand evidence over assertion — "the test output, the command it ran and what it returned"^[1] — because reading evidence is faster than re-running everything yourself. The rule compresses to five words worth remembering: if you can't verify it, don't ship it.

The three reminders that make agents persist

When you move from a chat assistant to an autonomous agent — one that runs tools in a loop until a task is done — a small set of standing instructions makes a measurable difference. OpenAI's GPT-4.1 prompting guide distills them to three, and reports that together they raised the model's SWE-bench Verified score by close to 20%.^[2] Paraphrased, they are:

1. Persistence. Tell it not to hand control back early: "keep going until the user's query is completely resolved before ending your turn."^[2] Without this, agents tend to stop halfway and ask whether they should continue.
2. Use your tools, don't guess. "If you are not sure about file content or codebase structure... use your tools to read files and gather the relevant information: do NOT guess or make up an answer."^[2] This is the single most effective line against hallucinated APIs and imagined file contents.
3. Plan and reflect around tool calls. The optional planning reminder — the same +4% from earlier — asks the model to think before each action and reflect on the result after.^[2]

Two mechanical notes from the same guide that quietly matter. Newer models tend to follow instructions "more literally" than older ones, so unequivocal directives beat hints you hope it infers.^[2] And in a long prompt, repeating the key instructions at both the top and the bottom measurably helps.^[2] If your agent frames edits as diffs, prefer a search/replace format with clear delimiters over one that leans on line numbers, which models get wrong.^[2]

If you're building the agent rather than just prompting it, the biggest lever is often the tools themselves. Anthropic found that switching its file tools from relative to absolute paths "eliminated this failure mode completely," and states the principle plainly: "tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts."^[3]

Persistent context, and knowing when to keep it loose

For anything you do more than once, stop re-typing the same context and write it down where the agent reads it automatically. Claude Code loads a CLAUDE.md file at the start of every session for exactly this — build commands, style rules, gotchas the model can't infer from code.^[1] But the guidance comes with a sharp warning that people ignore at their peril: keep it short. "Bloated CLAUDE.md files cause Claude to ignore your actual instructions." The test for every line is "Would removing this cause Claude to make mistakes?" If not, cut it.^[1] This is context rot again — a persistent-context file is only useful while it stays high-signal. The same "right altitude" applies: specific enough to guide behavior, flexible enough not to hardcode brittle logic.^[4]

Two more session habits pay off constantly. Course-correct the moment you see drift rather than letting a wrong turn compound; and when you've corrected the same thing twice, clear the context and restart with a better prompt, because "a clean session with a better prompt almost always outperforms a long session with accumulated corrections."^[1]

Finally, the limitation on all of this. Precision is a tool, not a religion — sometimes a loose prompt is the right call. When you're exploring, "what would you improve in this file?" can surface things you'd never have known to ask.^[1] The deeper point is a division of labor: across real usage, people make roughly 70% of the planning decisions but only about 20% of the execution decisions.^[5] Your job is to decide clearly what to build and how you'll know it worked; the patterns here are all in service of communicating that decision without noise. Get the intent and the check right, and you can afford to leave the how open. That, and not any single magic phrase, is what prompting a coding agent well actually is — and it starts with the humility to add complexity "only when it demonstrably improves outcomes."^[3]

Sources

1. Anthropic — Best practices for Claude Code (official documentation), accessed July 2026
2. OpenAI — GPT-4.1 Prompting Guide, accessed July 2026
3. Anthropic — Building Effective AI Agents (engineering blog), accessed July 2026
4. Anthropic — Effective context engineering for AI agents, accessed July 2026
5. Anthropic — How Claude Code is used in practice (research), accessed July 2026

Related: Using AI to write code: what actually works · Diff checker · Why Toolkit runs in your browser

What a Pi-hole actually is

Every time any app on any device wants to load something from the internet, it first asks a phone-book question: "what's the address for ads.example.com?" That lookup system is DNS, and normally your router forwards those questions to your internet provider or a public resolver.

Pi-hole is free, open-source software that takes over that phone-book job for your whole network. It keeps a long list of known ad and tracker domains, and when a device asks for one of them, Pi-hole simply refuses to hand over the address. The request dies before a single byte of the ad is downloaded. Everything else passes through to a real DNS resolver as usual. This design is called a DNS sinkhole: ads aren't hidden after they load — they never load.

Because the filtering happens at the network layer, it covers devices you could never install an ad blocker on. Your smart TV's home-screen telemetry, the tracking calls inside mobile games, the analytics beacons in "free" apps — if the domain is on the list, it goes nowhere.

Despite the name, Pi-hole isn't picky about hardware. It officially supports Raspberry Pi OS, Debian, Ubuntu, Fedora and several other Linux distributions, and its demands are tiny: 512 MB of RAM and 2 GB of free disk space (4 GB recommended)^[1]. A Raspberry Pi is simply the cheapest, quietest, most set-and-forget way to run it.

What it blocks — and what it honestly doesn't

This is where most Pi-hole articles oversell, so let's be precise. Pi-hole sees exactly one thing: domain names. For any given domain it has two options — answer the lookup or refuse it. There is no third option^[2].

That works beautifully when ads come from dedicated ad domains, which is most of the display-ad and tracker ecosystem. It fails when a service serves ads from the same domains as its actual content. YouTube is the canonical example: the video stream and the ads come from the same infrastructure, so blocking the ad domains means blocking the videos. Pi-hole's own community FAQ is upfront that in-video YouTube ads are effectively out of reach, and recommends a browser-level blocker like uBlock Origin for that job^[2]. The same logic applies to ads inside Facebook, Instagram and most big first-party platforms.

So set expectations accordingly. You'll notice: cleaner pages on many ad-heavy sites, quieter smart devices, fewer trackers following you between apps, and a dashboard that shows just how chatty your gadgets are. You won't notice: any change to YouTube ads, in-app ads served first-party, or sponsored results inside search engines. Pi-hole plus a browser extension is the honest combination, not a rivalry.

And yes — we see the irony of publishing this on a site that pays its hosting bill with ads; our view is that unobtrusive ads fund free tools, and what you block on your own network is entirely your call.

The parts list

Everything below is current as of July 2026, with prices from raspberrypi.com^[3]:

• A Raspberry Pi — any model from roughly the last decade. The Raspberry Pi Zero 2 W costs $15, has built-in Wi-Fi, and is more than enough for Pi-hole^[3]. The Raspberry Pi 5 (from $45) is massive overkill for this job — buy one only if you want headroom for other projects. And if there's an old Pi 3 or 4 in a drawer, it's perfect; this is the classic way to give one a second life.
• A microSD card. Pi-hole itself needs only 2–4 GB of free space^[1], so any name-brand card sold today clears the bar with room to spare. Buy from a reputable retailer — counterfeit cards are the most common cause of mysterious Pi problems.
• A power supply. The Zero 2 W takes micro USB; recent full-size models take USB-C. A proper supply (official or equivalent) beats a random phone charger — undervoltage is the other classic source of gremlins.
• Optional: an Ethernet connection. A DNS server answers hundreds of tiny queries a day, and wired is the more dependable way to serve them. Wi-Fi works fine on the Zero 2 W for a typical home; just place it somewhere with a solid signal.

No monitor, keyboard or soldering iron required — we'll do the whole setup "headless" from your existing computer.

The build, step by step

Step 1 — flash the operating system

Download Raspberry Pi Imager (free, for Windows, macOS and Linux) from raspberrypi.com^[4]. Insert the microSD card into your computer, pick your Pi model, and choose Raspberry Pi OS Lite as the operating system — "Lite" means no desktop, which is exactly right for a box you'll never plug a monitor into.

Before writing, don't skip Imager's customisation screen — it's what makes the headless setup painless. There you can set a hostname (something memorable like pihole), create your username and password, enter your Wi-Fi network's credentials, and enable SSH so you can log in remotely from the first boot^[5]. Fill in all four, write the card, then put it in the Pi and plug in power.

Step 2 — connect to the Pi

Give it a minute or two to boot, then from a terminal on your computer (Terminal on macOS, PowerShell on Windows) connect with the username and hostname you chose: ssh yourname@pihole.local. If .local names don't resolve on your network, find the Pi's IP address in your router's device list and use that instead. Once you're in, bring the system up to date with sudo apt update && sudo apt full-upgrade.

Step 3 — run the Pi-hole installer

Pi-hole's official install method is a one-liner^[6]:

curl -sSL https://install.pi-hole.net | bash

Piping a script straight from the internet into your shell is a practice worth side-eyeing, and Pi-hole's own docs acknowledge the controversy — they offer alternatives where you download the script first, read it, and then run it^[6]. (Our guide to verifying downloads covers the general habit.) Either way, a friendly text-mode wizard walks you through the choices: pick an upstream DNS provider (any of the listed ones is fine), accept the default blocklist, and keep the web admin interface enabled. The installer will remind you that Pi-hole needs a static IP address to do its job^[1] — the cleanest fix is a "DHCP reservation" for the Pi in your router's settings, so it always gets the same address. When the installer finishes it prints the address of your admin dashboard and a password for it; write both down.

Step 4 — point your router at it

Right now, Pi-hole is a bouncer standing at a door nobody uses. The fix is one setting: in your router's admin page, find the DHCP or LAN settings and set the DNS server to your Pi-hole's IP address. That's the method Pi-hole's docs recommend, because every device on the network picks it up automatically. If your router doesn't let you change its DNS setting (some ISP-issued boxes don't), Pi-hole can act as your DHCP server instead — disable the router's DHCP first — or, as a last resort, you can point each device at the Pi-hole manually^[7].

Devices adopt the new DNS when they renew their lease, so toggle Wi-Fi off and on to hurry things along. Then open the admin dashboard, load a few websites on your phone, and watch the query log light up. That moment — seeing every lookup your gadgets make, and the blocked ones dying in real time — is the whole payoff of the project.

Day two: breakage, upkeep and household diplomacy

Sooner or later something will misbehave — a tracking-wrapped link in a marketing email won't open, a coupon site won't load, an app's login flow stalls. This is normal, and the fix takes seconds: check the dashboard's query log for the red blocked entry, then whitelist it from the web interface or over SSH with pihole allow thedomain.com^[8]. Expect a small flurry of these in week one, then near silence.

Maintenance is genuinely light. The blocklists are compiled into a database Pi-hole calls gravity, which updates itself automatically every week; pihole -g runs the update on demand, and pihole -up upgrades Pi-hole itself when a new release lands^[8]. That's the entire routine.

One social tip: tell your household what changed and how to reach you when a page acts up. The dashboard has a temporary "disable blocking" button for genuine emergencies — better that they ask you than that they blame the internet.

The honest alternatives

Pi-hole isn't the only way to get this. AdGuard Home is the closest rival — the same DNS-sinkhole idea, open source, shipped as a single program with a polished interface and encrypted-DNS support built in; it runs happily on the identical hardware, and choosing between the two is mostly taste. Hosted filtering services do the same filtering in the cloud with no hardware at all, in exchange for routing your DNS history through a third party. And if the only ads you actually care about are the ones in your own browser, a good extension like uBlock Origin blocks more (including YouTube), costs nothing, and takes thirty seconds to install — no Pi required. The case for Pi-hole is specific: you want the whole network covered, including every screen and gadget you can't install an extension on, and you'd rather the filtering happen on a box you own.

Sources

1. Pi-hole documentation — Prerequisites, accessed July 2026
2. Pi-hole Userspace (official forum) — How do I block ads on YouTube?, accessed July 2026
3. Raspberry Pi — Products, accessed July 2026
4. Raspberry Pi — Raspberry Pi Imager, accessed July 2026
5. Raspberry Pi — Getting started documentation (Imager OS customisation), accessed July 2026
6. Pi-hole documentation — Installation, accessed July 2026
7. Pi-hole documentation — Post-Install, accessed July 2026
8. Pi-hole documentation — The pihole command, accessed July 2026

Related: How to verify a download with checksums · Why Toolkit runs entirely in your browser · All posts

Where AI genuinely shines

Some tasks are almost embarrassingly well-suited to a language model. The common thread: the task is well-specified, the pattern exists in a million training examples, and you can check the result quickly.

• Boilerplate and glue. CRUD endpoints, serialization code, config files, CI pipelines, argument parsing. Nobody's craft is expressed in a Dockerfile.
• Unfamiliar-but-mainstream territory. You know exactly what you want but not the incantation — a gnarly SQL window function, an ffmpeg flag combination, a CSS grid layout. The model has seen ten thousand of them.
• Reading code, not just writing it. Onboarding to a new codebase by asking questions — "how does logging work here?", "what edge cases does this handler cover?" — is one of the most effective uses Anthropic recommends for its own agentic tool, and it needs no special prompting.^[1]
• Tests, migrations and mechanical refactors. Renames across files, converting one pattern to another, generating test cases for edge conditions you describe. Tedious for you, trivial for the machine, easy to verify.
• A first draft to argue with. A mediocre concrete proposal is often faster to fix than a blank page is to fill.

Notice what's on the list: tasks where verification is cheap. That's not a coincidence, and it's the lens for everything that follows.

Where it quietly wastes your time

In 2025, the research group METR ran a randomized controlled trial that should hang over every AI-coding discussion: 16 experienced open-source maintainers completed 246 real issues in mature repositories they knew deeply, with tasks randomly assigned to allow or forbid AI tools. With AI, they took 19% longer. They had predicted AI would make them 24% faster — and even after finishing, still believed it had made them about 20% faster.^[2]

METR is careful about the caveats, and so should you be: this was a snapshot of early-2025 tools, in one demanding setting — experts on large codebases they knew inside out — and it says nothing about other developers or later tools.^[2] But the perception gap is the durable lesson. AI assistance feels fast because the keystrokes stop being yours. Whether it is fast depends on how long you spend steering, reviewing, and repairing plausible-but-wrong output.

The time sinks cluster predictably. Code that depends on deep, undocumented context the model doesn't have. Iterating on vague prompts instead of thinking for two minutes first. Debugging a subtly wrong 300-line generation instead of writing a correct 60-line version yourself. If you know exactly what a small diff should be, typing it is often the fast path — Anthropic's own guidance says to skip the planning ceremony when you could describe the change in one sentence.^[1]

You own every line

The single non-negotiable rule: never merge code you haven't read and understood. Not skimmed — read. "The AI wrote it" will never appear in a post-incident review as an excuse; the commit has your name on it, and so does the pager.

The industry-scale data backs the discipline. Google's 2025 DORA report found AI adoption now correlates with higher software delivery throughput — but still with worse delivery stability, because more change volume exposes every weakness downstream of it. Its summary line is the most useful sentence written about this technology: AI doesn't fix a team, it amplifies what's already there.^[3] Teams with strong review culture, automated tests and fast feedback loops get faster. Teams that rubber-stamp PRs get broken releases, faster. Notably, about 30% of developers surveyed report little or no trust in AI-generated code^[3] — a healthy instinct, as the security numbers below confirm.

Practical review habits that hold up:

1. Review the diff, not the vibe. Read generated changes with the same hostility you'd give a stranger's pull request. Small, reviewable increments beat one giant generation.
2. Make the model explain itself. Ask why it chose an approach, what breaks it, which edge cases it handles. Wrong answers here are your earliest warning.
3. Watch for plausible-looking APIs. Hallucinated methods and invented package names still happen; they compile in the model's imagination only. Every import earns an existence check.
4. Keep commits separable. If an AI-assisted change goes bad in production, you want to revert one commit, not archaeologically excavate it from a week of mixed work.

Context is most of the job

The quality gap between developers using the same model is mostly a context gap. A model can't read your mind, your architecture docs, or your team's taste — unless you hand them over. Anthropic's best-practices guide for Claude Code is blunt about it: the more precise your instructions, the fewer corrections you'll need.^[1] The same guidance applies to any assistant or agent:

• Point at examples, not adjectives. "Follow the pattern in HotDogWidget.php" beats "make it consistent with our style" every time.^[1] Existing code is the most information-dense spec you own.
• Write the spec down. Which files, what's out of scope, what "done" looks like, which libraries are allowed. For anything nontrivial, a few minutes of spec saves an hour of correction loops.
• Persist project context. Tools like Claude Code read a CLAUDE.md file at the start of every session — build commands, style rules, gotchas the model can't infer from code. Kept short and pruned hard, it compounds in value; bloated, it gets ignored.^[1]
• Explore, plan, then code. Letting an agent jump straight to implementation is how you get a confident solution to the wrong problem. Have it read the relevant code and produce a plan you can edit before it touches anything.^[1]
• Describe symptoms, locations and success criteria for bugs. "Login fails after session timeout, check token refresh in src/auth/, write a failing test first" gives the model a landing zone; "fix the login bug" gives it a dartboard.

Make it prove its work

A language model's output always looks done — that's precisely what it's optimized for. So looking done must never be the acceptance test. Give the model a check it can run: a test suite, a build, a linter, a script that diffs output against a known-good fixture. With a pass/fail signal in the loop, the model iterates against reality instead of against your patience; without one, you personally are the verification loop, and every mistake waits for you to notice it.^[1]

The strongest version is test-first: write (or dictate) the tests yourself, then let the model make them pass. Tests you authored encode your understanding of the problem, which is exactly the thing you're otherwise trusting the model to guess. And demand evidence over assertion — actual test output, the command it ran and what it returned — because reviewing evidence is faster than re-running everything yourself.^[1] One warning: a model told to make tests pass will sometimes take shortcuts, special-casing the test's inputs or weakening an assertion. Generated changes to test files deserve your most suspicious read.

The habit generalizes into a rule short enough to remember: if you can't verify it, don't ship it.^[1]

The security and license fine print

Here the data is genuinely uncomfortable. Veracode's 2025 GenAI Code Security Report tested over 100 LLMs on 80 curated coding tasks across Java, Python, C# and JavaScript: 45% of the time, models introduced an OWASP Top 10 vulnerability when a secure and an insecure implementation were both available. For cross-site scripting defenses the failure rate hit 86% of relevant samples; Java fared worst of the languages at a 72% failure rate. Worse, security performance stayed flat as models got newer and larger — the functional code got better, the secure code didn't.^[4]

The mechanism is mundane: models reproduce the average of their training data, and the average public code sample handles input sanitization, secrets and authentication carelessly. Unless your prompt makes security requirements explicit, the model decides for you — so state them (parameterized queries, output encoding, no secrets in code), run static analysis on generated code just as you would on human code, and give extra scrutiny to anything touching auth, file paths, SQL or user input.

Licensing is the quieter pitfall. Generated code can occasionally match public code verbatim — GitHub says matches occur in under 1% of Copilot suggestions, and its code-referencing feature checks suggestions against an index of public repositories and surfaces the matching file and its license, with a policy option to block such suggestions outright.^[5] Under 1% is small until you multiply it by thousands of suggestions a week. If you ship commercial software, turn these controls on; a copyleft-licensed snippet pasted into proprietary code is a problem no model will flag on its own.

Skills atrophy, and when to leave AI out

The honest version of the atrophy concern: it's real, but it's not automatic. A CHI 2025 study of 319 knowledge workers by Microsoft Research and Carnegie Mellon found that higher confidence in the AI was associated with less critical thinking, while higher confidence in one's own skills was associated with more — and that AI shifts the thinking that remains toward verifying, integrating and stewarding output rather than producing it.^[6] The muscle you stop using is the one you lose; the developers who stay sharp are the ones who keep treating the model's output as a claim to evaluate, not an answer to accept. Deliberate practice still matters — sometimes write it yourself, on purpose, especially in the areas you're supposed to be the expert.

And some work you should simply keep away from the tools, as of mid-2026:

• Code you can't evaluate. If you lack the expertise to judge the output, you have no review step — you're not using a tool, you're trusting a stranger. Cryptography is the canonical example.
• Novel algorithms and genuinely new problems. Models interpolate from what exists. Where there's no prior art, they generate confident pastiche.
• High-stakes logic: payments, permissions, safety-critical paths, data deletion. Assist, maybe. Generate-and-skim, never.
• Code you're not allowed to share. Cloud assistants see what you send them; check your employer's policy and the vendor's retention terms before pasting proprietary code.

The through-line of all of it: AI coding tools reward exactly the practices that made software good before them — clear specs, small reviewable changes, strong tests, healthy suspicion. That's the amplifier effect in DORA's data^[3], and it's the cheerful conclusion hiding inside the scary studies. The tools don't replace engineering judgment. They pay interest on it.

Sources

1. Anthropic — Best practices for Claude Code (official documentation), accessed July 2026
2. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025, accessed July 2026
3. Google Cloud — Announcing the 2025 DORA (State of AI-assisted Software Development) Report, accessed July 2026
4. Veracode — Insights from the 2025 GenAI Code Security Report, accessed July 2026
5. GitHub Docs — GitHub Copilot code referencing, accessed July 2026
6. Microsoft Research — The Impact of Generative AI on Critical Thinking (CHI 2025), accessed July 2026

Related: Why Toolkit runs entirely in your browser (and why that matters) · Diff checker · Browse all tools

Four questions that beat brand loyalty

People pick an AI assistant the way they pick a phone: once, on vibes, and then defend the choice. That's backwards, because switching costs here are nearly zero — every major assistant has a free tier, and a paid subscription can be cancelled monthly. Before any brand name, ask:

1. Task fit. Casual questions, serious writing, coding, research and data work stress models differently. A model that tops coding evaluations can be a mediocre editor, and vice versa.
2. Budget. The gap between "free", "$20 a month" and "$200 a month" is not capability alone — it's mostly usage limits and early access. Most people overestimate which tier they need.
3. Privacy. Everything you type into a hosted assistant lands on someone else's server, governed by that vendor's retention and training policies. If that's unacceptable for some of your material, the open-weight lane below exists precisely for you.
4. Ecosystem. If your life is in Gmail and Docs, Gemini's integration is a genuine advantage; if your team lives in a code editor, the model your tooling supports best matters more than any leaderboard.

With those four answers in hand, the vendor landscape gets much easier to read.

The big three, as of July 2026

Everything in this section is perishable — lineups turn over every few months, so treat it as a snapshot dated July 2026, checked against each vendor's own pages.

Anthropic (Claude). The current family is a capability ladder: Claude Fable 5, the most capable widely released model, pitched at long-running agent work ($10 input / $50 output per million API tokens); Claude Opus 4.8 for complex agentic coding and enterprise work ($5/$25); Claude Sonnet 5, "the best combination of speed and intelligence" ($3/$15, with introductory pricing through August); and Claude Haiku 4.5, the fast, cheap one ($1/$5). The top three models all take 1M-token context windows — roughly half a million words in one conversation.^[1] Claude's reputation, deserved in our experience, is strongest in writing quality and software engineering.

OpenAI (ChatGPT). The newest API family is GPT-5.6, sold in three tiers — Sol ($5/$30 per million tokens), Terra ($2.50/$15) and Luna ($1/$6) — atop a deep bench of older and smaller models (GPT-5.4-mini and -nano go as low as $0.20 input) and premium reasoning models that run up to $30/$180.^[2] On the consumer side, ChatGPT Plus is $20 a month, with a cheaper Go tier below it and two Pro tiers at $100 and $200 that buy 5× and 20× the usage of Plus respectively.^[3] ChatGPT remains the most polished all-rounder, with the largest ecosystem of integrations and the most familiar interface.

Google (Gemini). The current API lineup pairs Gemini 3.5 Flash — the newest stable model, pitched at agentic and coding work — with Gemini 3.1 Pro for advanced reasoning (still labelled preview) and 3.1 Flash-Lite for high-volume budget jobs, plus a stable of image (Nano Banana) and video (Veo 3.1) models.^[4] Consumer plans run from Google AI Plus at $4.99 a month through AI Pro at $19.99 to AI Ultra starting at $99.99, with the higher tiers unlocking the Pro model, the Deep Think reasoning mode and much higher limits.^[5] Gemini's structural advantage is the ecosystem: it's threaded through Gmail, Docs and Search in a way no competitor can match, and its multimodal breadth (native image, video, audio) is the widest.

Notice what's common across all three: every vendor now sells a ladder, not a model. The expensive flagship for hard problems, a mid-tier workhorse, and a fast cheap model for volume. The brand matters less than which rung you're on.

Free tier, paid assistant, or API — what you're actually buying

These are three different products that happen to share a brain, and knowing which one you need saves real money.

Free tiers are genuinely useful in 2026 — all three vendors give away access to capable models with daily or hourly caps. If you ask an AI a few questions a day, you may never need to pay anyone. The catches: tighter limits, slower or smaller models at busy times, and last-in-line access to new features.

Paid assistants ($5–$20/month for the standard tiers) buy you higher limits, the current flagship models, and the premium features — deep research modes, file analysis, agent capabilities. The $100+ tiers exist for people who lean on AI professionally for hours a day; their value is almost entirely in usage headroom, not smarter answers.^[3] If you've never hit a rate limit, you don't need them.

The API is pay-per-use — you're billed per million tokens (a token is roughly three-quarters of a word) and bring your own interface. For developers this is obvious territory, but it's underrated for heavy text users: at Sonnet 5 or GPT-5.6 Terra rates, a long document summarised costs a fraction of a cent, and light API use can come out far cheaper than a subscription. The trade is convenience — you need a client app or a script, and there's no polished chat interface unless you install one.

The open-weight lane: privacy and tinkering

Everything above runs on a vendor's servers. The alternative is models whose weights you can download and run on hardware you control — and in 2026 this lane is genuinely competitive, not a consolation prize. Meta's Llama 4 family (Scout and Maverick) brought open-weight, natively multimodal mixture-of-experts models, with Scout sized to fit a single high-end GPU^[6] — though it now looks like the end of an era, since Meta's newest flagship, Muse Spark, launched proprietary in April 2026.^[7] The energy has shifted to DeepSeek, whose V4 models pair downloadable weights with rock-bottom API prices (V4-Flash output costs $0.28 per million tokens — orders of magnitude below Western flagships)^[8]; Alibaba's Qwen 3.5, a 397B-parameter Apache-2.0 multimodal model with a family of smaller siblings^[9]; and Mistral, which ships its flagship Large 3 and Small 4 under Apache 2.0 alongside edge models built for on-device use.^[10] If your material can't leave your machine — client files, medical notes, unreleased code — this is your lane, and our companion post on running LLMs locally covers the hardware and tools it takes.

A decision guide by scenario

Sensible starting points, not verdicts — the right move is to try two or three candidates on your real work (more on that below).

A word about benchmarks

Every launch since 2023 has come with a chart where the new model wins, and mid-2026 is no different. Treat these numbers as marketing first and measurement second. The known problems are structural: popular benchmarks leak into training data; vendors run competitors at unflattering settings; "leaderboard" rankings shift with prompt format and sampling; and a two-point gap on an abstract evaluation says nothing about whether a model writes emails the way you like. Public leaderboards based on user votes measure charm as much as competence — models can win by being confident and verbose rather than right.

The fix is boring and effective: build a personal benchmark. Save five to ten real tasks from your own life — an email you actually sent, a bug you actually fixed, a document you actually summarised — and run them through two or three candidates. Thirty minutes of this tells you more than every leaderboard combined, because it measures the only distribution that matters: yours.

The bottom line

As of July 2026 there is no wrong choice among the majors for everyday use — Claude, ChatGPT and Gemini are all excellent, and each vendor's ladder means your real decision is a tier, not a religion. Pick by task fit, spend the minimum until you hit limits, keep sensitive material in the open-weight lane, and re-evaluate twice a year, because every specific fact in this post has a shelf life. The people getting the most out of AI right now aren't the ones who picked the "best" model — they're the ones who learned to test quickly and switch without sentiment.

Sources

1. Anthropic — Models overview (Claude Platform docs), accessed July 2026
2. OpenAI — API pricing, accessed July 2026
3. OpenAI Help Center — About ChatGPT Pro tiers, accessed July 2026
4. Google AI for Developers — Gemini models, accessed July 2026
5. Google — Gemini subscription plans, accessed July 2026
6. Meta AI — The Llama 4 herd, accessed July 2026
7. VentureBeat — Meta launches proprietary AI model Muse Spark, accessed July 2026
8. DeepSeek — Models & pricing (API docs), accessed July 2026
9. Qwen — Qwen3.5-397B-A17B model card (Hugging Face), accessed July 2026
10. Mistral AI — Models, accessed July 2026

Related: Running AI on your own hardware: local LLMs explained · How large language models actually work · Why Toolkit runs entirely in your browser