See the
whole system

The CLI gives you no meter, so you discover the rate limit by hitting it in the middle of a task.

Problem

Gemini CLI reports nothing about the quota it spends. The limits are two rolling windows over weighted tokens, and the heaviest consumers are the invisible ones: the chat history replayed on every call, and the depth of the reasoning mode.

Approach

Read the same quota endpoint the CLI itself calls, then go further than it does. The endpoint returns fractions only, so token spend and context depth are read out of the CLI's own local conversation database.

Result

A desktop widget with live quota windows, token spend, context depth and a switcher across several accounts. Single file Windows build, no runtime dependencies.

The same blind spot in a different tool, plus a third party widget that kept going stale without saying so.

Problem

The widget I used would freeze: its poller stopped while the process stayed alive, so the numbers on screen quietly stopped being true. A wrong number is worse than no number.

Approach

Session and weekly limits come from the official usage endpoint, token spend from the transcripts the CLI already writes to disk. Then the interface was ported off Win32 ctypes onto X11 so the same widget runs under ChromeOS Crostini.

Result

One widget, two platforms, and a visible heartbeat so a stalled poller can never pass for fresh data.

A machine with no monitor attached has no active display, and remote desktop then connects to nothing.

Problem

Headless servers drop remote sessions to a black screen, or refuse to start one at all. The usual answer is a hardware dummy plug, which does not help when the machine is in another city.

Approach

Create a virtual display through the Windows display configuration API, then keep a watchdog on it that notices when the picture disappears and brings it straight back.

Result

Remote sessions always have a picture. Released as open source together with the parts of the CCD API that are badly documented: how modes are chosen, and how cloning between adapters really behaves.

Every downloader either wants money, wants your data, or breaks the week the video site changes something.

Problem

Direct files and YouTube need completely different handling, and anything behind a login needs the session you already have in the browser.

Approach

Two paths in one extension: direct MP4 and WebM straight from the page, and YouTube in maximum quality through a native yt-dlp host running outside the browser, with cookies carried over.

Result

A download service with a queue and playlist support. The browser kills its child processes on exit through a job object, so the host is started around that restriction through WMI.

Chrome hands you the visible viewport only, and only about twice a second.

Problem

Naive stitching ignores that limit and assumes every scroll step produced a frame. The result is a tall image with repeated or missing strips, and nothing warns you that it happened.

Approach

Scroll, capture, and stitch by the scroll offset each frame was actually taken at, paced to the browser's own rate limit so no frame is lost silently.

Result

Whole page capture with an annotation editor on top, and a PDF writer built from scratch rather than pulled in as a dependency.

AIDA64 knows every sensor in the machine, but only while it is on your screen.

Problem

Monitoring software wants to be the thing you look at. I wanted the three numbers that matter and none of the program around them.

Approach

Read the sensor values straight out of the shared memory block AIDA64 exports, so AIDA64 itself can stay minimised and hidden.

Result

CPU, GPU and SSD temperatures always visible on the desktop in a small widget, with the program that produces them out of sight.

An assistant that does things, rather than one that describes how they could be done.

Problem

A chat model becomes an operator only when it can call tools, recover from a failed call, and be trusted to run unattended. Hosted models and local models disagree about how tool calling works, which is where most of the real work sits.

Approach

Multi step execution with real tool calling and structured outputs, one dialect adapter per model family, and error handling that retries deliberately instead of guessing.

Result

Runs unattended on the home server, covered by an automated suite of over a hundred tests so a broken tool call is caught before the user sees it.

Private project, no public repository.

Fully autonomous publishing does not save time, it publishes mistakes at scale.

Problem

Automated news channels either post everything and lose credibility, or need someone watching a console. Neither is a process you can leave running.

Approach

Collection, drafting by a language model, then review and approval inside Telegram itself, on a phone, followed by scheduled publishing. Drafting and publishing run as separate bots so neither can act for the other.

Result

Nothing reaches the channel without a person pressing approve, and approving takes a few seconds rather than a session at a desk.

Private project, no public repository.

Built after failing to find an online timer that was not buried in advertising.

Problem

Every free timer site is ad choked, and none of them run two independent timers side by side, which is exactly what a kitchen, a workout or a studio session needs.

Approach

Vanilla JavaScript, no framework. Four layouts (left, right, centre and a shortcut grid), each page keeping its own saved state, deployed over FTP by a small Python script.

Result

Live and in daily use, loads instantly, and shows nothing on screen that is not the clock.

The same engine as the dual timer, rebuilt around focus cycles instead of raw countdowns.

Problem

A countdown and a focus cycle look identical and behave differently: one is a number, the other is a rhythm of work and rest that has to survive being ignored.

Approach

Bigger targets, softer motion, and nothing on screen that is not the clock. The timer engine was reused wholesale, only the interface around it was rebuilt.

Result

Shipped and used, then retired: the free host removed the account for inactivity. The code is kept and the engine still runs in the dual timer.

Demo offline, the free hosting account was removed for inactivity.

Subtitles in, a dubbed audio track out, with every line landing in its own slot.

Problem

Synthesised speech never fits the subtitle it belongs to. A line that runs half a second long pushes the whole track out of sync, and fixing that by hand is the entire job.

Approach

Each subtitle is synthesised separately and speed matched to the gap it has to fill, with two text to speech back ends behind one interface and a launcher that needs no command line.

Result

Dubbing that stays in sync for a full length video, in every language tried so far.

Private project, no public repository.

Model Context Protocol servers that give an agent real hands instead of advice.

Problem

An agent is only as useful as the tools it can actually call. Most of what I needed had no API at all, only a web interface built for a human.

Approach

One server per capability, each exposing a small set of well described tools: image generation and chat, text to speech with subtitle timed dubbing, and research notebook automation driven through a real browser session.

Result

Tools that any MCP capable agent can use, so the same capability does not have to be rebuilt for every assistant.

Some servers are public, others are private.

One engine, six themes, and a build script that stamps out a store ready extension.

Problem

Building a second new tab extension from scratch means copying the first one and then maintaining two copies of the same bug.

Approach

The behaviour lives in a single engine, everything visual lives in a themes file, and a build script assembles a complete packaged extension from the pair, with landing page and payment flow around it.

Result

A new variant is a theme entry rather than a project, and a fix in the engine reaches every variant at once.

Private project, no public repository.

A book at one end, a script a person can actually read out loud at the other.

Problem

The slow part of long form video is not research, it is turning research into thirty five minutes that sound like a person talking rather than a summary being recited.

Approach

Extraction from a research notebook in parallel passes, a structural scaffold (logline, climax, obstacles, emotional turns), then rewriting passes that break the cadence machine generated text falls into, and an automatic split into teleprompter files.

Result

Nine full length scripts produced end to end, each one ready to shoot without further editing.

Private project, no public repository.