DEV Community: Alvarito1983

Meta's Muse Glimmer: a real agentic model that fits on your own GPU

Alvarito1983 — Tue, 11 Aug 2026 08:58:02 +0000

On August 10th, Meta released Muse Glimmer, a 30-billion-parameter open model built specifically to run local AI agents on consumer hardware — scheduling, file organization, tool calling, multi-step tasks — without shipping any of it to Meta's servers. Weights are on Hugging Face under an Apache 2.0 license, so there's no commercial restriction on using it.

Why this one is different from the last wave of "local" models

The 7B and 13B models that filled up Ollama's library over the last couple of years were solid text generators, but weak agents. Multi-step reasoning fell apart, tool calls failed halfway through, and they'd lose track of what happened three steps back in a task.

Glimmer is Meta's answer to that gap specifically — it's a simplified, efficiency-focused derivative of Meta's larger Muse Spark 1.2 model, purpose-built for "always-on" agentic workflows: the kind of thing that needs to keep running continuously on a personal machine rather than answering one prompt at a time.

What it actually needs to run

30B parameters, quantized memory footprint of 18–20 GB — within reach of current high-end consumer GPUs, no server rack required
Handles interleaved text and images (screenshots, documents, mixed content) across 100+ languages
Native support for the frameworks local-AI users already have installed: Ollama, LM Studio, llama.cpp, MLX, vLLM, SGLang — if you already pull models from Hugging Face, this drops into your existing workflow with no extra tooling
Meta is also working with AMD, Arm, Dell, Intel, and NVIDIA on hardware-specific performance tuning, and providing documentation for building custom agent scaffolds on top of it
The bigger picture

Glimmer didn't launch alone — Meta paired it with a 14-page essay from Mark Zuckerberg ("The Future Is for Everyone") arguing against AI capability staying locked inside a handful of companies, and confirmed weights for the larger Muse Spark model are coming too. It's a direct response to the pressure open models are putting on the market: Chinese labs — Moonshot's Kimi K3, Alibaba's Qwen3.8-Max, DeepSeek's V4-Flash — are shipping performance that rivals closed US frontier labs, and open weights are consistently cheaper to run at scale, which matters to anyone watching their own inference bill.

Where this fits in a self-hosted setup

For anyone already running local models as part of a homelab — Ollama containers, a GPU passed through to a VM, that kind of setup — Glimmer is one of the first local models actually aimed at running unattended agent workflows instead of just answering chat prompts. That's a meaningfully different use case from "local chatbot," and worth testing against real tasks rather than benchmarks.

I run local AI as part of my own homelab, so I'll be testing Glimmer against real agentic tasks rather than benchmarks — full writeup on El Rack once I've put it through its paces:

👉 Muse Glimmer, el nuevo modelo de Meta

(Spanish-language site — translation tools handle it cleanly if you don't read Spanish.)

I write about homelab, self-hosting, and local AI at El Rack — real testing from inside my own homelab, not just a spec sheet rewrite.

NVIDIA 610.57.04 for Linux: the point release actually worth installing

Alvarito1983 — Mon, 10 Aug 2026 12:03:11 +0000

On August 3rd, NVIDIA quietly shipped two Linux driver branches on the same day: the new feature branch 610.57.04 and the stable 595.91.07. The stable release is the usual "minor bug fixes and improvements" non-answer, but 610.57.04 is a different story — it carries an unusually large fix list for a point release, and if you're gaming on Linux with an NVIDIA card, it's worth grabbing now instead of leaving it to rot in your package manager.

What actually got fixed

More than 20 titles are patched in this release, several of which had been broken for weeks or months:

STALKER 2: Heart of Chornobyl — crash with VK_DEVICE_LOST
Assetto Corsa EVO — incorrectly wrapped textures
Monster Hunter Wilds — crash at the main menu (driver reporting the GPU as unresponsive)
Forza Horizon 6 — GPU hangs tied to the VKD3D-Proton descriptor heap feature
Elden Ring and Elden Ring Nightreign
Plus fixes touching Assassin's Creed Origins, Total War: Warhammer III, Crimson Desert, X-Plane, and a long tail of smaller titles (007 First Light, Grounded 2, Star Rupture, Windrose, and others)

Outside of gaming fixes, two changes matter for general desktop stability:

A fix for an X Server crash under GLX indirect rendering
A fix for black screens after modesets in X11 apps using the Present extension

For anyone running a Turing-generation GPU or newer, installation has also gotten noticeably less painful — modeset configuration is now handled automatically, closer to a plug-and-play experience than the manual dance NVIDIA-on-Linux has traditionally required.

Should you actually install it?

If you're not chasing bleeding-edge features and just want the most predictable driver, 595.91.07 (the parallel stable release) is the safer pick. But if any of the games above have been giving you trouble, or you've been holding off on an update because previous 610-branch builds felt rough, this specific point release is the one that closes out most of those complaints — 610.57.04 was the first release in the R610 feature branch back in late May, and this is the point release that actually fixes what broke on launch.

The installer is available directly from NVIDIA (~442 MB), with DKMS, RPM, and deb packages supported out of the box. If you're new to NVIDIA-on-Linux, installing through the .run file is still not the recommended path for beginners — wait for your distro's packaged version if you can, since it's much harder to break.

Full verdict and version comparison

I run this driver daily on my own homelab/gaming setup, so I put together a deeper breakdown — full version comparison table, install notes, and my actual verdict after running it for real — over on El Rack:

👉 Driver NVIDIA 610.57.04 para Linux

(Spanish-language site — the specs table, version numbers, and rating are readable regardless, and translation tools handle the rest cleanly if you want the full writeup.)

I write about homelab, self-hosting, and Linux gaming at El Rack — real testing from inside my own homelab, not just a spec sheet rewrite.

Claude Code Now Runs Subagents in the Background by Default — What Actually Changed

Alvarito1983 — Fri, 07 Aug 2026 07:15:58 +0000

Original article in Spanish on El Rack: Claude Code ya no espera a que le mires: subagentes en segundo plano por defecto

I run Claude Code daily as my main dev agent, both locally and over SSH against a VPS running a handful of production sites. A change that landed over the last few weeks quietly rewired how I work with it: subagents now run in the background by default.

Before, when Code delegated a task to a subagent, the conversation blocked until that subagent finished. Since July 1, it keeps working on other things while the subagent runs, and notifies you when it's done. For anyone running long sessions with --dangerously-skip-permissions and checking back hours later, that's the difference between a tool that waits and one that actually works unattended.

What changes day to day

My workflow has always been the same: approve the initial plan, then let Code proceed without confirmation on every step, stopping only on real errors. With background subagents, that autonomy compounds. I can now ask it to audit a site, generate new content, and review config files at the same time — each running as an independent subagent instead of queuing one after another.

Two limits matter here: a default cap of 20 concurrent subagents, and nesting now allowed up to 3 levels deep (up from 1). Both exist for a reason — it's easy for a large task to branch further than you expect if nothing constrains it.

Sonnet 5 and Opus 5: 1M context is no longer the exception

Claude Sonnet 5 became the default model in late June, with a native 1M-token context window. Claude Opus 5 replaced it as the default Opus model on July 24, also with 1M context. In long sessions — the kind you get during a full editorial rebuild of a site — I used to watch /context and run /compact mid-task to avoid losing thread. Now I run noticeably longer sessions without touching either. It's not magic: auto-compaction still kicks in, and cost on very long Opus sessions is worth watching, but the practical ceiling moved.

The security fix that actually matters

As someone who manages production infrastructure, this is the line item I care about most: in August, a fix landed for worktree-isolated sessions (and their subagents) that could run destructive git commands against the main checkout. When you're launching subagents with broad permissions against something that matters, broken isolation like that is exactly the failure mode you don't want. That it got closed quickly is a good sign — but also a reminder that "autonomous" and "unsupervised" aren't the same thing. I still review the final report of every session rather than assuming no visible errors means everything went well.

Where I still draw lines

With this much autonomy, the temptation is to hand off increasingly ambitious tasks and walk away. I don't do that on anything touching client-facing production servers — those sessions stay interactive, with explicit confirmation on sensitive steps. Where I do give it full rein is on my own infrastructure, where the cost of a mistake is low and recoverable. That distinction, more than any config flag, is what actually determines how much autonomy a session gets.

Bottom line

Background-by-default subagents are the change that's altered my day-to-day with Claude Code the most in months — not because it's flashy, but because it fits how I was already using it: approve the plan, let it run. The 1M context on Sonnet 5 and Opus 5 supports that well. The worktree isolation fix is the reminder that more autonomy means reviewing final output more carefully, not less.

Original (Spanish, full version with pros/cons and more context): https://elrack.es/herramientas-ia/claude-code-subagentes-segundo-plano-opus-5-2026/

Kimi K3 is the largest open-weight model ever released — and you probably still can't run it

Alvarito1983 — Thu, 06 Aug 2026 06:45:20 +0000

Originally published in Spanish on El Rack. Browser translation handles the rest of the site fine if you're into homelab/self-hosting content.

Moonshot AI released Kimi K3 on July 17, 2026, and made the weights publicly downloadable on July 27. At 2.8 trillion parameters, it's the largest open-weight model ever published — and according to multiple benchmarks, it rivals Claude Opus and GPT on coding, reasoning, and general knowledge work, at a fraction of the training cost.

The New York Times ran an in-depth piece on it a few days after release, which tells you this isn't just another model drop.

What "open weights" actually gets you here

Publicly downloadable weights mean any company or researcher can run this locally and modify it without depending on a third-party API. If you already run Ollama or LM Studio in your homelab, that's the tempting part: a frontier-level model, no monthly quota, running on your own hardware.

The practical reality is different.

"2.8 trillion parameters isn't a number that runs on homelab hardware — it needs an enterprise-grade GPU cluster. The weight release is real, but "downloadable" and "runnable" are very different things at this scale."

The bigger debate this reopened

What makes Kimi K3 interesting isn't just the benchmark numbers — it's what it represents in the ongoing dispute over AI's geopolitics. The same fracture that opened up around DeepSeek-R1 in January 2025 is back: some argue US labs need to close up more in response to Chinese competition, others see openness as the only real way to stay relevant against an ecosystem that ships open weights at a pace closed labs can't match on transparency. There's also a real technical concern underneath: the possibility that outside actors use massive querying of closed American models to distill their outputs and train competing open models.

Where this actually matters for a homelab

Even though K3 itself is unrunnable on consumer hardware, its release pushes down what smaller, actually-runnable models (7B-70B, the ones that fit on a consumer GPU) can eventually achieve — research and techniques from frontier releases like this tend to filter down, via distillation, into much more manageable versions. Ollama's ecosystem usually adds support for distilled variants of these releases within days or weeks.

Verdict

Kimi K3 isn't something you're installing in your homelab this week, but it's a meaningful signal of where open AI is heading — and probably the source of much smaller, distilled versions that will show up in Ollama soon. Worth tracking not for what you can run today, but for what it anticipates for the near future.

Full article (in Spanish): https://elrack.es/herramientas-ia/kimi-k3/

The MCP servers actually worth installing in Claude Code (2026) Published

Alvarito1983 — Wed, 05 Aug 2026 07:15:44 +0000

Originally published in Spanish on El Rack, a Spanish tech review site I write for. Browser translation handles the rest of the site well if you want to dig deeper into the sysadmin/homelab content.

Claude Code is my main tool every day for managing a handful of self-hosted projects. So when "just install these 10 MCP servers" guides kept showing up in every forum thread, I wanted to actually separate what's worth the setup time from what's just noise sitting in your context window.

Here's what I found after digging into the current state of the ecosystem.

The cost nobody mentions before you install ten of these

Before the list: the one number that matters most. Every connected MCP server injects somewhere between 2,000 and 5,000 tokens of tool schemas at session start. Three servers connected at once is already 6,000 to 15,000 tokens spent before you type your first prompt.

That's not free, even though it feels like it. If Claude Code feels slower to start or seems to "forget" context earlier than you'd expect, check how many MCP servers you're leaving connected by default.

Correction (added after publishing): Claude Code now enables Tool Search by default, which defers MCP schema loading until a tool is actually used — a connected-but-idle server now costs closer to a name-and-description stub than a full schema dump. The 2,000–5,000 token figure above was accurate before this became the default, and still applies if you disable Tool Search or if a given server doesn't support deferred loading yet. Thanks to a reader for catching this in the comments.

MCP is convenient. It is not free. Every server you connect is tokens that are no longer available for your own code.

The three actually worth installing first

Independent guides keep converging on the same top three, and after using them daily, I agree with the consensus:

Context7 — live library documentation, so Claude doesn't hallucinate APIs that changed three versions ago. This is the one that's saved me the most from confidently-wrong code suggestions based on outdated library docs.

Official GitHub MCP — repo operations, pull requests, issues and CI, without leaving the chat. One caveat on the token cost above: for simple lookups, the gh CLI is still much cheaper than going through MCP.

Playwright MCP — lets Claude drive a real browser to confirm a frontend change actually renders correctly, instead of just trusting the code diff. If you do any frontend work, this is the difference between "the code compiles" and "the code actually works."

Two that Anthropic still maintains but aren't essential anymore

The original reference servers for structured reasoning and file operations are still around, but the general consensus is honest about it: native model reasoning improved enough through 2026 that most people skip the reasoning server entirely, and Claude Code already ships built-in file tools that make the equivalent MCP mostly redundant.

The governance shift that matters long-term

In December 2025, MCP governance moved from Anthropic alone to the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, Google, Microsoft, AWS, Cloudflare and Bloomberg on the board. In practice, this means vendor-maintained servers (Slack's own MCP, GitHub's own MCP) tend to be more reliable than generic third-party integrations — each company simply knows its own service better than any middleman.

Best MCP for a specific task

If you don't want to read the full ranking, here's the direct answer for whatever you're trying to solve:

Working with your database → The PostgreSQL MCP if you run Postgres on any provider, or the official Supabase MCP if your backend lives there specifically (you can scope it to a single project via a URL parameter — good security practice).

Repo management → The official GitHub MCP, already covered above.

Verifying frontend actually works → Playwright, also covered above.

Project docs and knowledge base → The Notion MCP, if your team documents there — keeps pages synced with code changes automatically.

Task management → The Linear MCP, the most widely adopted for this.

Production error monitoring → The Sentry MCP — brings real production error context straight into the chat instead of copy-pasting logs by hand.

Design → The Figma MCP — pulls measurements, components and assets directly from published designs.

Notifying a team → The Slack MCP — post deployment updates or task results without leaving the session.

The question isn't "which MCP servers exist" — it's "which task do I repeat constantly that could be solved without switching windows." That question gets you a better answer than any generic ranking.

When to use MCP and when not to

The rule that sums it up best: use a CLI when latency and tokens matter and you can make a direct shell call; use an MCP server when you want the same tool available across Claude Code, Cursor and other clients with one config; use a Skill when the workflow is a set of instructions, not an external tool to call.

Full article (in Spanish) with more detail: elrack.es/herramientas-ia/mejores-mcp-claude-code-2026

I asked Claude Code to refactor a feature it built last week. It hated its own code.

Alvarito1983 — Mon, 27 Apr 2026 08:50:42 +0000

Last week I opened a feature I'd built six days earlier and asked Claude Code to extend it.

I hadn't touched the file since. The code was working. Tests passing. Nothing was on fire. I just wanted to add a small capability — fifteen minutes of work, maybe.

What I got back wasn't an extension. It was a quiet roast.

"Before extending this, I'd recommend refactoring. The current implementation has a few issues: the error handling is inconsistent, the function is doing more than its name suggests, and there's a duplicated validation block that should be a helper. Want me to fix those first?"

Reader, that code was written by Claude Code. Same project. Same model tier. Six days earlier. By the same agent that was now telling me, with polite confidence, that it was a mess.

I sat with that for a minute. Then I started thinking about what it meant. Because the more I thought, the more I realized that this — this exact moment — is the thing nobody is writing about with AI coding agents.

The "memory problem" everyone complains about

If you've used Claude Code, Codex, Cursor in agent mode, or any of the rest, you've hit it: agents don't have continuity between sessions. Every new conversation starts cold. They don't remember what they decided last Tuesday. They don't remember why a particular abstraction exists. They don't remember that you already debated naming this function and settled on something specific.

Most of the discourse treats this as a problem to solve. We bolt on memory systems. We pile up CLAUDE.md files. We build context-loading scripts. The implicit assumption is that the agent should remember, and the work is to compensate for the fact that it doesn't.

I'm starting to think that framing is exactly backwards.

What actually happened in that session

When Claude Code criticized its own code from six days earlier, it wasn't being inconsistent. It wasn't malfunctioning. It was being honest — in a way no human collaborator can.

Think about what just happened:

A reviewer with no ego attachment to the code looked at it fresh.
It had no memory of why we wrote it that way, what we'd ruled out, what compromises we made under time pressure, or what I muttered at 11pm when the test finally passed.
It just looked at the code on its merits and said: this could be better.

That's not a bug. That's the cleanest code review you'll ever get.

A human reviewing their own code from a week ago has every cognitive bias working against them. They remember the constraints. They remember the deadline. They remember that they "knew" the helper was duplicated but didn't want to break the function signature. They protect their past decisions because their past decisions are theirs.

Claude Code, with no continuity, has none of that. Every session is a new pair of eyes that hasn't been bought off by yesterday's reasoning.

The reframe

Once I saw this, I started doing it on purpose.

When I finish a feature now, I don't immediately ship it. I commit, sleep on it, and the next morning I open a new Claude Code session and ask it to review the code as if it had never seen it. Because for that session, it hasn't.

The reviews are brutal. They are also, almost always, right.

It catches:

Functions that are doing two things and lying about it in their name
Error handling that's defensive in some places and absent in others
Helpers I should have extracted but didn't
Naming that made sense in context but doesn't survive cold reading
Tests that pass but verify the wrong thing

The same agent that wrote the code can't see these issues while it's writing, because it has the same tunnel vision a human does in flow. But strip its memory of the session, hand it the file, and it becomes the reviewer it could never be in real-time.

The "memory problem" is actually a feature gate to a different mode of useful behavior. We've been trying to remove it instead of using it.

Why this changes how I think about CLAUDE.md

I've written about CLAUDE.md before, and I want to refine what I said there, because this experience clarified something for me.

CLAUDE.md is not the agent's memory. That framing is wrong.

CLAUDE.md is the project's memory of decisions that shouldn't be relitigated every session. Things like:

"We use Tailwind v3, not v4. Don't migrate."
"The auth layer is intentionally simple. Don't add OAuth without asking."
"Tests live next to source files, not in /tests."

These are decisions, not style. CLAUDE.md exists so the agent doesn't waste a session arguing with itself about settled choices.

But CLAUDE.md should not contain things like:

"This function does X" (the code says that)
"Last week we refactored Y" (that's history, not a decision)
"The pattern we use is Z" (let the code be the source of truth)

The mistake is using CLAUDE.md as a memory dump. When you do that, you're trying to give the agent continuity — and you lose the fresh-eyes review benefit. You've turned your honest reviewer into a yes-man who already agrees with everything you've decided.

The right CLAUDE.md is short. It pins down decisions. It leaves judgment alone, so a new session can still tell you when your code is bad.

The mental model shift

Stop thinking of an AI coding agent as one consistent collaborator across time.

Start thinking of it as a high-quality reviewer you can summon, fresh, as many times as you want — provided you preserve the decisions, not the reasoning.

This changes the workflow:

Write code with the agent in a session.
Commit when it works.
Open a new session the next day. Ask it to review.
Take the criticism seriously. It's coming from someone who isn't defending yesterday's choices.
If the criticism is wrong, that's a signal that a decision is missing from CLAUDE.md.
If the criticism is right, fix it. The fact that the same agent wrote the code is irrelevant.

I've started shipping noticeably cleaner code since I adopted this. Not because Claude Code got smarter. Because I stopped trying to glue together its sessions and started using the gaps between them.

The closing thought

There's a lot of energy right now going into making AI agents more continuous, more memory-rich, more "aware" across sessions. Long-running agents. Persistent context. Memory layers.

I'm not against any of that. But I think the rush is hiding something valuable. The discontinuity between sessions is the thing that lets the agent be a real reviewer instead of a sympathetic teammate. Once you give it perfect memory, it stops being able to look at your code from outside, and it starts protecting your past decisions the way a human would.

Maybe the goal isn't to give agents continuity. Maybe it's to give them just enough of it — your settled decisions — and protect the rest. Let them forget how the code got that way. Let them tell you, fresh, that it's bad.

Mine did. It was right.

Has Claude Code ever roasted its own past output in your projects? I want to hear the worst one — drop it in the comments.

The AI Coding Tools Panorama in 2026: From Claude Code to the Free Alternatives That Actually Replace It

Alvarito1983 — Sat, 25 Apr 2026 16:18:39 +0000

The AI coding tool space in 2026 looks nothing like it did 18 months ago. Autocomplete is a solved problem. The interesting question now is: which agent do you trust to read your codebase, plan a refactor, run your tests, and not torch your API budget while doing it.

I've been using these tools daily for the last year on a real project — a Docker management suite I'm building solo, where the cost of a bad refactor is hours of cleanup. That context matters, because most "best AI coding tools" lists rank by benchmark scores. Benchmarks measure isolated tasks. They don't measure what happens at hour three of a complex migration when the agent forgets which files it already touched.

This is the honest panorama from someone shipping production code. From the ones everyone knows to the ones that quietly outperform them. Then two opinionated rankings: the five paid tools that justify their price, and the five free ones that make you question whether you need to pay at all.

Let's get into it.

The full panorama

The space has split into clear layers. Most developers running serious AI workflows use 2–3 tools, not one — and once you understand the layers, the picking gets easier.

Layer 1: Inline assistants (autocomplete + chat in your editor)

These are what most people still think "AI coding" means. They suggest the next line, complete a function, answer a quick question. Low cognitive overhead, high frequency, low ambition.

GitHub Copilot is the default. 76% of developers have heard of it, 29% use it at work, and at $10/month for Pro it's the cheapest entry point that doesn't feel like a compromise. It ships in every editor that matters and just works. The growth has stalled — adoption has plateaued — but it's still the safest choice for someone who wants AI in their editor and doesn't want to think about it.

JetBrains AI Assistant + Junie is the equivalent for the JetBrains crowd. 11% adoption combined. If you live in IntelliJ, PyCharm, or WebStorm, it's the natural fit because it understands JetBrains' code intelligence in ways Copilot doesn't.

Tabnine still exists and still gets recommended for teams that need on-prem or air-gapped deployment. Outside that niche, it's been overtaken.

Continue.dev is the open-source Copilot-shaped option. Lives inside VS Code or JetBrains as an extension, brings your own API key, 31K GitHub stars. Less polished than Copilot, but you're not on a per-seat license and you choose your model.

Layer 2: AI-native IDEs (the editor itself is the product)

These are full editor replacements where the AI is woven into every keystroke, not bolted on as an extension.

Cursor is the reference. A VS Code fork that took "AI in the editor" further than anyone else. Composer mode handles multi-file edits with visual diffs, autocomplete is supernaturally fast (Supermaven under the hood), and the agent can take on actual tasks. It's the most productive IDE-based AI experience right now, with one giant asterisk: pricing trust took a hit earlier in 2026 when Anthropic's pricing changes cascaded through Cursor's billing model and a lot of people got surprise bills. The product is still excellent. The pricing is the part you have to watch.

Windsurf is the value alternative. Same category as Cursor, $15/month base, free tier with full IDE features and the Cascade agent. It's been climbing the rankings precisely because it's what Cursor was before the pricing got messy.

Antigravity is Google's entry, launched November 2025. Free during preview. Supports Claude, Gemini, GPT-OSS — the most diverse model lineup of any free tool right now. 6% adoption already, which is fast for a tool this new.

Layer 3: Terminal agents (the new center of gravity)

This is where serious work is happening in 2026. You point an agent at your repo from the terminal, and it reads, edits, runs tests, iterates. The terminal-first approach composes with everything: git, your shell, your CI, your existing scripts.

Claude Code is the one I use daily and the one most experienced developers have settled on. Anthropic's official terminal agent, runs Opus and Sonnet, scores 80.8% on SWE-bench Verified — meaning it actually solves real GitHub issues, not toy problems. It's the best at multi-file reasoning and the best at not losing context on hour three of a complex task. Costs $20/month for Pro, but heavy use can run $100–200/month on the Max plan or via API. That's the elephant in the room.

OpenAI Codex CLI re-entered the conversation in early 2026 with parallel sandboxed execution and automatic PR creation. 3% adoption (data from before its desktop app launched), but climbing. Strong choice if you're already in the OpenAI ecosystem.

Gemini CLI is the underrated one. Google's terminal agent. 1,000 free requests/day with Gemini 2.5 Pro and a 1M context window. Less consistent than Claude on complex refactors, but for the price (zero) and the context size (massive), it's the best free terminal option right now. Don't skip it.

Aider is the elder statesman. 41K GitHub stars, terminal-first, and its defining feature is that every AI edit is a git commit. You get a complete audit trail of what the AI changed and why. Bring your own API key. If you live in git, this is the one to try first.

OpenCode is the most popular open-source terminal agent. 95K stars. Provider-agnostic — supports 75+ models. Free models included, plus you can plug in any API key. Cleaner TUI than Aider, less opinionated about git.

Cline (58K stars) and its forks Roo Code (22K) and Kilo Code (16K) live as VS Code extensions but operate as full agents — they edit files, run commands, and ask for approval at each step. BYOK with zero markup. If you want Cursor-style agentic work but inside vanilla VS Code without the subscription, this is the path.

Layer 4: Cloud agents (autonomous, parallel, expensive)

These run in the cloud, often handling multiple tasks in parallel sandboxes, opening PRs against your repo while you do something else.

Devin is the original autonomous agent. 67% PR merge rate on well-defined tasks. Treats coding tasks like Jira tickets it picks up and ships. $20/month base plus unpredictable per-task costs. Useful as an accelerator for narrow, well-scoped work; treat anything it ships as a draft.

Codex (cloud version) is OpenAI's hosted agent that runs in sandboxed environments and pushes PRs to GitHub. Strong if your stack is OpenAI-aligned.

OpenHands (formerly OpenDevin) is the open-source version of this category. 68K stars, MIT-licensed, BYOK. If you want a cloud-style autonomous agent without the SaaS dependency, this is it.

Layer 5: Specialized tools (the rest)

Replit still owns the "build an app from a prompt in your browser" niche, especially for prototyping and education. Costs accumulate fast at scale.

Bolt.new and Lovable.dev are similar — browser-based, AI-first, great for MVPs and demos. Lovable couples to Supabase tightly, which is convenient until you outgrow it.

v0 (Vercel) generates React components from prompts or Figma designs. Useful for design-to-code, less so for general work.

Tabby is self-hosted autocomplete you run on your own GPU. The privacy-first option for teams that can't send code to anyone.

Snyk Code and Qodo sit alongside the rest of the stack — security scanning and AI code review on PRs. Not coding tools strictly, but they're part of the modern AI workflow.

Top 5 paid tools that actually justify their price

I'm ranking these on a single criterion: would I be measurably less productive without them. Not "is the demo impressive." Not "did they raise a Series B." Would my output drop if I uninstalled it tomorrow.

1. Claude Code — $20–200/month

Best for: complex multi-file work, anything where the model losing context costs you an hour of cleanup.

Claude Code on Opus is the only tool I trust with a refactor that touches more than three files. It plans, executes, runs my tests, and recovers from its own mistakes. The 200K context window plus extended thinking actually changes how I architect things — I can describe a problem at a higher level than I used to.

The price is real. Heavy use can run $100–200/month on Max. The honest framing is: if you're a working developer billing for your time, $200/month for the tool that saves you a few hours a week is the cheapest line item on your invoice. If you're a hobbyist, this isn't the right tier.

2. Cursor — from $20/month

Best for: developers who think visually and want diffs they can scan instead of accept.

If you do most of your work in an editor and the terminal-first model doesn't fit your brain, Cursor is the most productive AI IDE in existence. Composer mode for multi-file changes, instant autocomplete, model orchestration. The pricing trust issue I mentioned is real — monitor your credits, especially if you flip into agent mode for big tasks. With that caveat, it earns its place here.

3. GitHub Copilot — $10/month

Best for: the developer who wants AI in their editor and wants to never think about it again.

Copilot earned its place not by being the best, but by being the floor. $10/month, works everywhere, never surprises you with a bill, integrates with the GitHub ecosystem (PR summaries, issue context, repo activity). It's the silent default. Stop overthinking.

4. Windsurf — from $15/month

Best for: people who want what Cursor was before the pricing drama.

Windsurf does what Cursor does, charges less, and the free tier is genuinely usable for daily work. Cascade agent, plan mode, parallel multi-agent sessions with git worktrees. It's the IDE I'd recommend to someone starting from scratch in 2026 if cost predictability matters.

5. Devin — $20/month + variable

Best for: well-scoped, repetitive tasks you can describe in a paragraph.

Devin shipping a 67% PR merge rate on defined tasks is the data point that matters. It's not autonomy in the science-fiction sense — it's a junior engineer who works on tickets in parallel sandboxes and submits drafts. For the right kind of work (boring but real: dependency upgrades, test coverage, scoped refactors) it earns its keep. For ambiguous work, you'll spend more time correcting it than you save.

Top 5 free tools that genuinely replace a paid one

The bar here: would I recommend this to someone who can't or won't pay, knowing they'll get within 80% of the paid experience.

1. Gemini CLI — free (1,000 requests/day)

Best free terminal agent in 2026, full stop. Gemini 2.5 Pro, 1M context window, runs in your terminal, BYOK with a generous free tier from Google. It's not as consistent as Claude Code on the hardest tasks, but for 90% of work, the gap doesn't matter. And the 1M context window means it can ingest a small codebase in a single prompt — something even paid Claude Code can't always match.

2. Aider — free (BYOK)

Best for terminal-native, git-centric work. Pair it with the DeepSeek API and you're paying $5–15/month total for AI coding that competes with $200/month tools. Every edit is a git commit. Reviewable, revertible, auditable. If you've ever lost track of what an agent changed across a session, Aider's commit history is the answer.

3. Cline — free (BYOK, runs in VS Code)

Best free agent inside an IDE. 5M+ installs, Apache-licensed, every action requires human approval. Plug in your Claude or OpenAI key and you have Cursor's agent capability inside vanilla VS Code without the subscription. The forks (Roo Code, Kilo Code) add structured modes and broader model support — pick whichever feels right; they're all good.

4. GitHub Copilot Free — free (2,000 completions + 50 chats/month)

The free tier of Copilot is real and surprisingly generous for casual or learning use. If you're not coding 8 hours a day, the free quota covers it. The path most people should take: start here, find your edges, then decide whether to pay or move to BYOK.

5. OpenCode — free (BYOK, free models included)

The open-source terminal agent that's quietly become the most popular on GitHub (95K stars). Ships with free models you can use immediately, supports 75+ providers when you bring keys, polished TUI. If you want to try terminal agents without making any decisions about API keys or pricing on day one, OpenCode is the lowest-friction starting point.

What I actually run

For full transparency, since I think it matters more than abstract rankings: I use Claude Code on Max for the heavy lifting, Cline in VS Code for in-editor work where I want approval gates, and Gemini CLI for anything where I want to throw a huge codebase at a model in one prompt. Three tools, three roles, no overlap.

That's the meta-point. In 2026, the question is no longer "which is the best AI coding tool." It's "which combination handles each layer of my workflow without breaking under pressure." Get that right and the cost question answers itself — because the right setup pays for itself in saved hours, and the wrong setup torches credits without shipping anything.

If your current setup is one tool doing everything, you're probably either overpaying for capability you don't use or underpowered for the work you actually do. Pick the layer that hurts most and start there.

What does your stack look like? Curious especially about people running fully BYOK setups — what's the monthly bill landing at versus the equivalent SaaS subscriptions?

Quadlet: The Podman Feature That Finally Makes Sense on a Homelab

Alvarito1983 — Thu, 23 Apr 2026 08:45:09 +0000

If you run a homelab on Docker Compose, you've probably accepted a quiet trade-off without noticing.

Your containers work. They start on boot. They restart if they crash. But they live outside the operating system's service model — orphaned from systemd, invisible to journalctl, dependent on a daemon that has to be alive before anything else in your stack can exist. Your 40 services are really 40 children of a single PID, not 40 first-class citizens of your Linux host.

This isn't a problem, exactly. It's just a ceiling. And over the last year a feature from the Podman side of the container world has quietly raised that ceiling in a way that's interesting enough to write about — even if you, like me, have zero intention of ripping out your Docker Compose setup tomorrow.

The feature is called Quadlet. It has been around since Podman 4.4, but 2026 is the year it's actually becoming the default way sysadmins on Red Hat-adjacent systems manage containers at home. And it does something I've not seen any other container tool do cleanly: it makes a container behave like a native systemd service.

Let's look at what that actually means, what it's good for, and — importantly — when you should probably ignore it.

What Quadlet actually is, in one paragraph

Quadlet is a systemd generator that reads declarative .container files (plus .network, .volume, .pod, .kube, .image and a few others) and converts them at boot time into real systemd service units. You don't run podman run and you don't write unit files by hand. You drop an INI-style file into a specific directory, run systemctl daemon-reload, and now you have a fully managed service with restart policies, dependency management, journal logging, healthchecks, and optional auto-updates — all driven by systemd, not by a background daemon.

That's the whole idea. The container is no longer something Podman runs on the side. It's something your operating system runs, the same way it runs sshd or nginx.

The simplest possible example

A minimal rootless Quadlet for something useful — let's say Vaultwarden — looks like this:

# ~/.config/containers/systemd/vaultwarden.container
[Unit]
Description=Vaultwarden password vault
After=network-online.target

[Container]
Image=docker.io/vaultwarden/server:latest
ContainerName=vaultwarden
PublishPort=8080:80
Volume=vaultwarden-data.volume:/data
AutoUpdate=registry

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=default.target

Then:

systemctl --user daemon-reload
systemctl --user start vaultwarden.service

That's it. There's no vaultwarden.service file on disk — Quadlet generates it on the fly. If you edit the .container file and reload, the generated unit updates. If a newer Podman version ships improvements to the generator, your service picks them up next reboot without you touching anything.

The volume referenced as vaultwarden-data.volume is another Quadlet file (a .volume), which generates a named volume managed by systemd the same way.

What you actually gain

This is the part that took me a while to appreciate. It's not "Podman has replaced Docker." It's that the integration layer is fundamentally different.

Unified logging. journalctl --user -u vaultwarden.service gives you the container's logs in the same place and same format as the rest of the system. No docker logs, no parallel logging story. When something breaks at 2am, you're searching one place.

Real dependency management. Want your Nextcloud container to only start after MariaDB is ready and network-online.target has fired? Write it in the [Unit] section like any other service. systemd handles the ordering, not a depends_on line that only waits for process start.

Restart policies and health-triggered recovery. Quadlet exposes HealthCmd, HealthInterval, HealthOnFailure, HealthRetries directly. Combined with HealthOnFailure=kill and systemd's Restart=always, you get a self-healing service loop that doesn't depend on anything watching from outside.

Auto-update with automatic rollback. Add AutoUpdate=registry and the podman-auto-update.timer checks daily for new image digests. If the new image fails the healthcheck after restart, Podman rolls back to the previous image automatically. No Watchtower, no cron hack, no custom script — and crucially, no blind latest tag chasing that silently deploys a broken image.

Rootless by default. The file above runs under your user account. A container breakout gets your UID, not root. For a homelab exposing services, this is a meaningful reduction in blast radius.

No daemon to keep alive. There's no dockerd that has to be up before your stack exists. Containers are direct children of systemd. If Podman itself has a bug tomorrow, the contract with your services is still "this is a systemd unit" — same tools, same lifecycle, same recovery procedures you already know.

The comparison that matters: Quadlet vs Docker Compose

I want to be honest here because most of what's written online about Podman/Quadlet treats Docker Compose as the enemy. It isn't. Compose and Quadlet solve overlapping problems with very different philosophies.

Docker Compose thinks in stacks. One docker-compose.yml describes a self-contained application: services, networks, volumes, dependencies, all in one file. You docker compose up -d and the stack exists. It's portable across any machine with Docker. You can commit it to a git repo and anyone can reproduce your environment. The mental model is: an application is a folder.

Quadlet thinks in system services. Each container is its own unit file. Networks and volumes are their own unit files. The relationships are expressed through systemd's dependency graph, not through a single manifest. The mental model is: a container is a service that happens to run in a container.

For development, portability, and throwaway environments, Compose wins. It's simpler, the tooling is mature, and the ecosystem is vast. For a long-lived single-host deployment where you want containers to behave like every other service on your Linux box, Quadlet wins.

The honest answer for most homelabbers is that both are valid, and which one fits depends on what you actually value.

When Quadlet is the wrong answer

Skip this feature if any of the following apply:

Your homelab runs on Windows / WSL2 / macOS. Quadlet is Linux + systemd. Period. If you're on Docker Desktop, this isn't for you.
You're deeply invested in Compose-specific features like profiles, extends, x-* anchors, or the Compose CLI's build workflows. podman-compose exists but compatibility isn't 100%, and Quadlet isn't trying to replicate Compose semantics.
You want GUI-first management. Portainer, Dockge, and the like are built around Docker. Cockpit has Quadlet integration now, but the ecosystem is thinner.
You share stacks across machines with non-Linux users. Compose files are more portable as artifacts than a folder of .container units tied to one host's systemd tree.
GPU passthrough for media transcoding is a hard requirement and you have it working on Docker. It's doable on Podman, but expect extra work. If your Jellyfin is happy today, don't break it for philosophy.

When Quadlet is genuinely the right answer

Reach for it when:

You run a Linux-native homelab on Fedora, Rocky, Alma, CentOS Stream, Debian, or openSUSE and your containers are long-lived services rather than dev environments.
You care about boot ordering. "Start reverse proxy after databases after network is up" is a one-liner in systemd, and a fragile convention in Compose.
You want auto-update with rollback without bolting on a third-party tool.
You're tired of the Docker daemon being a single point of failure for your entire container story.
You're already comfortable with systemd as an operator. This is the key one. If systemctl, journalctl, and unit file syntax feel natural to you, Quadlet is going to feel like containers finally speaking your language. If they don't, the learning curve is real and not worth it for a Plex install.

The hybrid setup that actually makes sense

This is where I've landed, and I think it's where most practical people will land:

Docker Compose for development and prototyping. Fast iteration, familiar tooling, easy to share. If I'm testing a new self-hosted tool for the first time, it's going into a Compose file in a scratch directory.
Quadlet for the services I've committed to. Once something graduates from "I'm trying this out" to "this runs my household," it's worth the 15 minutes to port it to a .container file and let systemd own its lifecycle.

You don't have to pick one. On a Linux homelab you can run both side by side. The Docker daemon and Podman's rootless stack don't fight each other — they just don't talk.

The honest closing thought

Quadlet isn't going to replace Docker Compose in most homelabs, and I don't think it should. Compose is good at what Compose is good for. What Quadlet does is close a gap I didn't realize I had: my containers were never really part of my operating system. They were tenants. With Quadlet, for the services where it matters, they become residents.

That's a small distinction until it isn't — until the night something breaks and you realize your recovery story is the same one you use for every other service on the box, instead of a separate container-shaped exception.

If you run Linux and you've been curious about Podman but couldn't articulate what the actual upgrade was, this is it. Not the daemon thing. Not the rootless thing in isolation. The integration.

Try it on one service. See how it feels. If it clicks, you'll know. If it doesn't, your Compose file is still there, and nothing has been lost.

Have you moved any part of your stack to Quadlet, or tried and bounced off it? I'd like to hear which services worked cleanly and which were more trouble than they were worth — drop it in the comments.

The WSL2 Guide I Wish I Had: 4 Gotchas That Will Eat Your Afternoon

Alvarito1983 — Wed, 22 Apr 2026 12:38:57 +0000

WSL2 is a fantastic development environment on Windows. It's also a system with sharp edges that the official docs rarely highlight — the kind you only discover after losing an afternoon to a process eating 300% CPU for no apparent reason.

This guide documents four specific problems I've hit repeatedly over the last year while using WSL2 as my main development environment for Docker-based projects. For each one: the root cause, why the obvious fix doesn't work, and what actually solves it.

This isn't an introduction to WSL2. If you're already using it daily and something feels off, keep reading.

1. Docker Desktop, cgroups, and processes that ignore resource limits

The symptom

You run a container on Docker Desktop for Windows (which uses WSL2 under the hood). The container executes a CPU-intensive process — a vulnerability scanner, a compiler, a batch job.

You watch htop and the process is consuming 300%+ CPU, dragging the entire system down.

You think: "no problem, I'll throttle it."

services:
  heavy-worker:
    image: my-scanner:latest
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
    cpu_count: 1

You restart the container.

Still 300% CPU.

You try nice, ionice, cpulimit... nothing works.

The root cause

Docker Desktop runs containers inside a WSL2-hosted VM using cgroup v2, often with limited controllers.

The result:

deploy.resources.limits → ignored
cpu_count → ignored
nice / ionice → ineffective

You can verify:

cat /sys/fs/cgroup/cgroup.controllers

You'll often see fewer controllers than on a native Linux system.

What actually works

Option A (best): Limit the WSL2 VM

[wsl2]
processors=4
memory=8GB
swap=2GB

Then:

wsl --shutdown

Now the VM is capped → containers behave predictably.

Option B: Use tool-level throttling

Examples:

--parallel=1
--low-mem

These bypass scheduler issues entirely.

Option C: Replace the tool

If it's designed to max all cores and can't be tuned → wrong tool for WSL2.

Key takeaway

Don't trust container limits on WSL2. Control the VM or use self-throttling tools.

2. Disk performance: `/mnt/c` vs native WSL filesystem

The symptom

Working in:

/mnt/c/Users/you/projects

npm install → 8 minutes
git status → 4 seconds

Move to:

~/projects

npm install → 25 seconds
git status → instant

The root cause

/mnt/c uses the 9P protocol → every filesystem call crosses the Windows ↔ Linux boundary.

Heavy IO workloads (Node, Git, Docker builds) get destroyed by latency.

Native WSL FS = ext4 inside VHDX → near-native Linux speed.

Real benchmark

Operation	`/mnt/c`	WSL native
`npm install`	~8 min	~25 sec
`git status` (10k files)	~4 sec	< 100 ms
`docker build` context	~90 sec	~3 sec

What actually works

Rule: keep code inside WSL.

~/projects/myapp

Access options:

VS Code + WSL extension ✅ (best)
\\wsl$\Ubuntu\home\you\projects (OK)

If you MUST use /mnt/c:

Move heavy dirs (node_modules, .git) to WSL
Use symlinks

Key takeaway

/mnt/c is for compatibility, not performance.

3. Networking: ports, shifting IPs, and host access

The symptom

localhost:3000 → sometimes works, sometimes not
WSL IP changes every reboot
LAN access → broken

The root cause

WSL2 networking is:

NATed via Hyper-V
Not bridged
Dynamic IP
Partial localhost forwarding

What actually works

Ensure localhost forwarding:

[wsl2]
localhostForwarding=true

Get WSL IP:

ip addr show eth0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1

Expose to LAN (port proxy):

$wslIP = (wsl hostname -I).Trim().Split(' ')[0]

netsh interface portproxy add v4tov4 `
  listenport=3000 listenaddress=0.0.0.0 `
  connectport=3000 connectaddress=$wslIP

New-NetFirewallRule -DisplayName "WSL 3000" `
  -Direction Inbound -LocalPort 3000 `
  -Protocol TCP -Action Allow

Best solution (modern WSL):

[wsl2]
networkingMode=mirrored

✔ Same network as host
✔ No NAT issues
✔ LAN works directly

Key takeaway

WSL2 networking = NAT. Use mirrored mode if available.

4. Memory: the `vmmem` problem

The symptom

Start day → 4 GB used
Work with Docker
Stop everything
vmmem still using 12 GB

Never released.

The root cause

WSL2:

Allocates memory dynamically
Does not release it back
Linux keeps cache (normal behavior)
Windows cannot reclaim it

What actually works

Cap memory:

[wsl2]
memory=8GB
swap=4GB

Enable auto reclaim:

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

Manual reclaim:

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

Last resort:

wsl --shutdown

Key takeaway

WSL will NOT give memory back unless you force it or configure it.

Minimal `.wslconfig` (recommended)

[wsl2]
memory=8GB
processors=4
swap=2GB

localhostForwarding=true
networkingMode=mirrored

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

📍 Path:

C:\Users\<you>\.wslconfig

Apply with:

wsl --shutdown

Closing thoughts

Most of these issues come from one fact:

WSL2 is a VM pretending to be native Linux.

And the cracks show when:

You push CPU
You do heavy IO
You rely on networking assumptions
You expect Linux memory behavior to match Windows

WSL2 is still excellent — but only if you understand:

cgroups quirks
/mnt/c performance trap
NAT networking
Memory ballooning

Once you do, most "random issues" become predictable.

If you've hit other WSL2 gotchas, drop them in the comments 👇

The one that surprised me most? Spending 3 days tuning container limits… that were being completely ignored.

💡 Did this save you an afternoon? A follow or reaction helps me write more of these.

Everyone is using Claude Code wrong.

Alvarito1983 — Mon, 20 Apr 2026 14:17:15 +0000

Not because they're bad developers. Because the mental model is wrong from the start.

Most people open Claude Code and treat it like a smarter autocomplete. They ask it to write a function. Fix a bug. Generate a component. Then they wonder why the output needs so much correction, why the context gets lost after a few sessions, why it feels like babysitting rather than collaborating.

The problem isn't Claude Code. It's the job description you gave it.

The wrong mental model

When you use Claude Code as a coding assistant, you're asking it to be a fast typist. It writes code, you review it, you correct it, you move on.

That works. It's faster than writing everything yourself. But it's not where the leverage is.

The leverage is in treating Claude Code as a contractor, not a typist. A contractor who can execute an entire feature end-to-end — backend, frontend, tests, documentation — if you give them the right briefing.

The difference between a typist and a contractor isn't skill. It's context.

What Claude Code actually needs

Claude Code has no persistent memory between sessions. Every time you start a new conversation, it starts completely fresh. It doesn't know your architecture decisions, your naming conventions, your known bugs, or where you left off last time.

Most people solve this by re-explaining everything at the start of each session. That's the wrong solution. It's slow, it's incomplete, and you always forget something important.

The right solution is a single file that does the re-explaining for you.

I call it CLAUDE.md. It lives at the root of every project. Claude Code reads it automatically at the start of every session.

It has four sections:

Current State — what's working, what's broken, where to pick up. Updated at the end of every session.

Architecture Decisions — not what you built, but why. "We use in-memory sessions because adding a persistence layer would complicate the Docker setup for homelab users." The reasoning that would otherwise live only in your head.

Conventions — specific rules Claude Code must follow. Not "write clean code." That's useless. Instead: exact patterns learned from real debugging sessions. Things that would take 30 minutes to rediscover without documentation.

Known Issues — bugs and limitations that are known but not yet fixed. Prevents Claude Code from "fixing" something intentionally left as-is.

Without this file, every session starts at zero. With it, Claude Code picks up exactly where you left off.

The second mistake: one task at a time

Most people use Claude Code sequentially. Finish one thing, start the next.

Claude Code supports sub-agents — multiple parallel workstreams running simultaneously. If you need to build five related components, you don't have to build them one by one.

The mental shift is from "what's the next task" to "what can run in parallel." A frontend and a backend for the same feature. Unit tests while the implementation is being written. Documentation while the code is being reviewed.

This is where the output multiplier kicks in. Not 2x faster — closer to 5x, because the bottleneck is no longer Claude Code's speed. It's your ability to architect work that can run in parallel.

The third mistake: no standards document

When you use Claude Code across multiple sessions or multiple parts of a project, consistency breaks down fast. The button style from session one doesn't match session three. The error handling pattern in one module contradicts another.

The fix is a standards document in CLAUDE.md. Not a style guide for humans — a set of rules Claude Code must follow exactly, every time, without being reminded.

Color values. Component patterns. API response shapes. Auth flows. Every decision that should be consistent across the codebase, written down once, enforced automatically.

Without it, you spend half your time correcting drift. With it, Claude Code enforces your standards better than you would yourself — because it doesn't get tired or forget.

The fourth mistake: no forcing function for updates

The obvious weakness of CLAUDE.md is staleness. If you don't update it, it becomes worse than useless — it confidently points Claude Code in the wrong direction.

Discipline doesn't work. The sessions where you forget to update are exactly the sessions where something important happened.

The fix is simple: at the end of every session, ask Claude Code to update the Current State section before closing.

"Before we finish, update the Current State section in CLAUDE.md to reflect what we did today, what's working, and where to pick up next time."

Thirty seconds. While the context is still fresh. The model is better at summarizing what just happened than you are at remembering to write it down.

It catches maybe 80% of sessions. The other 20% are interrupted sessions — closed terminal, crashed IDE, ran out of time. Those you can't fully solve. But 80% is enough to make the system work.

What changes when you get this right

The output doesn't feel like AI-assisted coding anymore. It feels like having a contractor who knows your codebase, follows your standards, picks up exactly where you left off, and can work on multiple things at once.

The work you actually do shifts. Less time writing boilerplate. Less time correcting style drift. Less time re-explaining context. More time on architecture, on product decisions, on the problems that actually require human judgment.

That's the job description Claude Code was built for. Not typist. Architect's executor.

Most people never get there because they never give it the right briefing.

The CLAUDE.md approach and sub-agent patterns came out of building a 15-tool Docker management platform over several weeks. If you want the specifics on how to structure the file, I wrote about it here: [link to previous article]

I let Claude AI decide whether to patch my Docker vulnerabilities — here's what it found

Alvarito1983 — Sat, 18 Apr 2026 18:02:54 +0000

Every security scanner will tell you what's vulnerable.

None of them will tell you what to actually do about it.

You get a list. CVE IDs, severity badges, affected packages. Then you're alone with the question that actually matters: is this exploitable in my setup, can I safely apply the fix, and does patching this break anything?

I've been building a self-hosted Docker management platform. Last week I wired up an AI layer on top of the vulnerability scanner — not to automate patching, but to automate the reasoning about whether to patch. Here's what happened.

The problem with "critical"

Critical doesn't mean the same thing in every context.

CVE-2025-58050 is a critical vulnerability in pcre2. On paper: patch immediately. In practice: it's in a socket proxy image maintained by a third party. I don't control that Dockerfile. I can pull the latest image and hope the maintainer already shipped the fix — or I can wait. Neither option is obvious from the CVE report alone.

CVE-2026-27143 is a critical vulnerability in Go stdlib. Fix available: upgrade to 1.25.9. Sounds straightforward. The complication: the binary that ships this version of stdlib is cloudflared, Cloudflare's tunnel client. I didn't write it. I can't easily recompile it. The fix depends on Cloudflare publishing an updated release.

Both are "critical." Neither has the same answer. A scanner can't tell you that. A rule can't tell you that. It requires judgment.

What Level 1 does

The first layer of automation is rule-based. No AI, no API calls, no external dependencies.

When a scan completes and finds a critical vulnerability, Level 1 fires an alert. It knows: this image has N critical CVEs, the threshold is 1, therefore alert. Fast, deterministic, always on.

This covers the obvious cases. A container with a known critical CVE should be flagged. That part doesn't need AI.

What Level 1 can't do is answer: should I patch this right now, and at what risk?

What Level 2 does

When Level 1 detects a critical vulnerability, Level 2 kicks in if an Anthropic API key is configured. It builds a structured prompt with everything the model needs to reason about the situation: the image name, the CVEs, the packages affected, the versions with fixes available, and whether those fixes represent a patch bump, a minor version change, or a major version jump.

Claude Haiku then returns a structured analysis:

Exploitability — is this remotely exploitable or does it require local access?
Urgency — how quickly does this need to be addressed?
Version Risk — what's the upgrade risk? Patch bump vs minor vs major?
Fix Impact — is the fix likely to break anything?
Recommended Action — a concrete next step with reasoning

This analysis goes into the notification. The email you receive isn't "critical CVE detected." It's a security brief.

What it found on my stack

Three critical vulnerabilities across two images. Here's what the AI analysis said about each:

CVE-2026-27143 and GHSA-p77j-4mvh-x3m3 — both in a tunnel manager image, both in third-party binaries (Go stdlib and gRPC shipped inside cloudflared). Exploitability: remote. Urgency: critical. Version risk: patch bump. Fix impact: low — but the fix depends on the upstream vendor shipping an updated binary. Recommended action: defer until the vendor publishes an updated release, monitor for new cloudflared versions.

CVE-2025-58050 — in a socket proxy image maintained by a third party. Package: pcre2. Fix available: 10.46-r0. Exploitability: remote. Urgency: critical. Fix impact: low. Recommended action: pull the latest image version to pick up the fix if the maintainer has already shipped it. If not, defer and accept the risk with documentation.

In both cases the AI correctly identified that I don't control the vulnerable code. It didn't tell me to patch something I can't patch. It told me what I actually needed to know: these are third-party dependencies, here's the risk profile, here's what to do while you wait.

The part I didn't expect

The most useful output wasn't the vulnerability analysis. It was the differentiation between "you can fix this" and "you're waiting on someone else."

That distinction is obvious to a human who investigates the CVE. It's not obvious to a scanner. It requires knowing what the affected binary is, who maintains it, and whether the fix is in your control.

The AI got this right without me telling it explicitly. It reasoned from the package name and context to the correct conclusion about ownership and fixability.

That's the gap that rules-based automation can't close. You can write a rule that says "alert on critical CVEs." You can't write a rule that says "if the vulnerable binary is a third-party dependency with no upstream fix available, recommend deferral with documentation."

What I learned about AI in security workflows

The value isn't automating the patch. It's automating the triage.

A human security engineer looking at these three CVEs would spend 20-30 minutes researching each one: checking exploitability databases, looking at the upstream project's changelog, assessing version risk, writing up a recommendation. The AI does this in seconds, for every scan, every time.

The output isn't always perfect. The model can misread version risk or miss context about your specific setup. Every decision is visible in the feed with the full reasoning attached — you can always override, and you should review anything the model flags as critical before acting.

But the triage is right often enough to dramatically reduce the cognitive load of managing vulnerabilities across a fleet of containers. You stop reading CVE lists and start reading executive summaries with recommended actions.

That's a different kind of tool.

Building this as part of an open source self-hosted Docker management platform. If you're working on similar infrastructure automation problems, drop a comment.

CLAUDE.md: the file that makes AI actually remember what you built and why

Alvarito1983 — Fri, 17 Apr 2026 14:51:25 +0000

Every AI coding session starts the same way.

You open a new chat. You explain the project. You explain the stack. You explain the decisions you made last week and why. You spend 15 minutes giving context before writing a single line of code.

Then the session ends. The context disappears. Next time, you start over.

I got tired of this. So I built a system around a single file called CLAUDE.md — and it changed how I work with AI completely.

What CLAUDE.md is

It's a plain text file that lives at the root of every project I work on. Claude Code reads it automatically at the start of every session.

Not a README. Not documentation for other developers. This file is written specifically for the AI — it contains everything the model needs to pick up exactly where we left off without me having to re-explain anything.

The difference sounds small. It isn't.

What goes in it

The file has four sections that I've refined over months of daily use.

Current State is the entry point. It's the first thing Claude Code reads and it answers three questions: what's working, what's broken, and where to pick up next session.

## Current State — last updated [date]
- What's working: Hub SSO, all agents, Log Center
- What's broken: standalone tool still on old version
- Next session: bump versions, publish release

This section gets updated at the end of every session. More on that later.

Architecture Decisions is where I explain the why, not the what. Not "we use JWT auth" but "we use JWT auth with in-memory sessions because adding a persistence layer would complicate the Docker setup for homelab users — revisit when user base grows." The reasoning, the trade-offs, the constraints that shaped the decision.

This is the section that saves me from re-litigating decisions. When Claude Code suggests something that contradicts a past decision, it sees the reasoning and understands why the alternative was rejected.

Conventions is a list of rules Claude Code must follow. Specific ones, not generic ones. Not "write clean code" — that's useless. Instead: things learned from actual debugging sessions that would take 30 minutes to rediscover. Exact patterns that must be followed. Edge cases that look fixable but aren't.

Known Issues is a list of bugs and limitations that are known but not yet fixed. This prevents Claude Code from "fixing" something that's intentionally left as-is, or spending time diagnosing something I already understand.

The forcing function problem

The obvious weakness: if you don't update the file, it goes stale. And stale context is worse than no context — it confidently points the AI in the wrong direction.

I tried discipline. It doesn't work reliably. The sessions where you forget to update are exactly the sessions where something important happened — a late-night debugging run, an interrupted session, a decision made in conversation that never touched the codebase.

The solution I landed on: ask Claude Code to update the Current State block at the end of every session before closing.

The prompt is simple:

"Before we finish, update the Current State section in CLAUDE.md to reflect what we did today, what's working, and where to pick up next time."

It takes 30 seconds. It happens while the context is still fresh. And the model is better at summarizing what just happened than I am at remembering to write it down.

This catches maybe 80% of sessions that would otherwise leave stale state. The other 20% are interrupted sessions — closed terminal, crashed IDE, ran out of time. Those you can't fully solve. But 80% is enough to make the system work.

The problem it doesn't solve

There's a class of architectural knowledge that CLAUDE.md can't easily capture: the implicit decisions.

"We avoid Y because of the incident in March" is the most important kind of architectural knowledge and the hardest to write down. It's not a pattern — it's a scar. The context that makes it meaningful lives in someone's memory, or in a post-mortem that nobody links to the codebase.

A model reading CLAUDE.md can only match against what got written. If the decision was implicit — understood by everyone who was there, never documented because it seemed obvious at the time — the model has no surface to match against.

My partial fix: at the end of sessions I ask Claude Code:

"Is there anything we decided today that we'd regret not documenting in six months?"

It catches some of it. Not all. But it asks in the right direction — not "what did we do" but "what would we wish we'd written down."

What it looks like in practice

I'm building a self-hosted Docker management platform — 13 tools, each with its own frontend, backend, agent, and central Hub integration. The kind of project where losing context between sessions would be catastrophic.

With CLAUDE.md, a new session starts like this: Claude Code reads the file, understands the current state of all 13 tools, knows the conventions for auth patterns and Docker socket connections and visual standards, and picks up exactly where we left off. No re-explanation. No re-litigating past decisions.

Today's session: 7 new tools built from scratch, all integrated into the ecosystem, all following the same design system and agent patterns. Claude Code maintained consistency across all of them because the standards were written down, not carried in my head.

Without CLAUDE.md, that consistency would have required constant correction. With it, the model enforces the standards itself.

The one-line version

CLAUDE.md is not a README. It's not documentation. It's the answer to the question the AI needs to ask at the start of every session:

"What do I need to know to be useful right now?"

Write it for that question. Update it every session. The compounding effect over months of development is hard to overstate.

Building an open source self-hosted Docker ecosystem. If you're interested in the project or in how I use Claude Code to build it, follow along.

DEV Community: Alvarito1983

Meta's Muse Glimmer: a real agentic model that fits on your own GPU

Why this one is different from the last wave of "local" models

What it actually needs to run

Where this fits in a self-hosted setup

NVIDIA 610.57.04 for Linux: the point release actually worth installing

What actually got fixed

Outside of gaming fixes, two changes matter for general desktop stability:

Should you actually install it?

Full verdict and version comparison

Claude Code Now Runs Subagents in the Background by Default — What Actually Changed

What changes day to day

Sonnet 5 and Opus 5: 1M context is no longer the exception

The security fix that actually matters

Where I still draw lines

Bottom line

Kimi K3 is the largest open-weight model ever released — and you probably still can't run it

What "open weights" actually gets you here

The practical reality is different.

The bigger debate this reopened

Where this actually matters for a homelab

Verdict

The MCP servers actually worth installing in Claude Code (2026) Published

I asked Claude Code to refactor a feature it built last week. It hated its own code.

The "memory problem" everyone complains about

What actually happened in that session

The reframe

Why this changes how I think about CLAUDE.md

The mental model shift

The closing thought

The AI Coding Tools Panorama in 2026: From Claude Code to the Free Alternatives That Actually Replace It

The full panorama

Layer 1: Inline assistants (autocomplete + chat in your editor)

Layer 2: AI-native IDEs (the editor itself is the product)

Layer 3: Terminal agents (the new center of gravity)

Layer 4: Cloud agents (autonomous, parallel, expensive)

Layer 5: Specialized tools (the rest)

Top 5 paid tools that actually justify their price

1. Claude Code — $20–200/month

2. Cursor — from $20/month

3. GitHub Copilot — $10/month

4. Windsurf — from $15/month

5. Devin — $20/month + variable

Top 5 free tools that genuinely replace a paid one

1. Gemini CLI — free (1,000 requests/day)

2. Aider — free (BYOK)

3. Cline — free (BYOK, runs in VS Code)

4. GitHub Copilot Free — free (2,000 completions + 50 chats/month)

5. OpenCode — free (BYOK, free models included)

What I actually run

Quadlet: The Podman Feature That Finally Makes Sense on a Homelab

What Quadlet actually is, in one paragraph

The simplest possible example

What you actually gain

The comparison that matters: Quadlet vs Docker Compose

When Quadlet is the wrong answer

When Quadlet is genuinely the right answer

The hybrid setup that actually makes sense

The honest closing thought

The WSL2 Guide I Wish I Had: 4 Gotchas That Will Eat Your Afternoon

1. Docker Desktop, cgroups, and processes that ignore resource limits

The symptom

The root cause

What actually works

Key takeaway

2. Disk performance: /mnt/c vs native WSL filesystem

The symptom

The root cause

Real benchmark

What actually works

Key takeaway

3. Networking: ports, shifting IPs, and host access

The symptom

The root cause

What actually works

Key takeaway

4. Memory: the vmmem problem

The symptom

The root cause

What actually works

2. Disk performance: `/mnt/c` vs native WSL filesystem

4. Memory: the `vmmem` problem

Minimal `.wslconfig` (recommended)