<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Home on Preston Bernstein</title><link>https://prestonbernstein.com/</link><description>Recent content in Home on Preston Bernstein</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><managingEditor>contact@prestonbernstein.com (Preston Bernstein)</managingEditor><webMaster>contact@prestonbernstein.com (Preston Bernstein)</webMaster><copyright>© 2024 by Preston Bernstein. &lt;b&gt;All rights reserved.&lt;/b&gt;</copyright><lastBuildDate>Mon, 10 Aug 2026 00:00:00 -0400</lastBuildDate><atom:link href="https://prestonbernstein.com/index.xml" rel="self" type="application/rss+xml"/><item><title>A Clean ClamAV Scan Doesn't Mean the File Is Safe</title><link>https://prestonbernstein.com/blog/clamav-clean-scan-doesnt-mean-safe/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/clamav-clean-scan-doesnt-mean-safe/</guid><description>&lt;p&gt;A clean ClamAV scan means nothing matched a known signature. It does not mean the file is safe. I run a scan gate in front of my media-download pipeline: everything that lands from the download clients gets checked by a ClamAV daemon before it&amp;rsquo;s allowed into the library. For a long time I treated a clean verdict as the end of the question. It isn&amp;rsquo;t. ClamAV is a signature engine, and signature engines only catch what someone has already seen, fingerprinted, and shipped a rule for. Zero-days and packed or obfuscated executables walk right past it, and the gap is worse than it sounds because ClamAV is open source. Anyone can download the exact detection logic and test their malware against it before release. That&amp;rsquo;s not a hypothetical; researchers have measured samples built specifically to dodge open-source detectors evading ClamAV on the order of 70 to 85 percent of the time, without even needing inside knowledge of the engine.&lt;/p&gt;</description></item><item><title>Building a Self-Throttling Governor for Claude Max With No Published Ceiling</title><link>https://prestonbernstein.com/blog/self-throttling-claude-max-without-a-published-ceiling/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/self-throttling-claude-max-without-a-published-ceiling/</guid><description>&lt;p&gt;Anthropic will not tell you how many tokens or messages Claude Max 20x actually gives you, and I had to build a throttle for it anyway. I run several personal research projects on background schedules through &lt;code&gt;claude -p&lt;/code&gt;, unattended fires that call Claude Code from cron and systemd timers while I&amp;rsquo;m not watching. Those fires draw from the exact same quota as the interactive Claude Code sessions I use to do actual work. If a background job burns the pool at 2pm, my 2:15pm session pays for it. I wanted those jobs to back off automatically as usage climbed, and hand back the room the moment I sat down to work. The problem is that Anthropic gives you nothing to calibrate that against.&lt;/p&gt;</description></item><item><title>Fifteen of Eighteen Root Causes I Was Sure About Were Wrong</title><link>https://prestonbernstein.com/blog/adversarial-verification-home-lab-alerts/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/adversarial-verification-home-lab-alerts/</guid><description>&lt;p&gt;Fifteen of eighteen root causes I proposed for four firing alerts turned out to be wrong. Four alerts were going off across my home infrastructure at once: a stuck download post-processing backlog, and three separate automation alerts tied to a video-discovery pipeline. My first instinct on each one was the usual instinct: form a theory fast, patch it, watch the alert clear. Instead I forced myself to generate every plausible root cause I could find, then attacked each one before touching anything. Eighteen candidates went in. Three survived. That refutation rate is the actual finding here, more than any single bug I fixed.&lt;/p&gt;</description></item><item><title>Gaming Desktop or Dedicated Compute Box: Idle Power Decides, Not Sticker Price</title><link>https://prestonbernstein.com/blog/gaming-desktop-vs-dedicated-compute-box-idle-power/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/gaming-desktop-vs-dedicated-compute-box-idle-power/</guid><description>&lt;p&gt;Idle power draw, not the price tag on a mini PC, is what actually decides whether a dedicated low-power compute box saves you money over running everything on a gaming desktop. A gaming desktop idles somewhere around 80-200W depending on the board, PSU, and how many drives are spinning. A purpose-built low-power box, the N100-class mini PCs and similar, idles at 10-15W. That gap is real and it&amp;rsquo;s large. Whether it means anything for your electricity bill depends entirely on one question: does buying the mini PC let the desktop actually power off or sleep when you&amp;rsquo;re not gaming? If the answer is no, the math falls apart, and I found that out the hard way while pricing hardware for my own setup.&lt;/p&gt;</description></item><item><title>It Took Nine Fixes to Stop a LightRAG Crash. The First Eight Were All Real Bugs</title><link>https://prestonbernstein.com/blog/nine-fixes-lightrag-embedding-crash-one-afternoon/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/nine-fixes-lightrag-embedding-crash-one-afternoon/</guid><description>&lt;p&gt;A bulk-reprocess job against one of my LightRAG instances crashed three times in one afternoon, and I shipped eight legitimate fixes before I found the actual cause. That same afternoon I&amp;rsquo;d also fixed a false-positive bug in the GPU broker that arbitrates my home GPU between gaming and local inference. The two bugs had nothing to do with each other. They just happened to land on the same day, which made it tempting at first to blame one on the other. I want to walk through the LightRAG crash specifically, because the honest version of this story is that most of my fixes were correct and still didn&amp;rsquo;t solve it.&lt;/p&gt;</description></item><item><title>Mini-ITX Is the Wrong Form Factor for a Quiet AI Home-Lab PC</title><link>https://prestonbernstein.com/blog/mini-itx-is-the-wrong-form-factor-for-a-quiet-ai-homelab-pc/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/mini-itx-is-the-wrong-form-factor-for-a-quiet-ai-homelab-pc/</guid><description>&lt;p&gt;The choice that matters most in this build is form factor, and the trendy answer is wrong for the job. Every &amp;ldquo;quiet home-lab PC&amp;rdquo; guide points at mini-ITX: small, tucked in a corner, low power draw. I already own an RTX 3060 and want a box around it that stays quiet, stays cool, and lets me swap the CPU, RAM, storage, and eventually the GPU without replacing the motherboard underneath them. Mini-ITX fails on all three requirements at once, and it took reading real bench data and practitioner threads, not case marketing copy, to see why.&lt;/p&gt;</description></item><item><title>My GPU Broker Kept Killing Inference Jobs for Games That Weren't Running</title><link>https://prestonbernstein.com/blog/debugging-false-positive-gpu-contention-detection/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/debugging-false-positive-gpu-contention-detection/</guid><description>&lt;p&gt;A Go service I run at home kept canceling in-flight LLM inference jobs because it thought a game had launched, and most of the time nothing had launched at all. The service is a broker that arbitrates my desktop&amp;rsquo;s single GPU between gaming, Plex transcoding, and local inference through Ollama. When it detects gaming or Plex activity, it force-cancels whatever inference request is running and unloads the model from VRAM, no exceptions, because in my house whoever is playing a game or watching something wins that argument. That priority order is correct. The detector deciding when to enforce it was not.&lt;/p&gt;</description></item><item><title>No Embedding Server Survives a GPU Yield Gracefully. I Had to Build That Layer Myself</title><link>https://prestonbernstein.com/blog/surviving-a-gpu-yield-window-embedding-servers/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/surviving-a-gpu-yield-window-embedding-servers/</guid><description>&lt;p&gt;Every embedding server I tested handles a vanished GPU the same way: queue requests until a buffer fills, then reject them. Ollama does this. Text Embeddings Inference (TEI) does this. Infinity and llama.cpp do it too, with different buffer sizes and different error codes but the same shape. None of them pause a request and wait out a short GPU outage. They drop it, either immediately or once a queue limit is hit. I run one GPU at home across gaming, media transcoding, and every local model behind my personal tools, and a broker process decides who gets the card and when. That gap between reject-fast and wait-it-out is what forced me to build the missing layer myself.&lt;/p&gt;</description></item><item><title>Not Every Docker Container Belongs on the NAS</title><link>https://prestonbernstein.com/blog/not-every-docker-container-belongs-on-the-nas/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/not-every-docker-container-belongs-on-the-nas/</guid><description>&lt;p&gt;Family-facing and storage-coupled services stay on the NAS. Compute-heavy personal projects move to a separate host with real memory to spare. That&amp;rsquo;s the whole framework, and I only arrived at it after a Synology DS1522+ with 8GB of RAM spent months running roughly 35 Docker containers and periodically falling over under memory pressure. ContainerManager doesn&amp;rsquo;t fail loudly when it runs out of headroom. It stalls, swaps, and eventually kills something, and figuring out which container mattered enough to protect took longer than it should have.&lt;/p&gt;</description></item><item><title>Rebuilding a Home Network from the Modem Up, One Phase at a Time</title><link>https://prestonbernstein.com/blog/rebuilding-home-network-from-the-modem-up/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/rebuilding-home-network-from-the-modem-up/</guid><description>&lt;p&gt;I rebuilt my home network from the ISP modem outward instead of swapping in a new router and hoping the rest sorted itself out. The order was: modem into passthrough (a mode where the ISP box stops doing routing and just hands its public IP straight through), then a UniFi gateway and switch as the core, then Pi-hole DNS filtering running on a Raspberry Pi controller, then every downstream device reconnected one at a time. Bottom-up, slowest layer first, nothing skipped ahead of something it depended on.&lt;/p&gt;</description></item><item><title>Run One Observability Stack, Not One Per Repo</title><link>https://prestonbernstein.com/blog/one-observability-stack-not-one-per-repo/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/one-observability-stack-not-one-per-repo/</guid><description>&lt;p&gt;Run one shared Grafana and Prometheus stack for your whole home lab, not one per repo. I have around 30 GitHub repos and 15-20 always-on self-hosted services running mostly on one desktop plus a NAS, and I recently found two separate Grafana containers on that desktop, each spun up by a different project&amp;rsquo;s docker-compose file, each with its own dashboards nobody was cross-referencing. That&amp;rsquo;s the anti-pattern this post argues against, and it happened because &amp;ldquo;just add a Grafana container to the compose file&amp;rdquo; felt like the path of least resistance at the time.&lt;/p&gt;</description></item><item><title>RunPod Beats Gemini on Cost for My Vision Pipeline, and the Idle-Stop Feature It's Missing</title><link>https://prestonbernstein.com/blog/runpod-vs-gemini-vlm-inference-idle-auto-stop-gap/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/runpod-vs-gemini-vlm-inference-idle-auto-stop-gap/</guid><description>&lt;p&gt;I run vision-model inference for a personal image pipeline on RunPod GPUs instead of calling Google&amp;rsquo;s Gemini API, and the decision has nothing to do with accuracy. Gemini wins on accuracy. RunPod wins on cost, as long as I babysit it correctly, and the babysitting turned out to be the actual engineering problem. This is a companion piece to &lt;a href="https://prestonbernstein.com/blog/scrape-score-alert-resale-hunting-pipelines-local-vision-models/" &gt;the estate-sale scanner series&lt;/a&gt; on this blog, one narrow decision about where the vision step runs, not a rewrite of that whole pipeline.&lt;/p&gt;</description></item><item><title>Shipping Fast Isn't the Same as Being Done: Auditing a CLI My Agent Pipeline Built in an Afternoon</title><link>https://prestonbernstein.com/blog/auditing-what-an-agent-pipeline-shipped-in-an-afternoon/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/auditing-what-an-agent-pipeline-shipped-in-an-afternoon/</guid><description>&lt;p&gt;Shipping fast is not the same as being done, and I had to learn that the expensive way with a CLI tool an agent pipeline built for me in one afternoon. The pipeline is one I built myself: I give it a one-line description of what I want, it writes a spec, runs that spec through seven parallel agents whose only job is to attack it from different angles, spins up parallel build agents against the hardened spec, runs a full code review pass, then smoke-tests the real thing before calling it done. For a small outreach-automation CLI (local SQLite state, a human approval gate before anything goes out, a GitHub-facing sourcing loop), that pipeline produced working software in an afternoon. It ran. It did the job I asked for. It was also not something I trusted enough to extend to a second platform without checking it first.&lt;/p&gt;</description></item><item><title>Three Failure Modes Wearing One Name: Running Concurrent Claude Code Agents Without State Drift</title><link>https://prestonbernstein.com/blog/three-failure-modes-one-name-concurrent-claude-code-agents/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/three-failure-modes-one-name-concurrent-claude-code-agents/</guid><description>&lt;p&gt;Running four or five Claude Code agents at once across separate repos felt like one problem: things drifting out of state while I wasn&amp;rsquo;t watching. It turned out to be three separate failure modes wearing one name, and each one needed a different fix. Worktree sprawl (leftover git checkouts an agent session opened and nobody closed) was mostly a feature I hadn&amp;rsquo;t turned on, not a missing tool. Deploy drift (a running service that no longer matches what an agent thought it built) was a problem I&amp;rsquo;d already solved once, for one project, and just needed to generalize. Wasted compute across my machines is the one piece nothing solved, and it&amp;rsquo;s still open. Treating all three as one complaint is exactly what kept me from seeing that only one of them was actually about drift.&lt;/p&gt;</description></item><item><title>Tuning LightRAG Ingestion Concurrency Against a Rate-Limited Gemini API</title><link>https://prestonbernstein.com/blog/tuning-lightrag-ingestion-concurrency-against-gemini-rate-limits/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/tuning-lightrag-ingestion-concurrency-against-gemini-rate-limits/</guid><description>&lt;p&gt;Feeding a few hundred books into LightRAG through Gemini taught me that concurrency tuning is the wrong first lever, and the rate-limit table you&amp;rsquo;d normally tune it against doesn&amp;rsquo;t exist anymore anyway. I run a personal knowledge-graph project that ingests close to a thousand book-length documents through &lt;a href="https://github.com/HKUDS/LightRAG" target="_blank" rel="noreferrer"&gt;LightRAG&lt;/a&gt; (HKUDS), using Gemini for entity extraction and embeddings behind a LiteLLM proxy. The corpus is entity-dense enough that the LLM merge phase dominates ingestion time, and early runs kept marking documents FAILED with no obvious cause in the LightRAG logs. This post covers what I found chasing that down: the actual concurrency knobs, why Gemini&amp;rsquo;s rate limits are a moving target now, and the one setting that mattered more than any of it.&lt;/p&gt;</description></item><item><title>What a $364 Claude Code Session Taught Me About Running Agents Unattended</title><link>https://prestonbernstein.com/blog/what-a-364-dollar-claude-code-session-taught-me-about-agent-hygiene/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/what-a-364-dollar-claude-code-session-taught-me-about-agent-hygiene/</guid><description>&lt;p&gt;A single Claude Code session in my home lab cost $364. I found it on my own &lt;code&gt;/usage&lt;/code&gt; report, not from a billing alert, and it was enough to make me stop and read the full week behind it instead of writing it off as one bad run.&lt;/p&gt;</description></item><item><title>What If Two Independently-Built Agent Suites Reviewed Each Other's Code?</title><link>https://prestonbernstein.com/blog/dueling-agent-orchestration-suites/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/dueling-agent-orchestration-suites/</guid><description>&lt;p&gt;The idea is this: run two coding-agent orchestration suites that share none of the same prompts, config, or instruction derivation, and make them review each other&amp;rsquo;s pull requests the way two engineers with different judgment catch each other&amp;rsquo;s mistakes. Suite A opens a PR. Then suite B, built from scratch with no visibility into how A was built, reviews it cold. Suite A reads the review, decides what&amp;rsquo;s real, and applies fixes. The loop can repeat from there. I thought of this on my own, then went and checked whether it already existed somewhere, because that&amp;rsquo;s usually the fastest way to find out if an idea is obvious or overlooked.&lt;/p&gt;</description></item><item><title>Why the XPS 17 Offload Box Runs Proxmox, Not Plain Ubuntu</title><link>https://prestonbernstein.com/blog/proxmox-for-the-xps-17-offload-box/</link><pubDate>Mon, 10 Aug 2026 18:02:27 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/proxmox-for-the-xps-17-offload-box/</guid><description>&lt;p&gt;Proxmox VE won the decision, and the reason is simple: five separate workloads sharing one box is exactly the situation where isolation stops being a nice-to-have. I had an old Dell XPS 17 sitting around and a growing list of services that needed a new home. Instead of buying dedicated hardware, I closed the lid, racked the laptop, and pointed five different stacks at it. Picking the OS underneath that decision took longer than I expected, because the obvious answer (plain Ubuntu Server plus Docker Compose, matching every other machine I run) turned out to be the wrong one for this specific job.&lt;/p&gt;</description></item><item><title>A Native Hugo Image Pipeline: WebP, LQIP Blur-Up, and Mermaid Diagrams</title><link>https://prestonbernstein.com/blog/native-hugo-image-pipeline-webp-lqip-and-mermaid/</link><pubDate>Mon, 10 Aug 2026 18:00:00 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/native-hugo-image-pipeline-webp-lqip-and-mermaid/</guid><description>&lt;p&gt;This site had no image pipeline until this week. Every image in every post loaded at its original file size and format, usually a multi-megabyte PNG screenshot, with no responsive sizing and no loading placeholder. Diagrams worked through exactly one path: a Blowfish theme shortcode you had to remember to wrap your diagram in by hand, with no way to drop a diagram into a plain fenced code block the way you would in a GitHub README or almost anywhere else that renders Markdown. I fixed both problems in the same pass, because they share a mechanism: Hugo render hooks, which let a site override how the built-in Markdown renderer turns one specific element — an image, a code block — into HTML.&lt;/p&gt;</description></item><item><title>Deciding What Fits: Inside My Resale-Clothing Monitor</title><link>https://prestonbernstein.com/blog/deciding-what-fits-resale-clothing-monitor/</link><pubDate>Mon, 10 Aug 2026 16:36:57 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/deciding-what-fits-resale-clothing-monitor/</guid><description>&lt;p&gt;My resale-clothing monitor&amp;rsquo;s hardest problem isn&amp;rsquo;t finding new listings. It&amp;rsquo;s deciding which ones match my taste well enough to interrupt me about, and the design leans hard toward false positives over false negatives in a way I can defend today but haven&amp;rsquo;t stress-tested. This is part 3 of a series; &lt;a href="https://prestonbernstein.com/blog/scrape-score-alert-resale-hunting-pipelines-local-vision-models/" &gt;part 1&lt;/a&gt; covers the shared architecture, and &lt;a href="https://prestonbernstein.com/blog/deciding-whats-worth-a-saturday-estate-sale-scanner/" &gt;part 2&lt;/a&gt; covers a sibling project, an estate-sale scanner, that runs on the same foundation.&lt;/p&gt;</description></item><item><title>Deciding What's Worth a Saturday: Inside My Estate-Sale Scanner</title><link>https://prestonbernstein.com/blog/deciding-whats-worth-a-saturday-estate-sale-scanner/</link><pubDate>Mon, 10 Aug 2026 16:36:57 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/deciding-whats-worth-a-saturday-estate-sale-scanner/</guid><description>&lt;p&gt;My estate-sale scanner&amp;rsquo;s real job is deciding which of a week&amp;rsquo;s new listings are worth a Saturday drive, and the interesting part isn&amp;rsquo;t the scraping. It&amp;rsquo;s how the system scores unlabeled photos, and an asymmetric feedback loop that treats a bad sale and a good sale as very different kinds of evidence. This is part 2 of a series; &lt;a href="https://prestonbernstein.com/blog/scrape-score-alert-resale-hunting-pipelines-local-vision-models/" &gt;part 1&lt;/a&gt; covers the shared architecture and GPU constraints behind this and a second project.&lt;/p&gt;</description></item><item><title>Scrape, Score, Alert: The Pattern Behind Two Home-Lab Vision Pipelines</title><link>https://prestonbernstein.com/blog/scrape-score-alert-resale-hunting-pipelines-local-vision-models/</link><pubDate>Mon, 10 Aug 2026 16:36:57 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/scrape-score-alert-resale-hunting-pipelines-local-vision-models/</guid><description>&lt;p&gt;Two personal tools I&amp;rsquo;ve built, an estate-sale scanner and a resale-clothing monitor, run on the exact same architecture: scrape listings, score every photo with a local vision model, surface only the ones worth my attention. This post covers that shared foundation, one SQLite-only pipeline and one shared GPU, and the two decisions in it I&amp;rsquo;m still not fully sure were right. Two follow-ups go deep on how each project decides what actually counts as a match: &lt;a href="https://prestonbernstein.com/blog/deciding-whats-worth-a-saturday-estate-sale-scanner/" &gt;Deciding what&amp;rsquo;s worth a Saturday&lt;/a&gt; for the estate-sale scanner, and &lt;a href="https://prestonbernstein.com/blog/deciding-what-fits-resale-clothing-monitor/" &gt;Deciding what fits&lt;/a&gt; for the resale monitor.&lt;/p&gt;</description></item><item><title>GitHub's Agents Tab Puts Claude and Codex in the Repo UI. It's a Separate Bill From Claude Code.</title><link>https://prestonbernstein.com/blog/github-agents-tab-vs-claude-code/</link><pubDate>Mon, 10 Aug 2026 12:30:00 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/github-agents-tab-vs-claude-code/</guid><description>&lt;p&gt;GitHub&amp;rsquo;s per-repo Agents tab is a mission-control surface, live since January 26, 2026, where GitHub-hosted coding agents pick up issues and turn them into PRs without anyone opening a terminal. Copilot&amp;rsquo;s own agent lives there by default, and Claude and Codex are selectable alongside it as &amp;ldquo;picked&amp;rdquo; third-party agents. The tab is part of Agent HQ, the umbrella GitHub announced on October 28, 2025, meant to give every agent vendor one shared surface inside Issues, PRs, and Actions instead of a pile of separate integrations. My read after digging into how it actually works: this is a real product, not a rebrand of anything Anthropic ships, and it solves a narrower slice of my workflow than local Claude Code already covers. Whether I keep reaching for it once the novelty wears off is the part I genuinely don&amp;rsquo;t know yet.&lt;/p&gt;</description></item><item><title>Step-by-Step Guide to Creating a Secure Docker Compose Script with VPN Integration</title><link>https://prestonbernstein.com/blog/secure-services-docker-compose-and-nordvpn/</link><pubDate>Mon, 01 Jul 2024 22:01:16 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/blog/secure-services-docker-compose-and-nordvpn/</guid><description>&lt;h2 class="relative group"&gt;Introduction
 &lt;div id="introduction" class="anchor"&gt;&lt;/div&gt;
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#introduction" aria-label="Anchor"&gt;#&lt;/a&gt;
 &lt;/span&gt;
 
&lt;/h2&gt;
&lt;p&gt;Docker containers share the host&amp;rsquo;s network stack by default. Any service you run is only as private as the connection it&amp;rsquo;s running on, unless you put something in front of it. Routing a container&amp;rsquo;s traffic through a VPN container fixes that: requests leave through the VPN, not your raw connection, and the container&amp;rsquo;s real IP stays hidden.&lt;/p&gt;</description></item><item><title>Privacy</title><link>https://prestonbernstein.com/privacy-policy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><author>contact@prestonbernstein.com (Preston Bernstein)</author><guid>https://prestonbernstein.com/privacy-policy/</guid><description>&lt;h4 class="relative group"&gt;Responsibility of Contributors
 &lt;div id="responsibility-of-contributors" class="anchor"&gt;&lt;/div&gt;
 
 &lt;span
 class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;
 &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#responsibility-of-contributors" aria-label="Anchor"&gt;#&lt;/a&gt;
 &lt;/span&gt;
 
&lt;/h4&gt;
&lt;p&gt;Lorem ipsum dolor sit amet, consectetur adipiscing elit. Purus, donec nunc eros, ullamcorper id feugiat quisque aliquam sagittis. Sem turpis sed viverra massa gravida pharetra. Non dui dolor potenti eu dignissim fusce. Ultrices amet, in curabitur a arcu a lectus morbi id. Iaculis erat sagittis in tortor cursus. Molestie urna eu tortor, erat scelerisque eget. Nunc hendrerit sed interdum lacus. Lorem quis viverra sed&lt;/p&gt;</description></item></channel></rss>