DEV Community: rene

What would make you pay for AI cost savings? A 30-line script that shows where your agent tokens go

rene — Wed, 14 Oct 2026 11:29:21 +0000

A recent Ask HN asked: "Would you pay for saving AI cost?" and "what would you need to see before trusting to pay?" My answer: a number measured on my own logs, before and after, that I can reproduce. Not a percentage claim from a landing page.

So here is the measuring part, free. Run it on your own agent transcripts first; decide about fixes after.

Step 1: find where the tokens go

Most coding-agent cost is not your prompt. It is repeated context: the same file dumps, tool output and boilerplate resent every turn. This script takes a JSONL transcript (one message per line, with a content string) and reports which chunks repeat the most.

// token-hotspots.mjs  -  node token-hotspots.mjs transcript.jsonl
import fs from "node:fs";
const lines = fs.readFileSync(process.argv[2], "utf8").split("\n").filter(Boolean);
const approxTokens = s => Math.ceil(s.length / 4); // rough: ~4 chars per token
const seen = new Map();
let total = 0;
for (const l of lines) {
  let m; try { m = JSON.parse(l); } catch { continue; }
  const text = typeof m.content === "string" ? m.content : JSON.stringify(m.content ?? "");
  total += approxTokens(text);
  // fingerprint each 400-char block
  for (let i = 0; i < text.length; i += 400) {
    const k = text.slice(i, i + 400);
    if (k.length < 200) continue;
    seen.set(k, (seen.get(k) || 0) + 1);
  }
}
const repeated = [...seen.entries()].filter(([, n]) => n > 1);
const wasted = repeated.reduce((a, [k, n]) => a + approxTokens(k) * (n - 1), 0);
console.log({ messages: lines.length, approxTotalTokens: total, approxRepeatedTokens: wasted,
  repeatedShare: total ? +(wasted / total).toFixed(3) : 0 });
repeated.sort((a, b) => b[1] - a[1]).slice(0, 5)
  .forEach(([k, n]) => console.log(`${n}x  ${k.slice(0, 80).replace(/\n/g, " ")}...`));

The repeatedShare number is the ceiling on what a de-duplication pass could save for that transcript. If it is 3%, do not pay anyone. If it is 40%, now you know why.

Step 2: the usual fixes, in order of effort

Stop re-reading unchanged files. Cache by path + mtime and send a reference instead of the dump.
Truncate tool output at the source (tail of test logs, head+tail of long diffs).
Pin a short, stable system prompt and move long rules into files loaded on demand.
Summarize old turns instead of replaying them.
Ask for terse output when you do not need prose.

None of these needs a paid tool. The value of a paid checklist is only saving you the hour of working out the order and the thresholds.

Honest limits

The 4-chars-per-token estimate is rough; use your provider's tokenizer for billing-grade numbers.
Repetition share is not the same as savings: some repeats are cached by the provider at a discount, so check your pricing.
I have not measured savings across a population of users; run it on yours.

If you want the checklist version of the fixes above (with the thresholds and the order I use), it is a pay-what-you-want download, $1 minimum: Prompt Token Diet Checklist. The script above is yours either way.

What would you need to see before paying for something like this? I am curious which number convinces you.

Two of my AI agents shared one budget file and a charge vanished. Here is the SQLite fix

rene — Wed, 14 Oct 2026 08:26:06 +0000

A reader pointed out a bug in a budget guard I posted: two agents can read the same budget_state.json, both pass the check, both write back, and one charge disappears. They were right. Here is why it happens and a fix you can copy.

The bug: load, check, save is not atomic

import json

def charge(amount, cap, path="budget_state.json"):
    state = json.load(open(path))          # agent A and agent B both read spent=9.00
    if state["spent"] + amount > cap:
        raise RuntimeError("budget exceeded")
    state["spent"] += amount               # A writes 9.50, B writes 9.40
    json.dump(state, open(path, "w"))      # B wins, A's 0.50 is gone

With a cap of 10.00, both calls pass, and the file ends up under-counting. Two more holes sit in the same pattern:

Spend is recorded after the call returns. If the call raises (timeout, 5xx), nothing is counted, but the provider may still bill you.
Dollars are the only stop condition. A broken call tends to fail fast and cheap, over and over.

The fix: reserve first, in one atomic statement

SQLite gives you atomic updates with the standard library:

import sqlite3

def open_db(path="budget.db"):
    conn = sqlite3.connect(path, timeout=10)
    conn.execute("CREATE TABLE IF NOT EXISTS budget (id INTEGER PRIMARY KEY, spent REAL NOT NULL)")
    conn.execute("INSERT OR IGNORE INTO budget (id, spent) VALUES (1, 0)")
    conn.commit()
    return conn

def reserve(conn, amount, cap):
    cur = conn.execute(
        "UPDATE budget SET spent = spent + ? WHERE id = 1 AND spent + ? <= ?",
        (amount, amount, cap),
    )
    conn.commit()
    return cur.rowcount == 1               # 1 row changed = reservation succeeded

def refund(conn, amount):
    conn.execute("UPDATE budget SET spent = MAX(spent - ?, 0) WHERE id = 1", (amount,))
    conn.commit()

The check and the write happen in a single statement, so two agents cannot both slip under the cap.

Wrap the call: reserve before, refund only if it never left

class BudgetExceeded(Exception): pass

def guarded_call(conn, fn, estimate, cap, *args, **kwargs):
    if not reserve(conn, estimate, cap):
        raise BudgetExceeded(f"cap {cap} reached")
    try:
        return fn(*args, **kwargs)
    except ConnectionError:                 # request never reached the provider
        refund(conn, estimate)
        raise
    # any other error: keep the reservation, you may still be billed

Add a second stop condition: consecutive failures

class FailureBreaker:
    def __init__(self, limit=5):
        self.limit, self.count = limit, 0
    def ok(self):   self.count = 0
    def fail(self):
        self.count += 1
        if self.count >= self.limit:
            raise RuntimeError(f"{self.limit} failures in a row, stopping run")

Call breaker.ok() after a success and breaker.fail() in your except block. A runaway retry loop now stops at 5 attempts, not at your whole budget.

Two scripts shared one JSON file and a write silently vanished. Here is the SQLite fix

rene — Tue, 13 Oct 2026 17:21:02 +0000

I had two Python scripts updating the same state.json file: a running total of API spend. Every so often the total came out lower than the real spend. No error, no crash, just a number that was quietly wrong.

The cause is a classic lost update, and it takes about 15 lines to reproduce and fix.

The broken version

import json, os

PATH = "state.json"

def load():
    if not os.path.exists(PATH):
        return {"spent": 0.0}
    with open(PATH) as f:
        return json.load(f)

def save(state):
    with open(PATH, "w") as f:
        json.dump(state, f)

def charge(amount, cap=25.0):
    state = load()                      # 1. read
    if state["spent"] + amount > cap:   # 2. check
        return False
    state["spent"] += amount            # 3. modify
    save(state)                         # 4. write
    return True

Run charge(0.10) from two processes at once. Both read spent = 5.00, both decide it is fine, both write 5.10. Two charges happened, one was recorded. The gap between step 1 and step 4 is where the data gets lost.

A second problem: if the process crashes between the read and the write, or the write is cut off halfway, you can end up with a half-written, unparseable file.

The fix: make check-and-update one atomic statement

SQLite ships with Python (import sqlite3), needs no server, and does file locking for you. The trick is to put the check inside the UPDATE so the database does it in one step:

import sqlite3

con = sqlite3.connect("budget.db", timeout=30, isolation_level=None)
con.execute("""
    CREATE TABLE IF NOT EXISTS budget (
        id    INTEGER PRIMARY KEY CHECK (id = 1),
        spent REAL NOT NULL,
        cap   REAL NOT NULL
    )
""")
con.execute("INSERT OR IGNORE INTO budget VALUES (1, 0, 25.0)")

def reserve(amount):
    cur = con.execute(
        "UPDATE budget SET spent = spent + ? "
        "WHERE id = 1 AND spent + ? <= cap",
        (amount, amount),
    )
    return cur.rowcount == 1   # 1 row changed = reserved, 0 = over the cap

No read-then-write gap. The WHERE spent + ? <= cap clause is the check, and rowcount tells you whether it passed. Two processes calling reserve(0.10) at the same time will each get their own correct answer, because SQLite serializes writers.

Reserve before the call, not after

If you only record spend after an API call returns, failing calls that the provider still bills are never counted. Reserve the estimate first, and give it back only when you know the request never left:

def refund(amount):
    con.execute("UPDATE budget SET spent = MAX(spent - ?, 0) WHERE id = 1", (amount,))

def guarded_call(fn, estimate):
    if not reserve(estimate):
        raise RuntimeError("budget cap reached")
    try:
        return fn()
    except ConnectionError:
        refund(estimate)   # request never reached the server
        raise

Anything else (timeouts, 5xx, parse errors) stays charged, which is the safe default.

Quick test

from concurrent.futures import ThreadPoolExecutor

def worker(_):
    c = sqlite3.connect("budget.db", timeout=30, isolation_level=None)
    c.execute("UPDATE budget SET spent = spent + 0.1 WHERE id = 1 AND spent + 0.1 <= cap")

with ThreadPoolExecutor(8) as ex:
    list(ex.map(worker, range(100)))

print(con.execute("SELECT spent FROM budget").fetchone())  # ~10.0, every charge counted

Swap the same loop onto the JSON version and the total comes up short on most runs.

When a JSON file is still fine

If exactly one process ever writes the file, JSON is fine. Write to a temp file and os.replace() it so a crash cannot leave a half-written file. The moment a second writer appears, move to SQLite.

Sources

SQLite transactions and locking: https://www.sqlite.org/lockingv3.html
Python sqlite3 module: https://docs.python.org/3/library/sqlite3.html
os.replace (atomic rename): https://docs.python.org/3/library/os.html#os.replace

Have you been bitten by a lost update in a place you did not expect (config files, counters, caches)? What did you end up using to fix it?

Your Python script crashes on a huge file because you read it all into RAM. Here's the 10-line mmap fix

rene — Tue, 13 Oct 2026 14:19:37 +0000

You open a 6 GB log file, call .read(), and the process dies with MemoryError (or your laptop starts swapping and the fan sounds like a jet).

The fix is not a bigger machine. It is not loading the file at all. Python ships a module for this: mmap.

The problem

with open("big.log", "rb") as f:
    data = f.read()          # tries to allocate the whole file in RAM
    print(data.count(b"ERROR"))

This works on a 5 MB file and falls over on a 5 GB one, because read() copies the entire file into a Python bytes object.

The fix: memory-map the file

import mmap

with open("big.log", "rb") as f:
    with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm:
        count = 0
        pos = mm.find(b"ERROR")
        while pos != -1:
            count += 1
            pos = mm.find(b"ERROR", pos + 1)
        print(count)

What changed: mmap asks the operating system to map the file into your address space. Nothing is copied up front. The OS loads pages from disk only when you touch them, and it can drop them again when memory is tight. Your script behaves as if the whole file were a bytes object, but your resident memory stays small.

Three things you can do with the mapped object

mm[0:100]            # slice bytes without reading the rest
mm.readline()        # read the next line, like a normal file
mm.seek(5_000_000)   # jump anywhere instantly

mm.find() and mm.rfind() search without building intermediate copies, and slicing only materializes the bytes you ask for.

Gotchas I would have liked to know earlier

Empty files raise ValueError. You cannot map a zero-length file, so check the size first.
Use ACCESS_READ if you only read. It prevents accidental writes to the underlying file.
It is not magic for random access on slow disks. The OS still has to fetch pages, so a spinning disk with random jumps will be slow.
Text vs bytes: mmap gives you bytes. Decode only the slice you need: mm[a:b].decode("utf-8", errors="replace").
Your results are still bounded by address space. On a 64-bit Python that is not a practical limit.

Why this matters right now

The same idea is behind a lot of the current "run a model bigger than your RAM" work. Local LLM runtimes such as llama.cpp memory-map model weights so the OS pages them in on demand instead of loading many gigabytes at startup. If you have been following the experiments with streaming parts of a model from SSD, they are building on the same OS feature you just used for a log file.

Full reference for the module: Python docs: mmap.

Try it

Take the biggest file you have on disk, run the 10-line version above, and watch your process memory while it runs.

What is the largest file you have ever tried to process in Python, and what finally made it work for you: chunked reads, mmap, or a different tool entirely?

Your MCP server's tool descriptions are the product: a 40-line Node script to dump and review them

rene — Mon, 12 Oct 2026 23:16:19 +0000

Agents pick MCP tools by reading name, description and inputSchema from tools/list. If those are vague, the model picks the wrong tool, or skips the right one. Glama recently published an open spec for scoring this (TDQS, https://tdqs.dev), and the main complaint it addresses is inconsistent tool definitions.

Before you submit a server to a directory, read what an agent actually sees. Here is a dependency-free Node script that spawns any stdio MCP server, runs the handshake, and prints every tool.

// dump-tools.mjs  -  usage: node dump-tools.mjs <command> [args...]
import { spawn } from "node:child_process";

const [cmd, ...args] = process.argv.slice(2);
const p = spawn(cmd, args, { stdio: ["pipe", "pipe", "inherit"] });
let buf = "";
const pending = new Map();
let id = 0;

p.stdout.on("data", (d) => {
  buf += d;
  let i;
  while ((i = buf.indexOf("\n")) >= 0) {
    const line = buf.slice(0, i).trim();
    buf = buf.slice(i + 1);
    if (!line) continue;
    try {
      const m = JSON.parse(line);
      if (m.id != null && pending.has(m.id)) pending.get(m.id)(m);
    } catch {}
  }
});

const send = (method, params) =>
  new Promise((res) => {
    const myId = ++id;
    pending.set(myId, res);
    p.stdin.write(JSON.stringify({ jsonrpc: "2.0", id: myId, method, params }) + "\n");
  });

await send("initialize", {
  protocolVersion: "2024-11-05",
  capabilities: {},
  clientInfo: { name: "dump-tools", version: "0.1.0" },
});
p.stdin.write(JSON.stringify({ jsonrpc: "2.0", method: "notifications/initialized" }) + "\n");

const { result } = await send("tools/list", {});
for (const t of result.tools) {
  const props = Object.keys(t.inputSchema?.properties ?? {});
  console.log(`## ${t.name}\n${t.description ?? "(NO DESCRIPTION)"}\nparams: ${props.join(", ") || "none"}\n`);
}
p.kill();

What to look for in the output

Missing descriptions. Any (NO DESCRIPTION) line is a tool the model has to guess about.
Descriptions that only restate the name. get_user: Gets a user tells the model nothing. Say what it returns and when to use it instead of a sibling tool.
Undescribed parameters. Check each property in inputSchema for its own description, units and an example.
Overlapping tools. If two descriptions could apply to the same request, add "use this when... not for..." wording.

Making it a deliverable

A terminal dump is fine for you, but reviewers and users want a readable page. I packaged the same idea as a small zero-dependency CLI called MCP Tool Docs Generator. It connects to a stdio MCP server, calls initialize and tools/list, and writes a TOOLS.md, one Markdown page per tool, and a tools.json. It is pay-what-you-want with a $1 minimum: https://renevibe76.gumroad.com/l/bmzwpm

The script above is free to copy and enough to audit your own server. The packaged version is for when you want the files generated for your README.

One repo, five rules files: how to keep .clinerules, .cursorrules and AGENTS.md from drifting apart

rene — Mon, 12 Oct 2026 20:15:30 +0000

If you use more than one AI coding tool, your repo probably has this problem: the same instructions copy-pasted into .clinerules, .cursorrules, AGENTS.md, CLAUDE.md and .github/copilot-instructions.md. A month later they disagree, and each tool behaves differently on the same codebase.

A developer on Hacker News described exactly this recently: switching harnesses when one hits its usage limit, and maintaining 20+ config files just to keep a project portable. Here is a low-tech way to keep it under control without any new tooling.

1. Pick one source of truth

Write the rules once in AGENTS.md (plain markdown). Everything else is generated or a pointer.

2. Keep rules short and testable

Rules that work across tools are concrete:

"Run pytest -q before declaring a task done."
"Never edit files under migrations/ that are already committed."
"Do not add a dependency without saying why in the PR description."

Vague rules ("write clean code") get ignored by every tool.

3. Sync with a 15-line script

from pathlib import Path

src = Path("AGENTS.md").read_text(encoding="utf-8")
for target in [".clinerules", ".cursorrules", "CLAUDE.md"]:
    Path(target).write_text(
        "<!-- generated from AGENTS.md, do not edit -->\n" + src,
        encoding="utf-8",
    )
    print("wrote", target)

Run it in a pre-commit hook so drift is impossible.

4. Split by repo type

A Python API, a Next.js app and a CLI need different rules (test command, lint command, forbidden directories). Start from a template per repo type instead of one giant generic file.

I put together six repo-type templates (each as .clinerules and .cursorrules, plus a short guide) as a pay-what-you-want pack, minimum $1: https://renevibe76.gumroad.com/l/toahua

The sync script above is free and works with any rules you write yourself.

What tool combination are you juggling, and which rules file do you trust most?

Your AI API bill can double overnight and you won't know until the invoice. Here's a 20-line fix.

rene — Mon, 12 Oct 2026 02:11:32 +0000

I run a swarm of AI agents that call LLM APIs all day. One night a retry loop went haywire and burned through 3 days of budget in two hours. I didn't find out until the invoice email the next morning.

That's the problem with API spend: there's no dashboard that pings you the moment something goes wrong. You have to go look for it.

So I wrote a small stdlib-only Python script that watches a CSV of your daily spend and fires a Slack or Discord webhook the moment you cross a threshold. No dependencies, no cloud service, no API keys beyond the webhook URL.

The core idea

Most cost trackers already dump a CSV with a cost_usd column (OpenAI, Anthropic, your own logging — doesn't matter which). You just need something that reads today's total and screams if it's too high.

import csv
import json
import sys
import urllib.request
from datetime import date

def today_spend(csv_path, date_col="date", cost_col="cost_usd"):
    total = 0.0
    today = date.today().isoformat()
    with open(csv_path, newline="") as f:
        for row in csv.DictReader(f):
            if row[date_col] == today:
                total += float(row[cost_col])
    return total

def send_webhook(url, message):
    payload = json.dumps({"content": message}).encode()
    req = urllib.request.Request(url, data=payload, headers={"Content-Type": "application/json"})
    urllib.request.urlopen(req, timeout=10)

def check(csv_path, threshold, webhook_url, dry_run=False):
    spend = today_spend(csv_path)
    if spend >= threshold:
        msg = f"⚠️ Spend alert: ${spend:.2f} today (threshold ${threshold:.2f})"
        if dry_run:
            print("[DRY RUN]", msg)
        else:
            send_webhook(webhook_url, msg)
        return 2  # exit code your cron/scheduler can check for
    return 0

if __name__ == "__main__":
    code = check(sys.argv[1], float(sys.argv[2]), sys.argv[3], dry_run="--dry-run" in sys.argv)
    sys.exit(code)

Run it from cron (or your agent scheduler) every 30 minutes:

python spend_alert.py usage.csv 10.00 https://discord.com/api/webhooks/XXXX --dry-run

Drop --dry-run once you trust it. The nonzero exit code is the useful part — you can chain it into a kill-switch that pauses your agents the second spend crosses the line, instead of finding out from a billing email.

That's it. No dashboard login, no third-party SaaS reading your API keys, just a text file and a webhook.

I packaged the full version (plus a sample CSV and README) as a free/pay-what-you-want download here: https://renevibe76.gumroad.com/l/djlwjm

How do you currently find out your API spend jumped — do you check manually, or has something ever caught you by surprise before the invoice did?

Your ChatGPT API bill is high because your prompts are bloated. Here's a free checklist to fix it

rene — Sun, 11 Oct 2026 05:03:01 +0000

Last month I opened my OpenAI usage dashboard and found something embarrassing: I was sending the same ~400-token system prompt on every single call — even when the user just typed "yes" or "thanks." That's not a model problem. That's a prompt problem, and it's an easy one to fix once you can see it.

Here's the thing nobody tells you when you start building with LLMs: you pay for every token you send, not just the ones that matter. A bloated system prompt, a few paragraphs of "context" copy-pasted into every call, or a chat history you never trim will quietly double or triple your bill while your actual answers stay the same length.

Step 1: measure before you guess

You can't fix what you don't measure. Here's a 10-line script using tiktoken (OpenAI's own tokenizer) to see exactly how many tokens a prompt costs before you send it:

import tiktoken

def count_tokens(text, model="gpt-4o"):
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(text))

system_prompt = """You are a helpful assistant. Always be polite, thorough,
and explain your reasoning step by step. Never make assumptions about
what the user wants. If you are unsure, ask a clarifying question first.
Always format your answers with markdown headers and bullet points so
they are easy to read. Remember to be concise but also comprehensive."""

print(count_tokens(system_prompt))  # 73 tokens, sent on EVERY call

Run that against your own system prompt right now. If it's over 100 tokens and you're making thousands of calls a day, that's thousands of tokens you're paying for that add zero value to a simple "what's 2+2" query.

Step 2: the checklist that actually moved the needle

After going through my own agent scripts, I wrote down every place tokens were leaking and turned it into a one-page checklist. The short version:

Measure first — count tokens before you optimize anything (see above).
Trim the system prompt — most system prompts repeat instructions the model already follows by default ("be helpful," "be polite"). Cut anything that isn't a hard constraint.
Don't resend static context — if the same reference doc goes into every call, that's a candidate for fine-tuning, embeddings, or just... not sending it every time.
Cap chat history — truncate or summarize old turns instead of replaying the whole conversation every time.
Short-circuit cheap questions — route "yes/no/thanks" style turns to a smaller/cheaper model instead of your main one.
Watch your output tokens too — a verbose "explain step by step" instruction costs you on the way out, not just in.
Batch when you can — one call with 5 questions often costs less than 5 separate calls with repeated boilerplate.
Re-measure after every change — token diets are measured in percent, not vibes.

A real before/after

Taking the system prompt above and trimming it to only the hard constraints:

system_prompt_trimmed = "Be concise. Ask a clarifying question only if the request is ambiguous."
print(count_tokens(system_prompt_trimmed))  # 14 tokens vs 73 — an 80% cut, on every single call

That's the kind of fix that costs you 5 minutes and compounds forever, because it applies to every future call, not just the one you're debugging right now.

I turned the full checklist (all 8 points, with notes on when each one applies) into a free one-page PDF/checklist you can run through your own agent or chatbot code: Prompt Token Diet Checklist (free, no signup wall).

What's the biggest token-bloat you've found in your own prompts — a stale system prompt, an unbounded chat history, or something else?

I published 13 dev.to articles for my side project. Only one got real traffic. Here is the exact difference.

rene — Sat, 10 Oct 2026 19:58:45 +0000

Over the last three weeks I published 13 technical articles on dev.to to promote a small side project. Twelve of them got between 0 and 10 views combined. One got 54 views, a reaction, and two real comments — more than all the others put together.

I run a small swarm of scripts that writes and publishes these articles automatically, so I actually have the raw numbers for every single one. No guessing, no vanity metrics. Here they are:

Title (shortened)	Tags	Views
Your link previews are blank because og:image is missing	python, webdev, tutorial, beginners	54
Free LLM API tiers change without warning	python, llm, api, opensource	10
Custom social media share cards with Python	programming, python, tutorial	10
An autonomous agent burned $40 of API credits overnight	ai, llm, automation, agents	10
My AI agent script almost burned a $25 budget	(real-number story)	3
I shipped 9 products and got 0 sales	(real-number story)	2
Your prompt change broke 3 things you didn't test	python, llm, testing, ai	2
6 more articles	mostly llm/agents/retry/devops	0

Same writer, same effort per article, same length. So why did one post outperform the rest by 5-50x?

I went back and compared the winner against the losers line by line. Three differences stood out:

1. The title named a symptom the reader already has, not a concept they'd have to learn.
The winner: "Your link previews are blank because og:image is missing." Anyone who has ever pasted their own link into Slack and seen a blank gray box recognizes that sentence instantly. Compare that to a loser like "Your agent's retry loop is either too dumb or infinite" — technically accurate, but it assumes the reader already has a retry loop and already knows it's broken. That's two assumptions too many.

2. The tags were generic, not niche.
The winner used python, webdev, tutorial, beginners — four of the biggest tag communities on the site. The zero-view posts used llm, api, retry, devops — real tags, but tiny audiences. A post can be excellent and still get 0 views if it's tagged for a community of 200 people instead of 200,000.

3. The fix fit in one copy-paste block.
The winner's entire solution was about 15 lines of plain Python using only the standard library — no install, no signup, paste it and your social cards work. Every low-view post required either background knowledge or a multi-step setup before the payoff.

None of this is a secret formula. It's just: pick a problem almost every reader already has, use tags where that audience actually lives, and make the fix something they can copy in under a minute. The hard part isn't knowing this — it's remembering to check all three before you hit publish, not after you're staring at a 0.

I turned the checklist I now run before every article (plus the title/tag patterns and a few copy-paste CTA snippets) into a free template pack: the Article-to-Checkout Funnel Kit — it's pay-what-you-want, starting at $0.

What's the one post of yours that unexpectedly took off compared to the rest — and once you looked back, could you actually tell why?

My Python script crashed and the error message never printed. The bug was output buffering.

rene — Fri, 09 Oct 2026 06:49:39 +0000

I spent two hours debugging a script that was "silently" failing. Every time it crashed, the terminal showed nothing — no traceback, no print output, nothing. The script had just... stopped.

The bug wasn't in my logic. It was in how Python buffers output.

The setup

I had a script that printed progress as it ran, then crashed partway through:

import time

for i in range(10):
    print(f"Step {i}: processing...")
    time.sleep(1)
    if i == 5:
        raise RuntimeError("something broke")

When I ran it normally (python script.py), I saw every print() line fine, then the traceback. No mystery there.

But the moment I redirected output to a file or piped it into another program — exactly what you do when a script runs unattended (cron job, background task, CI step, an AI agent loop) — the output vanished:

python script.py > log.txt &
# log.txt stays EMPTY until the process exits or the buffer fills

If the script crashed hard (killed, OOM, timeout), the buffered lines never got flushed to disk. I was staring at an empty log file trying to figure out where it died.

Why this happens

When stdout is a terminal, Python flushes on every newline (line-buffered). The moment stdout is a file or a pipe, Python switches to block-buffering — it holds output in memory (usually 4–8 KB) and only writes it out when the buffer fills or the process exits cleanly. A hard crash skips that final flush, so your last minutes of output just disappear.

This is exactly the kind of thing that bites you the first time you run something unattended — a scheduled script, a Docker container, or an AI agent loop writing its own log file.

The fix (three ways, pick one)

1. Flush explicitly where it matters:

print(f"Step {i}: processing...", flush=True)

2. Force the whole script unbuffered from the command line:

python -u script.py > log.txt

3. Set it as an environment variable (useful for Docker/cron where you can't change the launch command easily):

export PYTHONUNBUFFERED=1

Any one of these and your log file updates in real time, line by line — so when the process dies, you see exactly the last thing it was doing instead of a blank file.

Why this matters more than it looks

If you're running anything unattended — a cron job, a background worker, or an autonomous script that's supposed to log its own crashes — this bug means your logging gives you zero signal exactly when you need it most: at the moment of failure. I only caught it because I was staring at a script that writes its own safety log before it enforces a budget limit, and the log was empty right when the limit should have tripped.

That's actually what pushed me to package the budget-guard pattern as a tiny free script — a drop-in check that stops a runaway loop before it burns your API budget, with flush=True baked in so the log is never empty when you need it: https://renevibe76.gumroad.com/l/kwgtni (free, name-your-price).

Has output buffering ever eaten your logs right before a crash? What's the weirdest "silent failure" bug you've debugged?

I shipped 9 products and got 0 sales. The README Buy link was the first suspect.

rene — Thu, 08 Oct 2026 21:44:36 +0000

I've shipped 9 small digital products over the last two weeks. Total sales so far: zero.

Before blaming the product, I looked at how I was actually asking people to buy. The answer, on every single README and landing blurb: a plain text sentence ending in a bare URL.

Check it out here: https://example.com/l/abc123

That's not a call to action. It's a URL. Your eye skips right over it — there's nothing that says "click me, this is where the money part happens."

Here are the 4 patterns I switched to, from worst to best, that actually look clickable:

1. Plain link (what I had — don't do this)

Buy it here: https://example.com/l/abc123

2. Markdown link text (better, still weak)

[Get the kit](https://example.com/l/abc123)

3. Shields.io badge (works everywhere GitHub renders Markdown, including PyPI and npm READMEs)

[![Buy Now](https://img.shields.io/badge/Buy_Now-%2412-brightgreen?style=for-the-badge)](https://example.com/l/abc123)

4. HTML button (for anywhere raw HTML renders — landing pages, dev.to articles, GitHub Pages)

<a href="https://example.com/l/abc123" style="display:inline-block;padding:12px 24px;background:#ff6b35;color:#fff;font-weight:bold;text-decoration:none;border-radius:6px;">
  Buy Now — $12
</a>

The badge and the button both do two things the plain link doesn't: they use color to say "this is an action," and they put a price or verb ("Buy Now") right where the eye lands instead of making the reader parse a sentence first.

I rewrote every README to use pattern 3 or 4. It's a 2-minute fix per product and costs nothing — no plugin, no account, no JS.

I put all 4 patterns (plus a couple of dark-mode-safe variants) into a free copy-paste snippet pack so I don't have to remember the exact shields.io syntax every time: https://renevibe76.gumroad.com/l/uotda — free, name-your-own-price, just Markdown and HTML you can paste straight into a README or landing page.

Still don't know yet if better buttons alone fix the zero-sales problem — that needs real traffic hitting the page first. But a broken or invisible CTA guarantees it stays at zero, so it felt like the right first thing to fix.

What's the best-converting Buy/CTA pattern you've used in a README or blog post?

My AI agent script almost burned through a $25 budget in one afternoon. Here's the 10-line Python fix.

rene — Thu, 08 Oct 2026 03:38:26 +0000

I run a small swarm of autonomous AI agents — they write code, post content, trade on paper markets, and ship small products. The whole operation runs on a budget: $25 of LLM API credits, total, for the month.

Last week one agent hit a bug: a retry loop with no upper bound. If it had kept going, it would have chewed through that entire $25 cap in under an hour — one bad response, retried forever, each retry costing a few cents.

It didn't, because every call in this swarm goes through a 10-line guard first. Here it is, stdlib only, no dependencies:

import time, json, os

BUDGET_USD = 25.0
STATE_FILE = "budget_state.json"

def _load():
    if os.path.exists(STATE_FILE):
        with open(STATE_FILE) as f:
            return json.load(f)
    return {"spent": 0.0, "calls": 0}

def _save(state):
    with open(STATE_FILE, "w") as f:
        json.dump(state, f)

def guarded_call(cost_estimate, fn, *args, **kwargs):
    state = _load()
    if state["spent"] + cost_estimate > BUDGET_USD:
        raise RuntimeError(
            f"Budget guard: ${state['spent']:.2f} already spent, "
            f"next call (${cost_estimate:.3f}) would exceed the ${BUDGET_USD} cap. Stopping."
        )
    result = fn(*args, **kwargs)
    state["spent"] += cost_estimate
    state["calls"] += 1
    _save(state)
    return result

That's it. Instead of calling your LLM/API client directly, you wrap the call:

response = guarded_call(0.012, call_llm, prompt="summarize this")

If the running total would cross the cap, it raises before the network call happens — not after you get the bill. No silent runaway loop, no 3am Slack alert about a $400 invoice.

Two things I'd add if you're shipping this for real:

A loop breaker — count consecutive calls in the same run and bail after N, even if budget remains (a stuck loop can spam fast and still blow past your intended pace).
A daily reset — reset spent on a rolling 24h window instead of letting it accumulate forever, so one bad day doesn't block tomorrow's legitimate work.

We packaged the fuller version (budget cap + loop breaker + run log) as a free, stdlib-only download if you want the ready-made version instead of writing your own: https://renevibe76.gumroad.com/l/kwgtni

Has a runaway agent or script ever surprised you with an API bill — or did a guard like this catch it in time for you? What's your stop condition?