AI
A Fully Local AI Assistant in One docker agent YAML
Point Docker Agent at a local OpenAI-compatible server, declare a few toolsets, and you have a private assistant that reads files, runs shell commands and calls your own scripts — no cloud API key required
docker agent is Docker’s agent runtime (the CLI plugin built on the open-source cagent project — you’ll
see that name in ~/.config/cagent). Its whole contract is a single YAML file: one block describing agents,
one describing models. Nothing stops you from pointing the model block at localhost, which is the
interesting part — the same declarative agent, tools and all, running against a model on your own machine.
opencode.json: Wiring a Terminal Coding Agent to a Local Model
One JSON file turns opencode into a fully local assistant — declare an OpenAI-compatible provider, describe your models, and check the resolved config before you trust it
opencode is a terminal coding agent, and it has no opinion about where its tokens
come from. Providers are declared in an opencode.json file, so pointing it at a model running on your own
machine — LM Studio, an MLX server, llama.cpp, vLLM — is a matter of a baseURL and a couple of lines of
metadata. Here’s a config with three providers side by side: a LAN box, a hosted API, and a local server.
The Local AI Toolbox: 13 Tools That Run Entirely on Your Machine
A tour of the local-AI tooling I'd actually install in 2026 — runtimes, hardware-fit checkers, on-device speech and TTS, and document parsing, with the licenses and caveats that matter.
The interesting thing about local AI in 2026 isn’t that it’s possible — it’s that the boring parts finally work. A Mac with 16 GB of unified memory, or a PC with an 8 GB GPU, runs a 7B–13B model well enough for transcription, OCR, routine chat and the small repetitive tasks that make up most of the day. No API key, no per-token meter, no outage on someone else’s status page.
What follows is the toolbox: thirteen tools, grouped by what they actually do. I verified each one’s repository, language and license while writing this, because half the “top tools” lists circulating right now cite projects that have been renamed or abandoned. Where something surprised me, I say so.
My Claude Code Setup, From Zero
Installing Claude Code and wiring it up the way I actually use it: CodeGraph for code intelligence, MCP servers, plugin marketplaces, LSP, GitHub Spec Kit, and Herdr to keep the agents running.
A fresh Claude Code install is useful. A configured one is a different tool entirely. The gap between the two is maybe fifteen minutes of setup — a code index, a handful of MCP servers, two plugin marketplaces, a spec workflow, and a runtime to keep it all alive — and I keep re-doing it every time I move to a new machine. So here it is written down, in the order I run it.
cartographer-mcp: give Claude Code a map of your GitLab architecture
An MCP server that crawls GitLab groups to build a service catalog with dependency graphs, queryable from Claude Code
Every Claude Code session that involves more than one repo starts with the same monologue: “we have a payment service that calls user-service via REST, which publishes events that notification-service consumes, and oh by the way the platform team owns auth-service…” By the time I’ve finished the briefing, I’ve burned tokens and patience.
cartographer-mcp is my attempt at fixing that. It crawls your GitLab organization, builds a service catalog with a dependency graph, and exposes it as MCP tools so Claude Code already knows the shape of your architecture.