I run a small homelab: an Ubuntu server, a pile of Docker Compose stacks, and somewhere around thirty self-hosted services: Radarr, Sonarr, Plex, Home Assistant, Grafana, ntfy, the usual suspects. And like every homelabber, I write a lot of small scripts. Check disk usage, ping an API, send a notification when a backup finishes or a disk starts making that noise disks shouldn't make.

Every one of those scripts needed something: an API key, a URL, a chatID. And every time I made the same decision: “I'll just hardcode it here for now.” Now, “for now” in a homelab is a unit of time that rounds up to forever.

The day I decided to rotate my Telegram bot token, I discovered it was copy/pasted into six different files. Rotating it meant grepping my entire scripts folder and hoping I didn't miss one. (I missed one. My disk-usage alert went silent for two weeks. The disk was fine btw.)

This is exactly the kind of sloppy chaos a homelab collects if you don't stop it early. So I stopped it.

Why not BitWarden / Vault / 1Password / ...?

Because this is a single-user homelab, not a company.

HashiCorp Vault for example is a nice piece of software that would also be, in my house, a self-hosted service whose entire job is to be a dependency for my other self-hosted services. One more thing to run, back up, unseal, and debug at 11pm when notifications stop working and I can't tell whether the problem is my script or my secrets infrastructure.

My requirements were shorter than most tools' install instructions: one place for all config and secrets, readable by any bash or Python script, and simple enough that I can read the whole thing and fix it in 30 seconds at 11pm. That last one is the real requirement. Everything else is negotiable.

So I did the least fashionable thing possible: one INI file and a tiny bash helper.

The setup

All config lives in /etc/mini/mini.conf.ini, one section per service or topic:

[telegram]
bot_token = 123456:FAKE-EXAMPLE-TOKEN
chat_id = 999999999

[plex]
url = https://plex.example.local:32400
api_token = fake-example-token

[defaults]
timeout = 20

(All illustrative, obviously. My real chatID has way more nines.)

Any script that needs a value calls mini_conf <section> <key>:

TOKEN=$(mini_conf telegram bot_token)
curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" ...

That's the whole interface. The script doesn't know or care where config comes from. It just asks. Rotating a key is now a one-line edit in one file, and every script picks it up on the next run.

The script

Here's mini_conf in full. About 40 lines, no dependencies beyond bash and awk:

#!/usr/bin/env bash
# creator: pven, supported by Claude
# version: v1.3
set -euo pipefail

INI="${MINI_INI:-/etc/mini/mini.conf.ini}"

# usage: mini_conf <section> <key> [default]
mini_conf() {
  local section="$1" key="$2" def="${3-}" val=""

  # ENV override: MINI_<SECTION>_<KEY>
  local envkey="MINI_${section}_${key}"
  envkey="$(echo "$envkey" | tr '[:lower:]-' '[:upper:]_')"
  if [[ -n "${!envkey-}" ]]; then printf '%s\n' "${!envkey}"; return 0; fi

  val="$(awk -v s="[$section]" -v k="$key" -v d="$def" '
    BEGIN{ FS="="; inside=0; s=tolower(s); k=tolower(k) }
    { sub(/\r$/,"") }
    /^\s*\[/ { if (tolower($0) == s) { inside=1 } else { inside=0 } }
    /^\s*([#;]|$)/ { next }
    inside && tolower($1) ~ "^[[:space:]]*" k "[[:space:]]*$" {
      sub(/^[^=]*=/,"")
      gsub(/^[ \t]+|[ \t]+$/,"")
      print
      found=1
      exit
    }
    END{ if (!found && length(d)) print d }
  ' "$INI")"

  if [[ -n "$val" ]]; then printf '%s\n' "$val"; else printf '%s\n' "$def"; fi
}

mini_conf "$@"

Let's walk through the interesting parts.

The awk INI parser

The heavy lifting is one awk program. It splits lines on =, and tracks a single state variable: inside. Every time it sees a line starting with [, it checks whether that's the section we want and flips inside on or off. Comment lines (# or ;) and blank lines are skipped.

When we're inside the right section and field one matches our key, it strips everything up to the first =, trims surrounding whitespace, prints the value, and exits. First match wins. If we fall off the end without a match, the END block prints the default (if one was given).

Is it a complete INI parser? No. It doesn't do quoted values, multiline values, or interpolation. It also doesn't need to, because I control both ends of this transaction.

Case-insensitive everything

Notice the tolower() calls sprinkled everywhere: both the section header comparison and the key match are case-insensitive. This wasn't design foresight. This was me repeatedly writing [Telegram] in the config and mini_conf telegram ... in scripts, then spending ten minutes debugging an empty variable. After the third time, I stopped fighting my own fingers and made the tool forgive me instead.

That sub(/\r$/,"") line

Every line gets a carriage return stripped off the end. Why? Because at some point one config file made a round trip through a Windows editor, came back with CRLF line endings, and every value it returned had an invisible \r glued to the end. Nothing fails quite as quietly as an API token with a carriage return in it. One sub() later, the problem can never come back. Cheap insurance.

The env-var override (the part I'm actually proud of)

Look at the top of the function, before awk ever runs:

local envkey="MINI_${section}_${key}"
envkey="$(echo "$envkey" | tr '[:lower:]-' '[:upper:]_')"
if [[ -n "${!envkey-}" ]]; then printf '%s\n' "${!envkey}"; return 0; fi

Any config value can be overridden at runtime by setting MINI_<SECTION>_<KEY> in the environment. Section and key get uppercased, dashes become underscores, and bash's indirect expansion (${!envkey}) checks whether that variable exists. If it does, that wins and the file is never touched.

This sounds like a small thing. It is not a small thing. It means I can test a notification script against my own private chat instead of the family group:

MINI_TELEGRAM_CHAT_ID=123 ./notify.sh

No editing the config file, no “temporary” change I forget to revert, no accidentally spamming everyone at 11pm because I was debugging. One-off overrides, testing, pointing a script at a staging instance: all without touching the file that thirty other scripts depend on. Twelve-factor apps get this via environment config; my crontab gets it via three lines of bash.

(The MINI_INI variable at the top is the same trick applied to the file itself: point the whole tool at a test config when you want to.)

What this fixed, philosophically

mini_conf fits a broader rule I try to hold my homelab to: simple tools I fully understand beat powerful tools I half understand. One boring config file instead of one secret per script. A helper small enough that “read the source” is the documentation.

The chaos hasn't come back. New script? Two lines: call mini_conf, use the value. Key rotation is a one-file edit. And when something breaks at 11pm, the config layer is never the suspect. It's 40 lines of bash I can hold in my head.

The best tools are the boring ones. mini_conf has been running for months and I mostly forget it exists. For infrastructure, that's the highest compliment there is.

Written with assistance from Claude.

Want to reach out? Contact me.

At work, I use Microsoft 365 Copilot. Mostly not for writing or reasoning, but for one specific thing it does better than anything else: finding stuff in the Microsoft ecosystem. Need a change number from six months ago buried in a Teams conversation? Copilot finds it. Want to know what was decided in that SharePoint document nobody can locate? Copilot finds it. For anything outside that Microsoft bubble it's unremarkable, but inside it, it's genuinely useful.

For technical work, I use Claude. Both through Claude Desktop and Claude Code running on my homelab. Writing scripts, working through infrastructure problems, reasoning about code. This is where it earns its keep. But I wouldn't ask it to do anything else.

Then there's Gemini. I use it for exactly one thing: images. Generating images for my website, or taking an existing photo and seeing what happens when you ask it to do something creative with it. Claude is not good at this. Gemini is. Simple as that.

What I've arrived at isn't a single AI that does everything: it's three tools with three distinct jobs. Copilot owns the Microsoft cloud. Claude owns the technical work. Gemini owns the pixels.

Maybe that changes as these tools evolve. But for now, this is what works.

Written with assistance from Claude.

Want to reach out? Contact me.

I am not going to argue against that. I use it myself, constantly. But I want to make the case for something that I think gets lost in the enthusiasm: you still need to understand what you're executing.

Not write it, but understand it. The difference matters more than it sounds.

A tablespace, a well-known AI, and a near-disaster

A while back I was working with an Oracle database and needed to verify whether a particular tablespace had existed at some point. I asked an AI assistant something like: “how do I check if this tablespace existed?”

The AI came back with a DROP TABLESPACE command. Its logic was: try to drop it, and if it doesn't throw an error, it was there. As a detection method, it technically works.

Except that if the tablespace does exist, you just deleted it.

If you know Oracle, you immediately see the problem. If you don't, you paste that command into your terminal and walk away with data loss and a very bad afternoon. The AI wasn't wrong, exactly. It answered the question I asked. But it answered a slightly different version of it: one where “existed” meant “still exists now, and can be destroyed as a test.” I meant existed in the past, and wanted a safe way to find out.

That is a distinction no AI will reliably catch if you don't catch it yourself.

Understanding is the new minimum

For a long time, the basic for working with databases, scripting, or systems administration was knowing the tools. You had to learn the syntax, the gotchas, the edge cases. That bar has genuinely lowered. AI handles a lot of that now.

But the new minimum is understanding. You need to be able to read what AI gives you and know, at least roughly, what it does. Not because AI is unreliable, it is often very good, but because the failure modes are hard to spot. The command that destroys your data may look identical to the one that checks for it.

The good news is that this is a much easier bar to clear. You don't need to be able to write a Python script from scratch. You need to be able to look at one and ask: does this do what I think it does? And if you're not sure, you can ask the AI to explain it. That conversation is usually excellent.

Read what you're given. Ask for an explanation if something is unclear. Never run a command you couldn't describe in plain language, even roughly.

The blast radius of misplaced trust is real. Understanding is what keeps it small.

Written with assistance from Claude.

Want to reach out? Contact me.

I was automating an Oracle 19c installation on Red Hat Enterprise Linux 9 by creating an Ansible-playbook. What followed was a small lesson in how AI tools are starting to complement each other in ways I didn't expect.

The problem: base release, wrong era

When you download Oracle 19c, you get version 19.3, the original base release. The catch: Oracle 19.3 was never certified to run on RHEL 9. Oracle 19.3 shipped before RHEL 9 existed. The installer doesn't refuse outright, but things quietly break in ways that are hard to trace from first principles.

My Ansible-playbook kept failing. I adjusted prerequisites, kernel parameters, user limits. Nothing worked. The errors were vague, the Oracle docs were circular, and the usual sysadmin intuition wasn't cutting it.

What Claude did next

After several iterations, I was using Claude to help debug the playbook. At some point, after the obvious fixes were exhausted, it made a suggestion I hadn't expected.

It recognized that the root cause was likely a certification gap between Oracle 19.3 and RHEL 9, and that Oracle Support's AI assistant has direct access to the official patch matrix. It handed me a ready-made prompt to use:

We are trying to install Oracle Database 19c (19.3 base installer) with RU 19.31 (patch 39034528) on RHEL 9 x86-64 using a silent installation (no GUI available). The silent installer consistently fails with "undefined reference to stat" in libnnzst19.a(ccme_ck_rand_load_fileS1.o) during the linking of the orion binary (make target all_no_orcl). Because the installer fails at this point, the oraInventory is never created, which means opatch apply and runInstaller -applyRU both fail as they require a registered inventory to proceed.
MOS Note 3064394.1 describes a workaround involving copying files from patch 33794281 into ORACLE_HOME/lib/stubs and clicking Retry in the GUI installer. We cannot use this workaround because we have no GUI.
We have already tried CV_ASSUME_DISTID=OL7/OL8/RHEL8/RHEL7.8, -ignoreInternalDriverError, libpthread_nonshared.a symlink, and manually creating the oraInventory XML.

Question: How do we apply the lib/stubs fix from patch 33794281 during a silent installation on RHEL 9 x86-64 with RU 19.31, so that the linking errors are resolved and the oraInventory is created successfully?

So I did. I opened Oracle Support, pasted that prompt into their AI assistant, and within seconds got a concrete answer: a specific patch number that brings 19.3 to a version certified on RHEL 9.

Patch applied, playbook fixed

I added the patch steps to the playbook and ran it again. The installation completed cleanly. What had been a multi-day friction point resolved in minutes, not because I found the answer, but because I was pointed to where it lived.

Claude didn't know the Oracle patch number. But it knew who did, and it knew how to ask the right question to get there.

The actual takeaway

This wasn't magic. It was a routing decision. Claude recognized the boundary of its own knowledge and pointed toward a system (Oracle's support AI) that has access to proprietary, continuously updated patch data. The value wasn't in the answer; it was in the referral and the framing of the question.

It's a pattern worth internalizing: AI tools aren't monolithic. Some have broad general knowledge; others have deep, domain-specific, up-to-date access. Knowing which to ask, and how, is increasingly part of the job.

In this case, one AI sent me to another. The second one had what the first one didn't. The playbook works.

Want to reach out? Contact me.

The problem with Marktplaats is that listings age. They sink to the bottom of search results over time, so if something doesn't sell quickly, you need to re-list it. That means logging in, filling out the same forms again, uploading the same photos, writing the same description. Every time.

At some point I decided that was a problem worth solving.

Phase one: a script on my laptop

The first version was a Python script I built together with Claude. It reads a simple textfile describing the listing: title, category, price, delivery options, description, photos, and handles the rest automatically. One command, done.

The textfile approach turned out to be surprisingly pleasant. Each listing lives in its own file, easy to tweak, easy to version. The script became my actual workflow: edit the file, run the script, walk away.

That worked well for a while. But running a script from a terminal still felt like more friction than necessary, especially when I just wanted to quickly re-list something that had slipped off the first page.

Phase two: moving it to the server

My homelab runs a small server. It already hosts a bunch of Docker containers: media, home automation, monitoring, that kind of stuff. So I asked Claude: what would it take to wrap this in a proper web interface, so I can manage listings from my browser?

The answer turned out to be: not that much.

We built a small web app that runs on my server. It gives me: – A proper editor for my listing files, with syntax highlighting – Photo management with drag-and-drop upload and preview thumbnails – A run button that fires off the automation and streams the output live to the browser, so I can watch it work – An overview of all listings, with the last time each one was placed, and the ability to select and run multiple at once

The whole thing sits behind my reverse proxy, accessible only from my own network. No cloud, no subscription, no third-party service involved.

What Claude actually did

Most of it, honestly. I described what I wanted, pushed back when something felt overcomplicated, and redirected when we went off course. Claude wrote the application logic, the streaming output, the Docker setup, and adapted the original script to run on Linux instead of on my Windows laptop.

What I contributed was knowing what I wanted, catching things that didn't feel right, and doing the actual testing. The kind of collaboration where you're the product manager and the AI is a very fast, very patient developer who doesn't complain about changing requirements.

The result is something I'd never have built on my own. Not because it's technically beyond me, but because I'd have talked myself out of the effort before starting. With Claude, the activation energy is low enough that “wouldn't it be nice if...” actually becomes a working thing.

The disclaimer

I'm deliberately vague about how the automation works under the hood. Platforms don't love bots, even well-behaved personal ones. This post is about the journey, not a how-to.

But the broader point stands: if you have a repetitive task that involves a website, and you've got a Claude subscription, it's probably worth asking whether it could be automated. And if it's already automated, it's probably worth asking whether it could be a proper tool.

Written with assistance from Claude.

Want to reach out? Contact me.

The problem

Claude Pro has three usage dimensions worth tracking:

• 5-hour block utilisation — the rolling window that gates your active sessions
• 7-day utilisation — the broader weekly cap
• Extra credits — the paid overflow, billed in euros

None of this is exposed in a machine-readable way by default. It turns out there is an undocumented OAuth endpoint that exposes exactly that data.

The endpoint

Claude Code stores an OAuth access token in ~/.claude/.credentials.json. The same token works against the usage API:

GET https://api.anthropic.com/api/oauth/usage
Authorization: Bearer <token>
anthropic-beta: oauth-2025-04-20

The response looks like this:

{
  "five_hour": { "utilization": 7.0, "resets_at": "..." },
  "seven_day": { "utilization": 19.0, "resets_at": "..." },
  "extra_usage": {
    "is_enabled": true,
    "monthly_limit": 1700,
    "used_credits": 190.0,
    "utilization": 11.18,
    "currency": "EUR"
  }
}

Note: monthly_limit and used_credits are in eurocents. Divide by 100 for the actual euro amounts.

The script

The script reads the token, hits the endpoint, optionally queries ccusage blocks for remaining block time, and appends a single JSON line to a log file — ready for Loki to scrape and Grafana to visualise.

#!/usr/bin/env bash
# Dependencies: jq, curl, ccusage (npm install -g ccusage)

LOGFILE="/var/log/ccusage.log"
CREDENTIALS_FILE="${HOME}/.claude/.credentials.json"
ANTHROPIC_USAGE_URL="https://api.anthropic.com/api/oauth/usage"

log() { echo "[$(date '+%d-%b-%Y %H:%M:%S')] $*" >&2; }

TOKEN=$(jq -r '.claudeAiOauth.accessToken // empty' "$CREDENTIALS_FILE" 2>/dev/null)
if [[ -z "$TOKEN" ]]; then
    log "No credentials available, aborting"
    exit 1
fi

USAGE=$(curl -s \
    -H "Authorization: Bearer $TOKEN" \
    -H "anthropic-beta: oauth-2025-04-20" \
    "$ANTHROPIC_USAGE_URL")

if ! echo "$USAGE" | jq -e '.five_hour' > /dev/null 2>&1; then
    log "Invalid API response"
    exit 1
fi

BLOK=$(echo "$USAGE"         | jq '(.five_hour.utilization   // 0) | round')
WEEK=$(echo "$USAGE"         | jq '(.seven_day.utilization   // 0) | round')
CREDITS_PCT=$(echo "$USAGE"  | jq '(.extra_usage.utilization // 0) * 100 | round / 100')
CREDITS_USED=$(echo "$USAGE" | jq '(.extra_usage.used_credits  // 0) / 100')
CREDITS_MAX=$(echo "$USAGE"  | jq '(.extra_usage.monthly_limit // 0) / 100')

REMAINING=$(ccusage blocks --json 2>/dev/null | jq '
    if (.blocks // []) | length > 0
       and (.blocks[-1].projection.remainingMinutes // null) != null
    then (.blocks[-1].projection.remainingMinutes / 60 * 10 | round / 10)
    else 0
    end' 2>/dev/null || echo 0)

printf '{"timestamp":"%s","blok_pct":%s,"week_pct":%s,"credits_pct":%s,"credits_used":%s,"credits_max":%s,"blok_remaining_hours":%s}\n' \
    "$(date -u '+%Y-%m-%dT%H:%M:%SZ')" \
    "$BLOK" "$WEEK" "$CREDITS_PCT" "$CREDITS_USED" "$CREDITS_MAX" "$REMAINING" \
    >> "$LOGFILE"

log "ccusage logged: block=${BLOK}% week=${WEEK}% credits=${CREDITS_PCT}%"

Install

Dependencies:

apt install jq curl
npm install -g ccusage

Deploy:

cp ccusage_log.sh /usr/local/sbin/ccusage_log
chmod +x /usr/local/sbin/ccusage_log

Cron — every 5 minutes:

*/5 * * * * /usr/local/sbin/ccusage_log

Output

Each run appends one line to /var/log/ccusage.log:

{"timestamp":"2026-05-23T19:26:17Z","blok_pct":7,"week_pct":19,"credits_pct":11.18,"credits_used":1.9,"credits_max":17,"blok_remaining_hours":0}

Point a Loki scrape job at that file and you have time-series data for all six metrics. Setting up Loki and Grafana for this is a topic for a separate post.

Notes

• Tested on Claude Pro with Claude Code. May work with other Claude subscriptions, but I haven't verified.
• The OAuth endpoint is undocumented and could change without notice.
• blok_remaining_hours is 0 when no active session block is running — that's expected.
• The full script with the latest version is available on GitHub: pven/scripts/claude

Written with assistance from Claude.

Want to reach out? Contact me.