DEV Community: Vuk Topalović

I made my terminal look like macOS Liquid Glass (iTerm2 + Ghostty)

Vuk Topalović — Wed, 14 Oct 2026 10:13:44 +0000

After macOS 26 came out, every part of my Mac felt like glass except the window I spend all day in: the terminal. So I built iglass, a theme and small CLI that makes iTerm2 and Ghostty look like they ship with macOS.

brew install vukkt/tap/iglass
iglass install

It's free and MIT licensed: github.com/vukkt/iglass

What you get

Four variants modeled on Apple's own options: Clear, Frosted (default), Tinted and Solid (for Reduce Transparency).
Light and dark palettes built from Apple's system colors. The terminal switches with macOS, including automatic day/night.
Eight accent colors matching the macOS accent set, used for the cursor, selection and links.
--contrast high, following Apple's guidance for Increase Contrast.
Real Liquid Glass in Ghostty on macOS 26+, with a blur fallback everywhere else.
One-command undo. iglass uninstall puts back exactly what was there before.

Clear	Frosted	Tinted	Solid

The interesting problems

A color scheme sounds like an afternoon's work. Doing it properly took longer, and these were the parts worth writing about.

1. Translucent backgrounds break contrast math

Normal contrast checks compare text against a known background color. With a translucent window, the background is whatever is behind the window: a white web page, a dark wallpaper, anything.

So the palette build checks each variant against the worst case it could be composited over. Tinted and Solid are checked over pure black and pure white. Frosted is checked over dark and light greys. Clear, the purely aesthetic variant, is checked over mid-grey, and the README says plainly that it can't be legible over everything.

The same math gives each variant a minimum safe opacity. If you pass --opacity below that value, iglass warns you and asks for --force. The full numbers are in a generated contrast report.

2. iTerm2 can't do real Liquid Glass (yet)

I wanted the real material, not an imitation. iTerm2's binary does contain glass-effect code, but there's no setting for it, and a pull request adding one was closed: glass forces auto layout and breaks window resizing.

So in iTerm2, iglass gets as close as it can with tuned transparency, blur and palettes, and the README's FAQ is upfront about that.

Ghostty is different. It has background-blur = macos-glass-regular and macos-glass-clear, which use Apple's actual material. Rather than guess from version numbers, iglass asks Ghostty's own config validator whether glass is supported and falls back to classic blur if it isn't.

3. One bad file breaks every profile

iglass installs into iTerm2 as a dynamic profile: a JSON file in a folder iTerm2 watches. Two things I learned:

A single malformed file in that folder disables all dynamic profiles, including other tools' profiles. So iglass writes to a temp file, validates it with plutil -lint, and only then moves it into place. iglass doctor also checks the other files in the folder.
Keys you leave out are inherited from your default profile. iglass only sets the keys that control the look, so your fonts, keybindings, shell and working directory stay yours.

4. You can't change iTerm2's global settings while it's running

Things like the tab theme and window padding are app-wide preferences. If you write them while iTerm2 is open, iTerm2 overwrites them with its in-memory copy when it quits.

The opt-in --app-settings flag therefore records the current values, hands off to a small detached launchd job that quits iTerm2, applies the change and reopens it. Uninstall restores those exact keys and nothing else.

5. The bug that hid from my own tests

v1.1.1 fixed a fun one. On macOS, pgrep leaves out its own ancestor processes. Run iglass from inside iTerm2, and iTerm2 is an ancestor, so iglass decided iTerm2 wasn't running and skipped the restart.

My tests didn't catch it because the fake pgrep in the test suite was more helpful than the real one. The fix is pgrep -a, and the stand-in now behaves like the real thing so the bug can't come back silently.

How it's built

Plain bash 3.2 (the version macOS ships) plus jq, so there's nothing extra to install.
Palettes live in one JSON file. A Python build step generates the iTerm2 and Ghostty themes and the contrast report, and CI fails if the generated files are stale.
117 bats tests and 19 palette tests, all run in a sandbox so they never touch real preferences. shellcheck is clean, and CI runs on macOS.
Installs via Homebrew, a curl script, or prebuilt theme files if you'd rather not run a CLI.

The iglass Dark and Light schemes were also merged into iTerm2-Color-Schemes, so they're available for the many terminals that project supports.

Try it

brew install vukkt/tap/iglass
iglass install --variant clear --accent purple
iglass preview --variant tinted
iglass uninstall   # everything back the way it was

👉 github.com/vukkt/iglass

I'd love feedback, especially screenshots of how it looks on your wallpaper, and requests for which terminal to support next (Kitty? WezTerm? Linux?). If it makes your terminal nicer, a ⭐ helps other people find it.

I built a Claude Code plugin that only keeps an "agent memory" rule if it can prove it saves tokens

Vuk Topalović — Sat, 27 Jun 2026 21:52:41 +0000

Most agent-memory setups add a rule because a model thought it sounded useful. I wanted one that has to earn its spot.

token-warden watches your Claude Code sessions, distills candidate efficiency rules from the expensive ones, then benchmarks each rule on a frozen test suite (with vs without it) and only keeps it if it saves at least 2x the tokens it costs to carry around, and breaks nothing. Everything else gets evicted. It once threw out a rule that saved 38k tokens per run because that "saving" came from the agent giving up and failing the task.

Honest result so far: on a deliberately wasteful agent, a "grep for the symbol before reading the whole file" rule cut a session from ~67k to ~56k tokens (about 16%, roughly 3 cents/session on Sonnet, ~500x what the rule itself costs). On my already-optimized agents the same rule saves basically nothing and gets auto-evicted, which is the entire point. It refuses to keep junk just to look busy.

It's measured, not vibes. Open source, MIT. I'd genuinely like people to try to break it or tell me the numbers are wrong.

https://github.com/vukkt/token-warden

Most AI agent memory never pays for itself

Vuk Topalović — Mon, 22 Jun 2026 21:12:52 +0000

Built a small tool for Claude Code that tracks whether “agent memory” rules actually pay for themselves in token usage.

The idea is simple: every persistent instruction should justify itself by reducing future token cost. If it doesn’t, it gets flagged for removal.

Over time, a surprising amount of memory ends up being neutral or negative ROI once measured. Check it out, would mean a lot :)

Repo: https://github.com/vukkt/token-warden

"make your AI better" is guesswork — token-warden only keeps changes it can prove, with real numbers on a fair repeatable test, made the work cheaper.

Vuk Topalović — Mon, 15 Jun 2026 09:57:06 +0000

token-warden is a thrifty office manager for your AI assistants. It does four things:

Keeps the receipts. Every time the AI finishes a task, it quietly notes how much that cost — like saving every taxi receipt in a drawer.
Notices waste. When a task costs far more than usual, it asks a cheap junior AI: "Why was that so expensive? What habit would've made it cheaper?" — and writes down a suggested habit, e.g. "search for the right file before opening files at random."
Tests the habit for real — this is the important part. It doesn't just trust the suggestion. It keeps a fixed set of practice tasks (like a standardized test that never changes), and runs them twice: once with the new habit, once without. Now it has hard numbers on whether the habit actually saved money, instead of a hunch.
Keeps only what pays off. A habit takes up room in the AI's memory, and that room itself costs a little every single time. So the rule is strict: a habit must save at least twice what it costs to keep, or it's thrown out. Winners get written into the AI's permanent memory so it uses them automatically forever after; losers are discarded (but remembered as "tried it, didn't work" so the same bad idea won't come back).
vukkt / token-warden

Claude Code plugin that makes coding agents measurably cheaper over time: collect token costs, distill candidate rules, benchmark them on a frozen golden suite, and keep only rules that earn their context rent.
token-warden

A Claude Code plugin that makes coding agents measurably cheaper over time.

Most "agent memory" accumulates advice nobody ever verifies. token-warden treats agent memory as an engineering problem: every rule that wants space in an agent's context must prove, on a fixed benchmark, that it saves more tokens than it costs — or it gets evicted. The result is a per-agent memory file containing only rules with measured positive return.
- Measured, not vibes — every rule carries a token delta from real benchmark runs
- Self-funding — rules must save ≥ 2× their own context rent to stay
- Self-auditing — active rules are re-benchmarked round-robin and evicted when they stop earning
- Zero session overhead — collection runs in a Stop hook that never blocks or fails your work
Table of contents
View on GitHub