DEV Community: DevLog

Search Console: When sitemap index shows 0

DevLog — Thu, 01 Oct 2026 11:43:33 +0000

I spend a lot of time digging into technical glitches, often running automation scripts on my Mac mini to isolate points of failure. Recently, I encountered a confusing issue in Google Search Console where my sitemap status seemed inaccurate, leading me down a rabbit hole of checking HTML sources and API responses.

Why does the sitemap screen show 0 indexed pages?

For several weeks, my sitemaps screen displayed "Submitted: 52" and "Indexed: 0". I had submitted both sitemap.xml and the Tistory-generated rss feed, and both were marked as "Success". It felt like something was broken; I started questioning if my google-site-verification code was missing or if the URLs were incorrect.

To verify, I used the Search Console API to run sitemaps().list(). The results showed 55 items for sitemap.xml and 11 for rss, both returning HTTP 200 status codes. In my automation scripts, a 200 OK signal indicates the process should move to the next step, so technically, everything was working perfectly. Despite this, the sitemap dashboard stubbornly refused to move past 0 indexed pages.

In reality, the "Indexed" count on the sitemap screen is an indirect indicator. It reflects whether the sitemap submission was successful or how Google discovered the files, but it is not a real-time mirror of whether your pages are live in search results. Especially on platforms like Tistory, there is often a lag between the sitemap report and actual indexing. For example, as of September 4, 2026, my Tistory page index report was 12 days behind, even though the content was already live.

How can I verify if a specific URL is actually indexed?

Since the sitemap dashboard was unreliable, I turned to the "URL Inspection" tool in the Search Console top search bar. This is the only way to get a definitive answer for a specific page.

To check your status, copy the full URL of your post—for example, https://yourblog.com/8—and paste it into the URL Inspection box at the top of the console, then hit enter. When I did this for my posts at /8, /18, and /44, the result was clearly "URL is on Google" or "Submitted and indexed."

This confirmed that while the sitemap screen showed 0, my pages were actually indexed and searchable. In one specific check, I found that 13 posts published between September 11 and September 14 were all "Indexed," with the crawl date matching the publication date, even though the sitemap report had not yet updated.

How do I make new posts get indexed faster?

Once I realized the dashboard numbers were misleading, I focused on discovery speed. Google can process multiple sitemaps, and I found that submitting two different types of feeds helps new content get picked up more quickly.

The first is sitemap.xml, the standard full list of posts provided by the blog service. The second is the rss feed (or atom.xml), which serves as a feed for the most recent posts. To set this up, go to the "Sitemaps" menu in Search Console and submit sitemap.xml, then repeat the process for rss. Currently, my rss shows 11 successful items and sitemap.xml shows 55.

If you want to manually push a page, you can use the "Request Indexing" button in the UI. However, this is limited to about 10 requests per day. Google explicitly warns that "submitting multiple times does not change priority," so there is no point in spamming the button. Submitting both sitemap types and verifying via URL Inspection is a much more efficient workflow.

Stop stressing over the numbers on the sitemap screen and simply check your URLs individually.

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Claude Code: Analyzing 159 Feedback Memory Files

DevLog — Wed, 30 Sep 2026 06:43:29 +0000

Symptom / Cause / Fix
Repeated mistakes despite automatic memory / Claude reads only the one-line index summary at session start, not the full body / Include the "Why" directly in the one-line summary.

I've been using Claude Code across my work laptop and home Mac mini for about 15 months. Claude Code includes an automatic memory feature: whenever I correct the AI, it creates a feedback file. Each file contains a one-line explanation of "why" the correction happened and "how" to apply it next time. While migrating these files from my work laptop, I realized I had accumulated 159 of them—meaning I've had to correct Claude 159 times.

Reviewing the files labeled as "reoccurred twice," "strongly repeated correction," or "repeated thinking error," I found that the issues fall into five distinct patterns. Interestingly, none of these concern specific code syntax; they are all about the workflow.

1. Solving in fragments without context

The most frequent correction was telling Claude to stop solving tasks piece-by-piece and instead grasp the overall context. This manifests in three ways:

Claiming to understand requirements but omitting them during implementation.
Deciding on an answer prematurely and inventing new justifications to defend that conclusion when challenged, rather than re-evaluating the conclusion itself.
Taking the shortest path to complete an immediate instruction, which effectively ignores the broader context.

2. Confusing reporting with actual reflection

There is often a gap between Claude claiming something is done and it actually being finished. In one instance, Claude reported "it's on the user's PC" after committing code, forgetting that pushing was still required. This led to two specific memory files: "Work is only complete after merging to main and pushing" and "Verify the remote state again after pushing."

The same applies to testing and UI. I had to mark a "reoccurred twice" error regarding tests: "A new test is only considered passed if it actually fails after reverting the fix." A test that always passes isn't a test. For UI, the rule is: "It is incomplete until a real screenshot is viewed; an agent's 'design complete' report is merely functional verification."

3. Trusting its own eyes over the user's

Claude often confuses its terminal output with what I see in the GUI. It once mistook a Korean character encoding glitch in its own PowerShell capture for a product bug and tried to fix the console encoding. On my Mac mini, it insisted a string didn't exist because its internal count was wrong, failing four times in one day. The rules are now: "Do not doubt what the user sees in their environment" and "Doubt your own inspection before claiming something isn't there."

4. Overstepping authority boundaries

"Diligence" is a virtue unless it's directed at a production server. I had to set strict boundaries:

"Review" means review only; implementation starts only after an explicit instruction to proceed.
Use only GET on production servers. One "confirmation" POST once accidentally triggered two crawlers simultaneously.
Any operation with permanent effects on external systems requires a two-step safety mechanism and visual verification.

5. The Korean Windows encoding trap

Working on a company PC introduced specific encoding hurdles that reoccurred multiple times. The rules seem contradictory, which is why they must be documented:

.bat files for Korean Windows must be saved as CP949, otherwise execution fails.
Printing characters like the em dash to the production PC console causes the tool to crash due to encoding errors.
Cron script output must be fixed to UTF-8. Reverting this to CP949 wipes out all Korean notifications (this reoccurred twice in August).

To fix these recurring issues, I changed how I manage memory files:

Identify the repeated failure pattern in the feedback file.
Rewrite the index summary to include not just the "what," but the "why."
Verify that the one-line summary is punchy enough to trigger the correct behavior in a new session.

Having 159 memory files isn't a badge of honor; it means the system is leaky. The reason "reoccurred twice" labels exist is that writing something down isn't the same as it being read. Claude Code only reads the one-line summary of the index file when starting a session, not the full body. Now, when saving memory, I prioritize the summary line over the detailed content to ensure it actually works in the next session.

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Claude Code PDCA: Why 100% alignment is not success

DevLog — Tue, 29 Sep 2026 10:43:26 +0000

Running six PDCA (Plan-Design-Do-Check-Act) cycles with Claude Code on a color extraction tool taught me that high alignment rates are often vanity metrics. In my case, half the cycles were essentially wasted because I relied too heavily on whether the code matched the design.

The biggest realization was that alignment and effectiveness are two different axes. In one cycle, gap analysis showed 100% alignment between the design document and the implementation; however, zero cases were actually fixed. The AI followed the design perfectly, but the design failed to solve the problem. Now, I track two separate metrics: Axis A (how well the design was met) and Axis B (whether the hypothesis in the plan actually worked).

I also learned that post-processing cannot fix failures in the upstream process. I spent two cycles trying to fix missing colors by adjusting filters, which failed because the clustering stage wasn't generating those colors in the first place. Now, any plan to modify a filter must first verify that the upstream process is producing the target. Similarly, introducing weights to vivid pixels—intended to improve clustering—actually pulled the center toward outliers, increasing the error in the hardest cases from 20 to 45.

Synthetic data proved to be another trap. While actual images missed colors in eight out of fourteen cases, a synthetic verification tool caught only one out of eight. The synthetic data was too clean, lacking the gradients and compression noise found in reality. I now require a check to ensure synthetic data statistics are within 10% of real-world data before adopting it as an MVP.

Interestingly, not every task requires a design document. For simple UI features with clear requirements in the plan, jumping straight to implementation still yielded 98% alignment. This lesson mirrored a Mac Mini review project where five rounds of AI script audits failed for the same reason: generalizing a single constant without conditions.

Ultimately, PDCA isn't about making the AI write documents; it is a mechanism to force objective judgment. Alignment tells you if the AI followed its own rules, but only reality tells you if it worked.

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Claude CLI 401 Unauthorized Refresh Token Issue

DevLog — Mon, 28 Sep 2026 11:43:23 +0000

Symptom: claude commands fail with 401 Unauthorized and the message "refresh token was already used. Please log out and sign in again."

Cause: The refresh token expired after being consumed by another session or a background process. Refresh tokens are single-use credentials.

Fix: Run claude auth login to refresh authentication without running a logout command first.

Why claude login alone did not clear the 401

I was running a pipeline command when every subsequent CLI call failed. The terminal returned this exact output:

Error: 401 Unauthorized
  Message: "Authentication failed: refresh token was already used. Please log out and sign in again."
  Code: "AUTH_ERROR"

The error text explicitly instructs me to log out. I spent roughly ten minutes searching the terminal for a logout function. The prompt only showed AUTH_ERROR. I assumed clearing old sessions was required first. That assumption blocked progress. The instructions in the error message describe your token state, not the recovery step. You do not need to run claude auth logout. The token is already invalid. Executing a logout command on an expired session adds unnecessary steps without changing the result. You only need to sign in again.

How to verify a consumed refresh token state

I checked available commands by running claude auth --help. It listed three options: login, logout, and status. I used claude auth status to verify the broken state. It confirmed the session was inactive. This command is useful for verifying your fix works immediately after re-authenticating.

The core issue lies in how refresh tokens work. A refresh token is a single-use credential that keeps your session alive without asking for fresh credentials repeatedly. If any background script or another terminal window consumes it, the token becomes invalid. Your active session loses its validity instantly. The error message mentions log out because the system expects you to clean up after yourself, but that cleanup function only works on active sessions. When the token is already consumed, you must bypass the logout step entirely.

What happens when background scripts burn tokens

The CLI functioned normally until a pipeline execution triggered the failure. No manual logout occurred beforehand. This pointed to an unseen consumer. Long-running scripts or suspended processes often hold onto refresh tokens in the background. When they execute, they use the token to verify their identity against the API. Once that happens, your active terminal session can no longer use it. The token is burned.

I resolved the issue by running claude auth login. The terminal opened a browser window to complete the authentication flow. Alternatively, it prompted me directly in the terminal for an authentication code. I completed the prompt. All commands immediately resumed working. The 401 error disappeared. I verified everything was normal by running claude auth status. It showed an active session. The entire process took less than two minutes once I stopped looking for a logout function.

How to prevent token exhaustion during pipeline runs

I learned a few concrete things from this breakdown. Session management requires understanding how tokens behave under the hood. I will keep this checklist for future pipeline maintenance:

Ignore log out instructions when you see a consumed token error.
Run claude auth login immediately to generate a fresh token.
Use claude auth status to verify your session is active before running pipelines.
Check for long-running background scripts that might be burning refresh tokens.

Written from real hands-on experience, drafted with AI assistance.

npm command not found on Windows: fix the PATH
codex CLI login not working on macOS: what fixed it
Run a Discord bot 24/7 for free on a computer you already own

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

codex CLI login not working on macOS: what fixed it

DevLog — Mon, 28 Sep 2026 07:43:22 +0000

TL;DR:

Symptom: codex --version fails with "No such file or directory", while codex login and codex exec throw 401 Unauthorized or "Not inside a trusted directory".

Cause: brew cask leaves only symlinks with missing binaries, expired tokens in auth.json, and security restrictions blocking non-git directories.

Fix: Run brew reinstall --cask codex to restore the binary, re-run codex login for a fresh token, and append --skip-git-repo-check when working outside repositories.

Why codex login alone did not clear the 401

I spent hours trying to get the codex CLI working after a clean install. The first red flag appeared when I ran codex --version. Instead of printing the installed version, it immediately crashed with "No such file or directory". This is a classic symptom of a broken package manager installation. When you install tools through brew cask, the system sometimes only writes symbolic links instead of copying the actual executable files. A symbolic link is just a reference path that points to another file, so if the target disappears, the link becomes useless. It felt like checking a skeleton and finding nothing inside.

Running brew reinstall --cask codex fixed the missing binary and restored the symlinks. codex --version started working again, which made me confident I had fixed the installation. Then came codex login. Every attempt returned 401 Unauthorized. I assumed the API key was invalid and went through the reissuing process, but the error persisted. The real issue lived inside auth.json, which stores your authentication tokens on disk. Authentication tokens are temporary credentials that prove your identity to the service. Package updates or manual edits can leave these tokens expired on disk. Running codex login again forces the CLI to generate a fresh token and overwrite the stale entry. It cleared the 401 Unauthorized response immediately.

Breaking the trusted directory check for local projects

The final hurdle appeared when I tried codex exec. Running it outside a version-controlled project triggered "Not inside a trusted directory" and refused to execute. This is not a bug; it is a built-in security measure. The CLI defaults to running only in directories that contain git commit history, assuming those are validated codebases. When I tried to apply the tool to private files or scratch projects, it blocked me without warning.

I had to dig into man codex to find the override. Adding --skip-git-repo-check disables that directory validation and lets the command run anywhere you specify. Testing codex exec --skip-git-repo-check confirmed it worked exactly as intended. After verifying that codex login succeeded and codex --version printed correctly, I stopped fighting the toolchain.

Dealing with broken symlinks, expired tokens, and hidden security checks simultaneously taught me a practical lesson. CLI failures rarely come from a single missing dependency. Package managers, local config files, and default security policies interact in ways that simple reinstallation cannot fix. You have to trace each error back to its actual source before applying the next command. Understanding how your package manager and tool defaults interact saves more time than memorizing error codes.

Run a Discord bot 24/7 for free on a computer you already own
npm command not found on Windows: fix the PATH
Claude CLI 401 Unauthorized Refresh Token Issue

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Run a Discord bot 24/7 for free on a computer you already own

DevLog — Sun, 27 Sep 2026 10:43:18 +0000

Once you have a Discord bot working, the next problem shows up fast. Close the terminal and the bot dies. Turn off the computer and it dies. So you go looking for "free 24/7 hosting".

Before you do: if you have a computer at home that stays on, that is your host. Ours is a Mac mini that has been up 34 days straight. Hosting cost is zero.

What you get by hosting it yourself

It never sleeps. Free tiers often idle your bot out. Waking up takes time, and commands sent in between are lost
It can touch your files. The bot runs inside your machine, so your folders, your scripts and your installed tools are all available. This is the real difference
No expiry. Free plans change. Your own computer does not
You pay for electricity, nothing else

The trade is that you are tied to your home power and internet. A blackout takes the bot with it. For a bot you use, that is usually fine.

Step 1: survive closing the terminal

A program started in a terminal belongs to that window. Close it and the program goes too.

screen gives you a detached place to run it. macOS ships with it.

screen -dmS mybot python3 /Users/me/bot.py

-dmS means "start detached, give it a name". You can close the terminal now.

To look in on it:

screen -ls
screen -r mybot

screen -ls prints something like this.

There is a screen on:
        37448.mybot     (Detached)

Detached means nobody is watching but it is running. screen -r attaches you to it. To leave, press Ctrl+A then D. Pressing Ctrl+C kills the bot. That catches everyone once.

tmux does the same job. nohup is simpler but you cannot look at the screen later, which you will want.

Step 2: survive a reboot

A screen session dies with the machine, and updates reboot it whether you like it or not.

On macOS, launchd handles this. You write one file, register it, and the thing starts at login and restarts if it dies. On Linux it is systemd.

Step 3: the shape that actually works

Here is where people usually go wrong. You can have launchd start the bot directly. We do not.

launchd starts a small script, and that script manages the screen session.

The reason is that you will want to see the bot's screen with your own eyes. A process started directly by launchd has no screen to attach to. Put screen in the middle and screen -r works whenever you need it.

The script is not complicated.

while true; do
  if ! screen -ls | grep -q "\.mybot[[:space:]]"; then
    screen -dmS mybot python3 /Users/me/bot.py
  fi
  sleep 30
done

Every 30 seconds it checks whether the session exists and starts it if not. launchd keeps the script alive, so if the script dies it comes back. Two layers.

Add a network check before the first start. Right after a reboot the network is often not up yet, and the bot fails immediately if it tries to connect.

Step 4: stop the machine from sleeping

If you skip this, your bot dies every night and you will not know why.

Turn off sleep in Energy Saver. You can confirm from the terminal:

pmset -g

sleep 0 means it will not sleep. displaysleep can stay on — the screen turning off does not stop anything. On a laptop, check what closing the lid does. This is why a headless box like a Mac mini suits the job.

The failure nobody plans for

Everything above handles a bot that dies. In practice the worse case is different.

The process is alive and the bot simply stops answering. Discord still shows it online. ps still lists it. Commands get no reply. A session expired, a quota ran out, or something inside got stuck.

Restart-if-dead never fires, because nothing died.

The fix is to watch work, not liveness. Have the bot write a timestamp every time it actually handles something, and have your script kill the process if that timestamp gets too old. Killing it is enough — the structure above brings it straight back.

We got burned here in a way worth repeating. Our watchdog checked connectivity by fetching a page, and that fetch pulled the whole 170KB body. On a slow day it blew past the timeout, so the watchdog itself failed for eight hours while the bot sat dead. Switching to a HEAD request brought it to 0.5 seconds.

If the thing doing the watching is heavy, the watching breaks first.

Checking on it

screen -ls
launchctl list | grep mybot

First line tells you the session exists, second that autostart is registered.

One warning: screen -X hardcopy, which dumps the screen to a file, produces an empty file for anything that draws a text UI. We tried to use it for health checks and wasted time. Check for a child process and an established network connection instead.

Making the bot in the first place: Discord bot setup, from token to server invite
When it is alive but silent: Discord bot not responding but still running: how to catch it

Every command and number here comes from a machine that is running right now.

Discord bot not responding but still running: how to catch it
npm command not found on Windows: fix the PATH
codex CLI login not working on macOS: what fixed it

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Discord bot not responding but still running: how to catch it

DevLog — Sun, 27 Sep 2026 06:43:17 +0000

Your bot shows as online in Discord. The process is there in ps. And it answers nothing.

This is the failure that gets past every restart-if-it-dies setup, because nothing died. Here is how to detect it and what to do about it.

Why your supervisor misses this

launchd with KeepAlive, systemd with Restart=always, pm2, a while loop that checks for the process — they all watch the same thing. Is the process there?

When a session expires, a daily quota runs out, or a request hangs on a socket with no timeout, the process is still there. It holds memory, it shows up in the process list, and the supervisor is satisfied. The bot is dead in every way that matters and nothing will restart it.

Signals that lie to you

Before building a check, know which signals are useless here.

Discord shows the bot online. The gateway connection can outlive the part of your code that handles messages
The process exists. That is exactly the thing that is wrong
launchctl list shows a PID. Same problem
Logs are quiet. A stuck bot usually stops logging, and "no errors" reads like "no problems"
A screen dump is empty. If your bot draws a text interface, screen -X hardcopy writes an empty file. We tried to use it for health checks and wasted time on it

Watch work, not life

The check that works is the boring one. Have the bot record when it last did something real.

Not when it started. Not when it received a message. When it finished handling one.

from pathlib import Path
import time

HEARTBEAT = Path("/tmp/mybot.alive")

async def on_message(msg):
    ...                      # handle the command
    await msg.channel.send(reply)
    HEARTBEAT.write_text(str(int(time.time())))   # only after a real reply

Then a separate script decides whether that timestamp is too old.

now=$(date +%s)
last=$(cat /tmp/mybot.alive 2>/dev/null || echo 0)
if [ $((now - last)) -gt 900 ]; then
  pkill -f mybot.py          # let the supervisor bring it back
fi

Killing it is the whole fix. You do not need restart logic — whatever already restarts a dead process will handle it. You are just converting an invisible failure into a visible one.

Choosing the threshold

Too short and you restart a bot that is merely idle. Too long and you are down for hours.

The number depends on traffic, not on taste. If your bot handles something every few minutes, fifteen minutes is generous. If it goes quiet overnight, a timestamp alone will produce false restarts — in that case have the bot do a cheap internal task on a timer and stamp that, so the heartbeat reflects the bot being capable, not being used.

Keep the watcher light

This one cost us eight hours.

Our watchdog checked connectivity before restarting the bot, and that check fetched a page — the whole 170KB body. On a slow connection it exceeded its own timeout, decided the network was down, and refused to restart. The bot was dead the entire time and the watchdog was the reason it stayed dead.

Switching to a HEAD request took it to 0.5 seconds.

If a watchdog can fail, it will fail at the worst time. Keep every check in it cheap and give each one a timeout shorter than the loop interval.

A quick audit

Answer these about your own setup:

If the process froze right now, what would notice? If the answer is "me, eventually", you have this problem
Does your health check look at anything other than the process existing?
Can your watchdog itself hang? What is its slowest operation?

The setup this runs on: Run a Discord bot 24/7 for free on a computer you already own
Environment traps when starting from a supervisor: mac environment variables that autostart does not have

Every number here is from a bot that has been running on the same machine for 34 days.

Run a Discord bot 24/7 for free on a computer you already own
codex CLI login not working on macOS: what fixed it
Claude CLI 401 Unauthorized Refresh Token Issue

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Getting started with uv: an existing project, a new project, and the numbers (pip 2.46 s uv 0.38 s)

DevLog — Sat, 26 Sep 2026 09:43:13 +0000

uv is a fast Python package and project manager written in Rust. This is the write-up of the video above: dropping uv into a project that already has a requirements.txt, starting a new project from scratch, and a pip-versus-uv benchmark on one machine with the conditions stated. Every number below is on screen in the video and came from the same runs.

The two commands first

Existing project: uv pip install -r requirements.txt
New project: uv init && uv add && uv sync

If all you want is faster installs, the first line is the whole migration. The rest of this post is what happens around those two lines, and where to be careful.

Install

One command, one binary. You do not need a Python on the machine to install it, which matters when the thing you are installing is what will manage your Pythons.

curl -LsSf https://astral.sh/uv/install.sh | sh

The video pins version 0.11.6 and installs into a throwaway directory instead:

$ curl -LsSf https://astral.sh/uv/0.11.6/install.sh | UV_INSTALL_DIR=/tmp/uvtest sh
downloading uv 0.11.6 aarch64-apple-darwin
installing to /tmp/uvtest
  uv
  uvx
everything's installed!
WARN: The following commands are shadowed by other commands in your PATH: uv uvx
$ /tmp/uvtest/uv --version
uv 0.11.6 (65950801c 2026-04-09 aarch64-apple-darwin)

Why pin an old version? The benchmark ran on 0.11.6, and I wanted every number and every version string on screen to come from one build. Newer releases are faster in places, so read the numbers here as a floor. The "shadowed" warning appears because this Mac already had a uv on the PATH; you will not see it on a clean machine. For your own install, use the first command and take the latest.

Replace pip in a project you already have

Nothing gets converted. uv ships a pip-compatible interface, so the command you already know still works against the same requirements.txt.

$ cat requirements.txt
requests
rich
httpx
pydantic
click
jinja2
pyyaml
python-dateutil

Same file installed twice, both with caches turned off:

$ python3 -m venv .venv-pip && time .venv-pip/bin/pip install -q --no-cache-dir --disable-pip-version-check -r requirements.txt

real    0m2.643s
user    0m1.582s
sys     0m0.303s
$ uv venv --python 3.14 .venv-uv && time uv pip install -q --no-cache -r requirements.txt --python .venv-uv/bin/python
Using CPython 3.14.6 interpreter at: /opt/homebrew/opt/python@3.14/bin/python3.14
Creating virtual environment at: .venv-uv
Activate with: source .venv-uv/bin/activate

real    0m0.363s
user    0m0.153s

Notice what did not happen: no rewritten requirements file, no new project layout, no CI changes.

The numbers, with the conditions

Numbers without conditions are not worth much, so here they are together. Eight packages, caches disabled on both sides, five runs each, median.

Mac mini M4 Pro / macOS 26.6.1 / Python 3.14.6 / pip 26.1.2 / uv 0.11.6
8 packages, caches disabled on both sides, 5 runs each, median

  install       pip  2.457s     uv  0.381s      6.4x
  create venv   venv 1.143s     uv  0.026s     43.9x
  ------------------------------------------------------
  full flow     3.600s   ->   0.407s            8.8x

  (bonus) uv install with warm cache: 0.062s

Two things worth separating. Installing the packages is the headline, 6.4×. Creating the environment is a separate cost, and that gap is bigger: 1.143 s against 0.026 s. Put together, the thing you actually do went from 3.6 s to 0.4 s.

One caveat: that is a cold install. With a warm cache uv drops to 0.062 s, but comparing a warm run against a cold one would be cheating, so treat that line as a bonus, not the headline.

Update, 2026-09-09: uv 0.12.11 shipped the day before this post went live, so I re-ran the same eight packages, caches off, five runs each, median, on the same machine with both uv versions and pip 26.1.2 back to back:

              create venv   install    full flow
pip 26.1.2       1.202s      2.338s      3.540s
uv 0.11.6        0.150s      0.383s      0.533s
uv 0.12.11       0.136s      0.375s      0.511s

Install is 6.2× faster than pip on 0.12.11 and the full flow 6.9×, so the video's numbers still hold as a floor. The two uv versions are within 4% of each other on this workload. The venv column differs from the table above because this re-run timed uv venv --python 3.14 from a Python harness rather than the shell's time; compare rows within one table, not across the two.

Start a new project: init, add, sync

The other entry point is starting fresh. uv init lays out a project, uv add resolves and installs in one step while writing a lock file, and uv sync rebuilds the environment from that lock file.

$ uv init demo && cd demo && ls
Initialized project `demo` at `.../uvdemo/demo`
main.py         pyproject.toml  README.md
$ uv add requests rich
Using CPython 3.13.13
Creating virtual environment at: .venv
Resolved 10 packages in 71ms
Prepared 7 packages in 79ms
Installed 9 packages in 10ms
 + certifi==2026.7.22
 + charset-normalizer==3.5.1
 + idna==3.19
 + markdown-it-py==4.2.0
 + mdurl==0.1.2
 + pygments==2.21.0
 + requests==2.34.2
 + rich==15.0.0
 + urllib3==2.7.0
$ cat pyproject.toml
[project]
name = "demo"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
    "requests>=2.34.2",
    "rich>=15.0.0",
]

This is why the lock file exists. Delete the environment completely, run uv sync, and you get the exact same versions back, not whatever resolves today:

$ rm -rf .venv && uv sync
Using CPython 3.13.13
Creating virtual environment at: .venv
Resolved 10 packages in 0.59ms
Installed 9 packages in 7ms
 + certifi==2026.7.22
 + charset-normalizer==3.5.1
 + idna==3.19
 + markdown-it-py==4.2.0
 + mdurl==0.1.2
 + pygments==2.21.0
 + requests==2.34.2
 + rich==15.0.0
 ...

pyproject.toml says what the project asks for. uv.lock records the exact resolved graph, transitive packages included. Commit it, and a teammate who clones the repo runs one command and has your environment.

Run without activating

uv run resolves the project's environment, makes sure it is in sync, and runs your command inside it. No source .venv/bin/activate, no shell state to lose.

$ uv run python -c 'import requests; print(requests.__version__)'
2.34.2

The interpreter it used is the project's own, not the system one, without touching anything.

Python versions and tools

uv installs Python itself. Pin a version per project and anyone who runs uv sync gets that interpreter downloaded automatically. No pyenv, no system-Python roulette.

$ uv python list | head -6
cpython-3.15.0a8-macos-aarch64-none
cpython-3.15.0a8+freethreaded-macos-aarch64-none
cpython-3.14.6-macos-aarch64-none                   /opt/homebrew/bin/python3.14 -> ...
cpython-3.14.6-macos-aarch64-none                   /opt/homebrew/bin/python3 -> ...
cpython-3.14.4-macos-aarch64-none
cpython-3.14.4+freethreaded-macos-aarch64-none
$ uv run --python 3.13 python -V
Python 3.13.13

It also manages command-line tools. uv tool install puts a command on your PATH for good; uvx runs one once in a throwaway environment. Same package, different commitment.

uv tool install ruff
uvx ruff check .

Three things to check before moving a real project

1. The tool directory may not be on your PATH. This happened while making the video. uv tool install httpie succeeded, installed 16 packages and 3 executables, and printed the warning right there:

$ uv tool install httpie
Resolved 16 packages in 71ms
Prepared 2 packages in 23ms
Installed 16 packages in 25ms
 ...
Installed 3 executables: http, httpie, https
warning: `/Users/smkim/.local/bin` is not on your PATH. To use installed tools, run `export PATH="/Users/smkim/.local/bin:$PATH"` or `uv tool update-shell`.
$ http --version
bash: http: command not found

uv did warn. Until the PATH was fixed, the command still would not resolve. Read the last line of the install output.

2. Switching installs is cheap. Switching your team's workflow and CI at the same time is not. The pip-compatible path exists so you can do the first without the second. Take the faster installs today; move the layout, lock file and CI when the team is ready.

3. Private indexes, authenticated registries and unusual build backends are where a drop-in replacement stops being drop-in. It is not that uv cannot do them. It is that "it just works" stops being a safe assumption there, so test before you commit.

What to do today

Point uv at whatever you are working on right now and see what your install time drops to. That is the whole test.

uv pip install -r requirements.txt

Measured on a Mac mini M4 Pro, macOS 26.6.1, Python 3.14.6, pip 26.1.2, uv 0.11.6. The two timings in the "Replace pip" section are single runs from the recording; the table reports five-run medians. They are different runs on purpose, and they agree.

Why your Python script is slow: two lines took it 3.71 s to 1.20 s
Run a Discord bot 24/7 for free on a computer you already own
codex CLI login not working on macOS: what fixed it

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

ffmpeg: Convert video to optimized GIF on macOS

DevLog — Sat, 26 Sep 2026 06:43:12 +0000

Whenever I need to turn a video into a GIF, most search results lead me to upload-based websites. These usually have strict file size or length limits, and I prefer not to upload my raw files to a third-party server. Since I use a Mac mini with Apple Silicon, I wanted a way to do this locally.

To get started, you need Homebrew (a package manager for macOS). If you don't have it, install it via the terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Verify the installation with brew --version. Once that is sorted, install ffmpeg, a powerful tool for handling almost any video or audio task:

brew install ffmpeg

Run ffmpeg -version to confirm it's working. On my M1 Mac mini, the installation took less than a minute.

My first attempt was to keep it simple. I found a basic one-line command and tried it on a 15-second Full HD (1920x1080) video:

ffmpeg -i input.mp4 output_single_pass.gif

The result was a "capacity bomb." The GIF ended up being 25.1 MB, even though the source was just a simple smartphone clip. While usable for very short clips, the file size becomes impossible to share for anything longer.

The issue is that GIFs only support 256 colors. Trying to preserve every color from a high-resolution video causes the file size to explode. To fix this, you must first generate a custom color palette.

Using a two-step conversion for optimization

To dramatically reduce the size, you need to extract an optimized color palette from the source video and then use that palette to render the GIF.

Step 1: Generate the palette
First, extract the best 256 colors from input.mp4 and save them as palette.png.

ffmpeg -i input.mp4 -vf "fps=10,scale=480:-1:flags=lanczos,palettegen" palette.png

Here is what the -vf (video filter) options are doing:

fps=10: Sets the frames per second to 10. Standard video is usually 24–30 fps, but 10–15 is plenty for a GIF and saves significant space.
scale=480:-1: Resizes the width to 480 pixels. The -1 tells ffmpeg to calculate the height automatically to maintain the aspect ratio.
flags=lanczos: A high-quality scaling algorithm that minimizes quality loss during resizing.
palettegen: The filter that creates the optimized 256-color palette.

On my 15-second clip, this step took about 4 seconds to produce palette.png.

Step 2: Convert using the palette
Now, combine the original video and the palette to create the final GIF.

ffmpeg -i input.mp4 -i palette.png -filter_complex "fps=10,scale=480:-1:flags=lanczos[x];[x][1:v]paletteuse" output_optimized.gif

In this command, -filter_complex is used because there are two inputs. The video stream [x] (processed with the same fps and scale) is combined with the palette stream [1:v] using the paletteuse filter. This final step took about 5 seconds.

Performance Comparison

To see the actual difference, I tested both methods using the same 15-second 1080p MP4 (original size: 8.7 MB).

Method	File Size	Conversion Time
Single-pass	25.1 MB	3.2s
Two-step (Optimized)	2.5 MB	9.0s (3.8s palette + 5.2s GIF)

The optimized version is over 10 times smaller than the single-pass version. While it takes about three times longer to process, that is a small price to pay for such a massive reduction in file size.

A few things to keep in mind: fps is critical; pushing it above 20 will cause your file size to skyrocket. Also, reducing the scale is the most effective way to cut size—dropping from 960px to 480px reduces total pixels by a factor of four. I once tried to turn a full hour of footage into a GIF, and my Mac mini fans started screaming; keep your clips short for the best results.

It was a good reminder that simply finding a command that "works" isn't enough. Taking the time to measure results and understand the underlying logic—like how the GIF color palette works—saves a lot of frustration in the long run.

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Why your Python script is slow: two lines took it 3.71 s to 1.20 s

DevLog — Sat, 26 Sep 2026 06:43:11 +0000

One script, one million rows, one question: where does the time go? This is the write-up of the video above. Every number comes from the same measurement files the video used, all on one Mac mini (M4 Pro, 48 GB) with Python 3.14.6. The workload is synthetic: a deterministic generator (seed 42) writes a sales CSV so anyone can reproduce the run.

The result first

report.py (baseline): 3.71 s — single run, timed inside the script
report_cached.py (two lines added): 1.20 s — single run, timed inside the script
cmp report.txt report2.txt → identical, byte for byte

About 3.1× faster, same output, two lines changed. The interesting part is how we found the two lines, and where the trick stops working.

What the script does

report.py reads a CSV of 1,000,000 sales rows, parses each row's date string, totals revenue by month and region, and writes a text report. We measure wall time, and the report must stay identical.

$ python3 report.py sales.csv report.txt
wrote report.txt: 1,000,000 rows in 3.71 s

Not slow enough to notice once. Slow enough to hate inside a loop.

Ask Python where the time goes

$ python3 -m cProfile -s tottime report.py sales.csv report.txt | head -12
         32016593 function calls (32016422 primitive calls) in 8.440 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  1000000    3.045    0.000    5.556    0.000 _strptime.py:516(_strptime)
  1000001    0.859    0.000    1.411    0.000 csv.py:173(__next__)
  1000000    0.465    0.000    6.021    0.000 _strptime.py:812(_strptime_datetime_datetime)
        1    0.451    0.451    6.947    6.947 report.py:12(summarize)

The top line is the date parser, strptime: one million calls, 3.045 s of self-time, 36% of the profiled run. Two cautions that the profiler itself teaches: self-time excludes subcalls, and profiling changes the timing (8.44 s here versus 3.71 s unprofiled). Read the share, not the seconds. The share points at parsing.

A profile says which function, not why

So look at the input.

$ python3 count_distinct.py sales.csv
1,000,000 rows, 365 distinct dates

One million calls, 365 distinct strings. The same date string gets parsed about 2,740 times.

The two-line change

 from collections import defaultdict
+from functools import lru_cache

+@lru_cache(maxsize=None)
 def parse_date(s):
     return datetime.strptime(s, "%Y-%m-%d %H:%M:%S")

Prediction before running it: strptime executes 365 times instead of 1,000,000, and the report does not change.

Did the prediction hold?

$ python3 report_cached.py sales.csv report2.txt
wrote report2.txt: 1,000,000 rows in 1.20 s
$ cmp report.txt report2.txt && echo identical
identical
$ python3 cache_check.py sales.csv
CacheInfo(hits=999635, misses=365, maxsize=None, currsize=365)

365 misses, 999,635 hits. The cache holds exactly 365 entries.

Why it works

strptime is expensive; a dictionary lookup is cheap. With 365 distinct inputs the cache misses 365 times and hits everywhere else. Which raises the real test: what if every date is different?

The limit: when inputs don't repeat

Three data sets, five runs per version, medians. These are whole-process timings (startup and shutdown included), which is why they sit above the single in-script runs at the top. Compare plain and cached within a row, not across the two timers.

$ python3 bench.py --table
distinct dates    plain   cached  speedup  same output
           365    3.96s    1.43s    2.77x  yes
        20,000    3.70s    1.49s    2.48x  yes
     1,000,000    3.76s    3.98s    0.95x  yes
1,000,000 rows · 5 runs each, median · Python 3.14.6

Here, caching paid when inputs repeated. With every row unique, the cache cost about 6% and returned nothing.

When to use it

Try caching an expensive pure function when its inputs repeat. Count the inputs before you trust the speedup.

Use when: the same strings hit a parser thousands of times; the function is pure (same input, same output); you counted, and distinct inputs ≪ calls.
Doesn't fix: unique inputs (here, about 6% slower); loading — a separate benchmark took about 0.9 s just to read the CSV and build the rows; memory — the cache keeps every distinct key.

Start by profiling your script and inspecting its most expensive functions. Check their inputs, then benchmark any change without the profiler:

python3 -m cProfile -s tottime your_script.py

Reproduce it

Code, data generator and every capture: in the pinned comment under the video

python3 make_data.py --rows 1000000 --unique 365 --out sales.csv
python3 report.py sales.csv report.txt
python3 -m cProfile -s tottime report.py sales.csv report.txt | head -12
python3 count_distinct.py sales.csv
python3 report_cached.py sales.csv report2.txt && cmp report.txt report2.txt && echo identical
python3 cache_check.py sales.csv
python3 bench.py --table

Two timing scopes appear above on purpose. The 3.71 s and 1.20 s are single measurements timed inside the script. The table reports five-run median whole-process times. They are not the same timer, and the ratios are what transfer.

Run a Discord bot 24/7 for free on a computer you already own
codex CLI login not working on macOS: what fixed it
Discord bot not responding but still running: how to catch it

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

10 Python tricks you'll actually use, 8 of them with zero installs (with the numbers)

DevLog — Fri, 25 Sep 2026 12:43:08 +0000

Ten Python tricks, shown live on one machine. Eight ship with Python itself; two are worth a brew install. This is the write-up of the video above: every command, every output, and how each number was measured. Python 3.14.6 throughout.

1. uv: the pip workflow, minus the wait

One Rust binary that stands in for pip and venv, same workflow, familiar commands.

brew install uv
uv venv -p 3.14
UV_NO_CACHE=1 uv pip install requests flask

Three cold installs, pip versus uv, on this machine:

cold install, pip vs uv

package        pip      uv   ratio
requests     0.86s   0.15s    5.7x
flask        0.94s   0.15s    6.4x
pandas       4.07s   0.59s    6.9x

python 3.14.6 both · caches off · 5 runs each, median · alternating order

Conditions: cold installs from PyPI, caches off on both sides, five runs each, median, alternating order so neither tool benefits from going second. The installed artifacts were checked to be identical. uv 0.11.6. For the full setup, existing project and new project, see the uv video and its write-up on this blog.

2. ruff: flake8, black and isort, retired

One tool that lints and formats. Here it cold-scans a frozen snapshot of a real repo, 43 files:

brew install ruff
$ ruff check --no-cache --statistics . | head -12
94      C408    [ ] unnecessary-collection-call
84      SIM115  [ ] open-file-with-context-handler
42      BLE001  [ ] blind-except
25      PLW1510 [ ] subprocess-run-without-check
22      RUF100  [*] unused-noqa
14      I001    [-] unsorted-imports
12      FURB167 [-] regex-flag-alias
12      S110    [ ] try-except-pass
10      F401    [*] unused-import
 8      B023    [ ] function-uses-loop-variable
 5      EXE001  [ ] shebang-not-executable
 5      S112    [ ] try-except-continue
$ ruff check --no-cache . | tail -2
Found 349 errors.
[*] 62 fixable with the `--fix` option (99 hidden fixes can be enabled with the `--unsafe-fixes` option).

349 issues across 43 files in 46 ms, one timed cold run with --no-cache, ruff 0.16.5. [*] marks what --fix will handle for you.

3. f'{x=}': stop typing it twice

Put an equals sign inside the braces and Python prints the variable name and its value together. Built in since 3.8.

>>> x = 42
>>> print(f'{x=}')
x=42
>>> team = 'infra'
>>> print(f'{team=} {x*2=}')
team='infra' x*2=84

Expressions work too, as the second line shows.

4. breakpoint(): a debugger was here all along

Drop it on any line and you are inside a live debugger. No IDE, no setup. Built in since 3.7.

$ cat app.py
def score(user):
    base = user["points"] * 2
    breakpoint()
    return base + bonus(user)

def bonus(user):
    return 10 if user["team"] == "infra" else 0

print(score({"name": "mara", "team": "infra", "points": 41}))
$ python3 app.py
> /private/tmp/pydemo/app.py(3)score()
-> breakpoint()
(Pdb) p user
{'name': 'mara', 'team': 'infra', 'points': 41}
(Pdb) p base
82
(Pdb) c
92

p prints, n steps, c continues. Inspect anything, step anywhere.

5. python3 -i: crash autopsy, live

Your script crashed. Run it again with -i and Python drops you at a prompt with the script's variables still loaded.

$ cat crash.py
rows = [line.strip().split(",") for line in open("users.csv")]
header, data = rows[0], rows[1:]
total = sum(int(r[2]) for r in data)
print("total points:", total)
$ python3 -i crash.py
Traceback (most recent call last):
  File "/private/tmp/pydemo/crash.py", line 3, in
    total = sum(int(r[2]) for r in data)
  File "/private/tmp/pydemo/crash.py", line 3, in
    total = sum(int(r[2]) for r in data)
ValueError: invalid literal for int() with base 10: 'receipt-7'
>>> data[1]
['jon', 'web', 'receipt-7']
>>> header
['name', 'team', 'points']

The traceback names the value. The prompt shows which row it came from. Do the autopsy right there.

6. http.server: a web server in one line

Zero installs, and the current folder is on your local network. Hand a file to the laptop next to you, then shut it down.

$ python3 -m http.server 8000 2>/dev/null &
[1] 77428
$ curl -sI localhost:8000/orders.json | head -3
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.14.6
Date: Tue, 01 Sep 2026 14:59:55 GMT
$ curl -s localhost:8000/orders.json | head -c 80
{"orders":[{"id":9174,"user":"mara","items":[{"sku":"KB-01","qty":2,"price":39.5
$ kill %1

It serves everything in the directory to anyone on the network. Use it on a network you trust, and kill it when you are done.

7. json.tool: jq, when there's no jq

Any box with Python can pretty-print JSON straight from a pipe.

$ cat orders.json | python3 -m json.tool
{
    "orders": [
        {
            "id": 9174,
            "user": "mara",
            "items": [
                {
                    "sku": "KB-01",
                    "qty": 2,
                    "price": 39.5
                },
                ...
            ],
            "status": "shipped"
        },
        ...
    ],
    "count": 2
}

8. timeit: measure, don't guess

It runs your line enough times to trust the number and reports the best of five. Same line, two sizes; watch the cost move.

$ python3 -m timeit 'sum(range(1000))'
100000 loops, best of 5: 3.7 usec per loop
$ python3 -m timeit 'sum(range(100000))'
500 loops, best of 5: 425 usec per loop

timeit picks the loop count itself, which is why the first line ran 100,000 loops and the second 500. Those are the live runs from the recording.

9. -X importtime: find out where startup goes

Your script feels slow before it even starts? This flag breaks down where that time goes, import by import. Here it is on pandas, output saved with tee so the numbers on screen are the numbers in the file:

$ python -X importtime -c 'import pandas' 2>&1 | tee it.log | tail -6
import time:       386 |        386 |     pandas.io.sql
import time:       145 |        145 |     pandas.io.xml
import time:       104 |       4290 |   pandas.io.api
import time:        73 |         73 |   pandas.util._tester
import time:        58 |         58 |   pandas._version_meson
import time:       392 |     187650 | pandas

Columns are self time and cumulative time in microseconds. import pandas cost 187,650 µs, about 187 ms, on this run. Sort the log by the second column to find the imports worth deferring.

10. python3 -u: your logs were there all along

Python buffers print output when there is no terminal on the other end, so logs run late and a crash can eat them. -u turns buffering off and every line lands the moment it is written.

$ cat slow_logs.py
import time

for step in ["load config", "connect db", "warm cache", "start worker", "ready"]:
    print(f"[boot] {step}")
    time.sleep(0.8)
$ python3 slow_logs.py | cat        # all five lines appear at once, at the end
$ python3 -u slow_logs.py | cat     # one line every 0.8 s, as they happen

The output text is identical; the timing is not. In a container or under a process manager, -u or PYTHONUNBUFFERED=1 is the difference between seeing the last log line before a crash and not.

All ten commands

brew install uv
uv venv -p 3.14
uv pip install requests flask
brew install ruff
ruff check --no-cache .
print(f'{x=}')
breakpoint()
python3 -i app.py
python3 -m http.server 8000
python3 -m json.tool
python3 -m timeit 'sum(range(1000))'
python3 -X importtime app.py
python3 -u app.py

How things were measured, all on a Mac mini M4 Pro with Python 3.14.6: uv versus pip is three packages, cold installs from PyPI, caches off, five runs each, median, alternating order. ruff is one timed cold scan of a frozen snapshot of the repo. importtime is the exact run shown on screen. timeit outputs are the live runs; timeit picks the loop counts and reports the best of five.

Why your Python script is slow: two lines took it 3.71 s to 1.20 s
Run a Discord bot 24/7 for free on a computer you already own
npm command not found on Windows: fix the PATH

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

Generate video subtitles for free with Whisper on a Mac

DevLog — Fri, 25 Sep 2026 12:43:07 +0000

Subtitling is the part of making a video that nobody enjoys. You listen, you type, you line up the timings, and it takes longer than the edit did.

Whisper does it for you. It runs on your own machine, it costs nothing, and it does not need an internet connection once it is set up. You hand it a video file and you get a subtitle file back.

Install

There are several ways to run Whisper. On a Mac, whisper-ctranslate2 is the least trouble — one command, and it is fast.

uv tool install whisper-ctranslate2

If you are not using uv, pip install whisper-ctranslate2 works the same way. uv just keeps it out of your other Python environments.

First run

Point it at the video. You do not need to extract the audio first.

whisper-ctranslate2 --model large-v3-turbo --language ko \
  --output_format srt video.mp4

The first run downloads the model — about 1.5GB. Ours took 52 seconds including that download. After that it runs offline.

Set --language explicitly. Left to guess, it reads the opening seconds, and a quiet intro can send it to the wrong language entirely.

What you get

An .srt file appears next to your video. Plain text, opens in any editor.

1
00:00:00,000 --> 00:00:04,500
Text of the first line here.

2
00:00:05,120 --> 00:00:07,440
And the second.

That format uploads straight to YouTube and imports into every editor.

How long it takes

Measured on a Mac mini:

InputTime16.6 s of audio12 s12 s video clip12 sFirst run (incl. 1.5GB download)52 s
Faster than real time. A ten minute video finishes in under ten minutes. Start it and go do something else.

Do not drop to a smaller model

The temptation is to pick tiny or base and go faster.

For English you can get away with it. For most other languages you cannot. We tested the small models on Korean and went straight back to the large one. Fixing the mistakes by hand costs far more time than the faster run saves.

large-v3-turbo is the sensible default: it is the large model with the speed problem solved.

It is good, not perfect

Here is a real line from our own output. The speaker said "봇들" (bots) and Whisper heard "못둘".

[00:03.080 --> 00:07.000]  그 안에서 디스코드 못둘 로컬 LLM 영상 복원이 같이 돕니다.
                                        ^^^^

The places it slips are predictable:

Invented words. Product names, tool names, acronyms
Similar-sounding endings. The example above
Numbers and units. There is usually more than one way to read them aloud
Spacing. Rarely matters in a subtitle

So read it once before you ship it. But reading and fixing four lines is a different job from transcribing ten minutes from scratch.

Another use for it

It is not only for subtitles.

Use it to check synthetic speech. If you generate narration with a text-to-speech model, transcribe the result and diff it against your script. Anything it read wrong shows up immediately. We caught a homophone problem this way and fixed it in the script rather than fighting the audio.

Making that narration in the first place: Clone your own voice with a 17-second recording

Every command and number here was run on the machine this blog is written on.

Run a Discord bot 24/7 for free on a computer you already own
Why your Python script is slow: two lines took it 3.71 s to 1.20 s

Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.

DEV Community: DevLog

Search Console: When sitemap index shows 0

Why does the sitemap screen show 0 indexed pages?

How can I verify if a specific URL is actually indexed?

How do I make new posts get indexed faster?

Claude Code: Analyzing 159 Feedback Memory Files

1. Solving in fragments without context

2. Confusing reporting with actual reflection

3. Trusting its own eyes over the user's

4. Overstepping authority boundaries

5. The Korean Windows encoding trap

Claude Code PDCA: Why 100% alignment is not success

Claude CLI 401 Unauthorized Refresh Token Issue

Why claude login alone did not clear the 401

How to verify a consumed refresh token state

What happens when background scripts burn tokens

How to prevent token exhaustion during pipeline runs

Related posts

codex CLI login not working on macOS: what fixed it

Why codex login alone did not clear the 401

Breaking the trusted directory check for local projects

Related posts

Run a Discord bot 24/7 for free on a computer you already own

What you get by hosting it yourself

Step 1: survive closing the terminal

Step 2: survive a reboot

Step 3: the shape that actually works

Step 4: stop the machine from sleeping

The failure nobody plans for

Checking on it

Related

Related posts

Discord bot not responding but still running: how to catch it

Why your supervisor misses this

Signals that lie to you

Watch work, not life

Choosing the threshold

Keep the watcher light

A quick audit

Related

Related posts

Getting started with uv: an existing project, a new project, and the numbers (pip 2.46 s uv 0.38 s)

The two commands first

Install

Replace pip in a project you already have

The numbers, with the conditions

Start a new project: init, add, sync

Run without activating

Python versions and tools

Three things to check before moving a real project

What to do today

Related posts

ffmpeg: Convert video to optimized GIF on macOS

Using a two-step conversion for optimization

Performance Comparison

Why your Python script is slow: two lines took it 3.71 s to 1.20 s

The result first

What the script does

Ask Python where the time goes

A profile says which function, not why

The two-line change

Did the prediction hold?

Why it works

The limit: when inputs don't repeat

When to use it

Reproduce it

Related posts

10 Python tricks you'll actually use, 8 of them with zero installs (with the numbers)

1. uv: the pip workflow, minus the wait

2. ruff: flake8, black and isort, retired

3. f'{x=}': stop typing it twice

4. breakpoint(): a debugger was here all along

5. python3 -i: crash autopsy, live

6. http.server: a web server in one line

7. json.tool: jq, when there's no jq

8. timeit: measure, don't guess

9. -X importtime: find out where startup goes

10. python3 -u: your logs were there all along

All ten commands

Related posts