Back in the terminal
These days, a lot of my work happens in the terminal, and I’m clearly not alone. The terminal has once again become a primary environment, in a renaissance led by coding agents, modern emulators, and an explosion of quality TUI apps.
Aesthetics and ergonomics have always mattered to me. In the terminal, those come down to nice colors and readability.
The state of terminal themes
And yet, finding themes that nail this is harder than it should be, especially when you like changing things up. I scrolled through ghostty +list-themes. Hundreds of options, most meh, the same failures with different palettes: unreadable dim blue and oversaturated red/magenta on near-black backgrounds, comment color (bright black) pushed too dim, selection backgrounds that make highlighted text unreadable. The handful that don’t fail are the usual suspects (Catppuccin, Gruvbox, Tokyo Night, Rose Pine, and the venerable Modus), and you already knew that. There’s probably one in your dotfiles right now.
There’s a subtler failure too. ANSI gives you sixteen named color slots (red, green, yellow, blue, magenta, cyan, and brights), and programs use them semantically: red for errors, yellow for warnings, green for success. A git diff paints removed lines red and added lines green. But many themes pick a “yellow” that’s closer to green, a “red” leaning orange, a “blue” drifted toward purple. The colors are pretty in isolation, but WARNING: in your logs takes a half-second to register, and a git diff becomes a salad of oranges and yellows you have to untangle before you can read. That half-second matters, and it shouldn’t be the theme’s job to insert it. Random terminal colors are also why tools started using their own color schemes in the first place; the fix isn’t more bypassing, it’s themes worth trusting. Modern emulators now derive the 256-color cube from your base 16 so the slot semantic carries past 16 colors too.
From vibes to math
Making my own theme from scratch was never on the table; I was looking for a tech solution to a design problem. “Give me lots of themes that don’t fail at readability and use the right semantic colors.” That’s the kind of thing you hand to an algorithm to generate a theme. Existing tools (pywal, base16, themer) handle extraction and templating, but they check neither per-slot contrast targets nor color fidelity (reds read as red, not muddy brown).
I wanted to put a few science points into the decisions, not just go on vibes. A bit of digging led me to Julia Evans’ Terminal colours are tricky. In the comments, someone recommended APCA, the Accessible Perceptual Contrast Algorithm. That was when it clicked.
APCA is a perceptual contrast model designed for screens. Given the sRGB-Y luminance of each color in a foreground/background pair, APCA returns a single polarity-aware Lc number (its sign distinguishes dark-on-light from light-on-dark), modeled on how the eye reads text on a display. This number can be benchmarked against APCA’s named tiers: minimum Lc thresholds for different reading contexts, e.g. Lc 90 for fluent text, Lc 30 for spot text or labels, Lc 15 for non-text discernibility. The taste judgment “is this color combo readable?” becomes a numeric check: does its Lc clear the tier the slot needs?
One note for the web crowd: the familiar WCAG 2 contrast ratio misjudges contrast on dark backgrounds and isn’t recommended for dark-mode design, which is exactly where terminal themes live.
The next question: how do you generate a “red” that’s really red, and chromatic enough to read as red, not as muddy brown? OKLCH helped here. It’s a perceptually-tuned color space where “hue” stays close to a stable angle (red sits in a known arc regardless of lightness) and “chroma” is a meaningful “how vivid” axis. Evil Martians make the case for OKLCH in palette generation. Together with APCA, the “good colors” problem starts looking like math you can put in a solver.
So I built Paletty. It’s a generator with a few sliders (background lightness, accent temperature, accent lightness, accent chroma), plus optional per-slot pins (lock a slot to a specific color) and image-seeding. Push the sliders to taste, hit a button, get a scheme that hits every slot’s contrast target. Hit again, get a different one. Save the ones you like with a shareable URL, then export to whichever emulator you use: Ghostty, Kitty, iTerm2, Alacritty, and most other modern emulators.
How generation works
What a terminal palette is
A terminal color scheme is a small set of named colors the emulator uses to render everything you see. At the core are the 16 ANSI slots: eight base colors and their bright variants. Programs emit ANSI escape codes saying which slot to use; the emulator decides which color the slot maps to. On top of those, most emulators add UI extras: background, foreground, cursor, selection foreground and selection background.
Planning for contrast
In Paletty, we think of the palette as a tree of slots rooted at background, organized by contrast requirements. Each non-root slot has a parent: the surface its color must read against. It’s either a direct leaf (its color is picked to contrast against the background) or an intermediate surface, colored against the background but then acting as a surface for its own children. Here’s the slot tree:
The concrete APCA targets per slot, Paletty’s design choice, not an external standard:
| Slot | Against | Tier |
|---|---|---|
foreground | background | Lc 90 (fluent text) |
cursor, ANSI 1–6 (normal + bright),ansi.normal.7, ansi.bright.7 | background | Lc 30 (spot text) |
selectionBackground,ansi.bright.0 (dark grey) | background | Lc 15 (non-text) |
ansi.normal.0 (black) | background | none |
selectionForeground | selectionBackground | Lc 30 (spot text) |
cursorText | cursor | Lc 30 (spot text) |
ansi.normal.0 (black) skips the contrast requirement on purpose: on a dark terminal, ANSI black is conventionally a background-tone marker, not a foreground color.
Each slot has its own color domain, the set of candidates that satisfy its semantic role, defined in OKLCH. For chromatic accents (red, green, yellow, blue, magenta, cyan), the domain is a hue arc closer to that slot’s canonical OKLCH anchor than to any other accent’s (its Voronoi cell), restricted to colors with enough chroma to clearly read as that hue, not the desaturated near-gray that could pass for any of them. Red looks reddish, green looks greenish. For monochrome slots (the black-end and white-end pairs), the domain inverts: low-chroma colors biased to the slot’s lightness end (dark for black, light for white).
This is where the answer to “why bother with OKLCH when palettes are just sRGB hex codes?” lives. sRGB hex is fine for telling a screen what to render, but useless for asking “is this red enough to be the red slot?” RGB axes encode device intent, not perception; no coordinate means “how red” or “how vivid”. OKLCH gives us three perceptually meaningful axes (lightness, chroma, hue) calibrated to how the eye reads color, so “red” lives at a stable hue angle whether the color is dark, light, dull, or vivid.
For each slot’s color domain, the planner computes the parent sRGB-Y values that would make the slot’s APCA tier unachievable: its forbidden band. To plan the background, the planner excludes from background’s own color domain any color whose sRGB-Y falls in a direct child’s forbidden band.
Picking colors
Materialization comes next. An RNG picks background from its narrowed color domain, with the background lightness control biasing the choice toward dark or light within the range. With background fixed, APCA inversion against the picked color gives every direct child an allowed sRGB-Y range. Each slot intersects that range with its own color domain and picks from the result. The two intermediate surfaces (selectionBackground, cursor) play parent in turn: once picked, each feeds the same APCA inversion to give its text child (selectionForeground, cursorText) an allowed range. Generation walks the tree depth-first.
The picking strategy varies by role.
For all slots except the bright accents, an RNG picks from the intersection of the slot’s color domain and its allowed sRGB-Y range. The chromatic accents (ANSI normals 1–6) have their domains further narrowed at query time by the accent generation controls: temperature, lightness, chroma. The black-end and white-end slots carry OKLCH lightness biases in their domains, so they land at the right extreme without any extra RNG steering.
For bright accents: no RNG. Paletty takes the dimmest color in the slot’s allowed hue range that still clears a small offset above the normal counterpart’s sRGB-Y luminance: emphasis as a consistent step up, not a random jump. Brights are always at least as bright as their normals, never darker. Otherwise bold text, which many emulators render via the bright slot, would look weaker than regular text.
Planning and picking together turn the slot tree into a concrete palette in two passes: bottom-up, the planner collects each slot’s contrast pressure on background’s domain; top-down, materialization fills in every slot. On every emitted scheme, each slot color lives inside its OKLCH-defined domain (red reads as red, black sits at the dark end), and each bright accent is at least as bright as its normal counterpart. The planner aims to clear each contrast pair’s requested APCA tier; when inputs leave no room (tight pins, controls pushed against the contrast budget), it relaxes individual slots by one tier rather than refusing to emit. A per-slot quality grade in the UI flags exactly which slots compromised and by how much, so a dim cursor has an explanation.
How it runs
Every membership test in the algorithm above runs against the same set: every color in the 24-bit sRGB space, roughly 16.7 million points. Both planning and materialization ask things like “all colors with sRGB-Y in [0.6, 0.8] and OKLCH hue in [25°, 50°]”, combinations of perceptual coordinates derived from the sRGB triple, with no index on those axes.
Without one, every query has to walk all 16.7M colors and compute their OKLCH and sRGB-Y on the fly. Individual conversions are cheap; sixteen million of them times multiple queries per palette aren’t. OKLCH → sRGB isn’t lossless either, so you can’t sample OKLCH space directly and trust the result represents a real on-screen color. Paletty runs on Cloudflare Workers, where CPU budgets are tight and the user is waiting on the result, so none of this can be done from scratch on every call.
Paletty solves it with a precomputed atlas. For every representable sRGB color, we calculate its sRGB-Y, its OKLCH coordinates, and its forbidden-background bands per APCA tier once, offline. Internally it’s structured as a static spatial index: an immutable tree with multi-axis min/max bounds on every node, ~1k rows per leaf, closer to a packed KD-tree than an R-tree (no overlap-minimization on build). A query like “rows in this hue arc with sRGB-Y in this band” prunes the search to a handful of subtree descents, and only reads rows from leaves that partially overlap the query.
The atlas isn’t bundled with the Worker code; at hundreds of megabytes, it’s far over Cloudflare’s 10 MB Worker script cap. It lives in Cloudflare KV as an immutable snapshot. Tree blobs (a few megabytes in total) are fetched once and held hot in memory for the isolate’s lifetime; row blocks (hundreds of megabytes total) stay cold in KV and are range-read only when a query hits a partial leaf. Two layers of caching keep this fast: KV reads ride on Cloudflare’s edge cache so cross-isolate fetches are warm, and each isolate keeps its own in-memory map of fetched blocks.
All told, palette generation takes tens of milliseconds on the Worker; most of that is the KV fetches at partial leaves, not the math itself.
The rest is conventional: a Svelte SPA talks to a Hono server on Cloudflare Workers that does the generation and returns a flat JSON of hex codes.
Source is closed for now; I’ll mark the repo public once the design settles.
A small thing
Color in the terminal is a small thing. It doesn’t make you faster, and nobody will praise your taste in HN comments. But you look at it for hours a day, and the difference between a scheme that fights you and one that gets out of the way is real. If you want to try it, Paletty is at paletty.dev. Generate one this week, swap it for another next week. I do it every couple of weeks myself.