DEV Community: Daksh Gargas

The 4% rule: picking app background colors that survive cheap phone screens

Daksh Gargas — Sun, 02 Aug 2026 20:55:42 +0000

Every design team eventually ships a beautiful off-white, off-blue, or off-anything background… and then opens the app on a $120 phone and watches it turn dirty gray. Same hex, same build. This post explains why, and gives you a small formula to convert any tint you've chosen into one that survives budget panels.

Why subtle tints die on cheap screens

Four panel-level failure modes, all common in the budget tier:

1. Weak gamut coverage. Entry-level LCDs cover only a fraction of sRGB — independent panel measurements routinely land in the 55–70% range, with large per-color error. A low-chroma tint simply doesn't have the budget to survive that compression.

2. Cold white points. sRGB assumes a D65 white (6500K). Budget modules commonly ship visibly cooler — high-6000s to 9000K+ — because blue-ish whites look "brighter" in a store. That blue cast is spread across the entire grayscale, and its magnitude is comparable to a subtle warm tint. Net result: the panel can cancel your background color outright.

3. Stretched gamuts on budget AMOLED. The opposite failure: "vivid" default modes stretch sRGB content across the panel's wider native gamut. Your quiet tint renders at roughly double saturation and suddenly has an opinion.

4. Banding. Many cheap panels are 6-bit + FRC. Soft near-white gradients develop visible steps, which makes barely-different surface colors look like rendering bugs.

The 4% rule

You don't need a colorimeter to know if you're at risk. Use channel spread — the distance between your highest and lowest RGB channel — as a chroma proxy:

spread = max(R, G, B) − min(R, G, B)

If spread is under ~10 of 255 (≈4%), your tint is inside a cheap panel's error bar. It may render as intended, as gray, or as tinted the other direction — you don't get a vote. (Quick check on any hex: two outer pairs of digits within ~0x0A of each other = you're in the danger zone.)

Why 4%? Because that's the same order of magnitude as the grayscale tint produced by a few-hundred-kelvin white-point error — the most common budget-panel defect. Your color and the panel's error are the same size, so the panel wins half the time.

Converting your color: the budget-tier formula

Don't pick a different color for cheap devices — that forks your brand. Derive the same hue at higher chroma:

Take your canvas color. Find maxC (highest channel), and each channel's distance from it: d = maxC − channel.
Pick a spread multiplier k — 2 if your spread is ≤4%, 1.2–1.5 if you're already near 5%.
Drop the ceiling a touch so cards can sit above the canvas in pure white: maxNew = maxC − 4.
Each new channel = maxNew − d × k.

Worked example — say your designer chose a cool "paper blue" #F2F5FA:

Channels 242 / 245 / 250 → spread 8 (3.1%): danger zone.
k = 2, maxNew = 246.
R = 246 − (8×2) = 230 → E6 · G = 246 − (5×2) = 236 → EC · B = 246 → F6.
Budget variant: #E6ECF6 — spread 16 (6.3%), same hue, twice the presence, and pure #FFFFFF cards now sit a clear step above it.

The same math works on warm creams, mint-greens, blush-pinks — hue never changes, only its insistence. If you prefer perceptual tooling: convert to OKLCH, multiply C by ~2, subtract ~0.01 from L, keep H — same result with cleaner math. (Avoid HSL for this: its S value is wildly misleading near white.) Either way, your background lightness barely moves, so text contrast ratios are essentially unchanged — but re-run your AA checks anyway.

Ship it as tiers, not themes

Tier 1 — color-managed panels (iPhones, flagship Androids): your original tint, near-white cards.
Tier 2 — budget panels: the converted tint, pure-white cards, hairlines nudged one step darker.

Everything else — ink, accent, type — stays identical. Users never see "a different theme"; they see the same brand, legible. Platform low-RAM/entry-device flags are a good-enough proxy for panel class to pick a default, and a small Paper tone: Auto · Soft · Rich setting covers the misfires (and the users who simply prefer one).

Test on glass, not in Figma

Emulators show you your monitor's opinion. On the real device, at full brightness and ~40%:

Does the canvas read as a color — or as a white that needs cleaning?
Can you see where a card ends without tilting the phone?
Is a canvas→white gradient smooth, no steps?
Is your content (photos especially) still the warmest, richest thing on screen?

Four yeses on your cheapest test device and you're done.

Takeaways

Subtle off-whites are a flagship luxury; under ~4% channel spread you're inside the error bar of a cheap panel.
Never fork the color — scale its chroma: maxNew − d × k, hue untouched.
Pure-white cards above a slightly stronger canvas beat shadow-only hierarchy on washed panels.
Tier by device class with a user override; test with eyes on real glass.

Sources & further reading

Panel measurement & gamut coverage

How Notebookcheck tests laptops and smartphones — the measurement methodology behind most published sRGB-coverage and DeltaE numbers; a good primer on what "coverage" and "ΔE < 3" actually mean.
Lenovo IdeaPad 330S display review — a real measured example of a budget panel at ~58% sRGB (reds render orange; subtle tints don't stand a chance).
sRGB coverage explained + NTSC conversion — why "45% NTSC" marketing ≈ 63% sRGB, typical coverage tiers by panel class, and why wide-gamut panels oversaturate sRGB content in native mode.

White points

X-Rite: which white point is correct? — D65/6500K as the reference illuminant.
Barco: what is a display's white point? — native panel hue, and sRGB's 6500K default.
PhoneArena: how we test displays — phone color temperature measured against the 6500K reference; higher = colder/bluer whites.
6500K vs 5000K in practice — includes real-world reports of uncalibrated displays landing in the low-to-mid 7000K range.

Bit depth & banding

8-bit vs 6-bit+FRC panels — why cheap panels band in soft gradients (262k native colors, dithering artifacts).

Color math & platform APIs

Björn Ottosson: Oklab/OKLCH — the perceptual color space behind the "C × 2, L − 0.01, H constant" conversion; interactive picker at oklch.com.
Android isLowRamDevice — the platform flag that best proxies device (and panel) class.

Most measurement sources above are monitor/laptop reviews — the panel physics is identical, and phone-specific measurement lives in the PhoneArena and Notebookcheck methodologies.

One Brain, Two Wallets: Two Claude Code Accounts on One Machine

Daksh Gargas — Mon, 20 Jul 2026 18:56:18 +0000

I hit my Claude Code usage limit mid-week. I have a second subscription, but switching accounts the naive way — /logout, /login, repeat — is miserable, and it turns out "switching accounts" in Claude Code silently means switching everything: skills, MCP servers, settings, hooks, memory, session history. All of it.

What I actually wanted: one brain, two wallets. Same skills, same MCP servers, same muscle memory — just a different subscription getting billed.

Here's the setup that got me there. ~20 minutes, fully reversible.

Step 1: Two config dirs, two aliases

Claude Code keeps all its state in a config directory — ~/.claude by default — and honors a CLAUDE_CONFIG_DIR env var to point elsewhere. That's the whole trick:

# ~/.zshrc
# Claude Code multi-account aliases
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude claude'
alias claude-personal='CLAUDE_CONFIG_DIR=~/.claude-personal claude'

mkdir ~/.claude-personal
source ~/.zshrc
claude-personal   # prompts OAuth login for the second account — one time

Credentials land in whichever dir is active. Bare claude still defaults to ~/.claude, so nothing about your existing workflow changes.

Gotcha #1: `.claude.json` moves when you set the env var

Claude Code's user-level config file (~/.claude.json — MCP servers, folder trust, onboarding state) lives next to ~/.claude, not inside it. But when CLAUDE_CONFIG_DIR is set, it's read from inside the config dir instead.

So claude-work — even though it points at the same ~/.claude you've always used — creates a fresh, empty ~/.claude/.claude.json and suddenly has zero MCP servers. Fix: symlink it to the master, since it's the same account:

ln -s ~/.claude.json ~/.claude/.claude.json

Now bare claude and claude-work are byte-for-byte identical.

Step 2: Share the brain

The second account starts as a blank slate. Since only billing should differ, symlink everything shareable from the main dir:

cd ~/.claude-personal
ln -s ~/.claude/skills skills
ln -s ~/.claude/CLAUDE.md CLAUDE.md
ln -s ~/.claude/settings.json settings.json        # hooks, permissions, env
ln -s ~/.claude/settings.local.json settings.local.json
ln -s ~/.claude/plugins plugins

One source of truth: add a skill or tweak a hook once, both accounts see it.

MCP servers need more care. They live in .claude.json, which also holds the account identity (oauthAccount) — so you can't symlink the whole file across accounts. Merge just the mcpServers block:

jq --slurpfile mcp <(jq '.mcpServers' ~/.claude.json) \
   '.mcpServers = $mcp[0]' ~/.claude-personal/.claude.json \
   > /tmp/merged.json && mv /tmp/merged.json ~/.claude-personal/.claude.json

Gotcha #2: `--resume` doesn't know about accounts

Session transcripts live at <config-dir>/projects/<project>/<session-id>.jsonl. Resume a personal session under the work account and Claude just says the session doesn't exist. Worse, anything that launches bare claude for you — crash-restore scripts, launchd jobs — always resumes against the default dir.

The fix is a tiny shim earlier in $PATH than the real binary. Every session ID exists in exactly one account's tree, so ownership is the routing signal:

#!/bin/bash
# ~/.local/bin/claude — routes --resume to the account that owns the session
REAL=/opt/homebrew/bin/claude   # wherever `command -v claude` pointed before

if [[ -z "$CLAUDE_CONFIG_DIR" ]]; then
  id="" prev=""
  for arg in "$@"; do
    if [[ $prev == "--resume" || $prev == "-r" ]]; then id=$arg; break; fi
    if [[ $arg == --resume=* ]]; then id=${arg#--resume=}; break; fi
    prev=$arg
  done
  if [[ -n $id ]] && compgen -G "$HOME/.claude-personal/projects/*/$id.jsonl" >/dev/null; then
    export CLAUDE_CONFIG_DIR="$HOME/.claude-personal"
  fi
fi
exec "$REAL" "$@"

Now claude --resume <id> just works, from anywhere, for either account. Explicit CLAUDE_CONFIG_DIR (your aliases) passes through untouched.

Bonus: moving a conversation between wallets

The whole reason I did this was running out of credits mid-conversation. Since a session is just a transcript file, "continue this work conversation on my personal account" is a copy + resume:

#!/bin/bash
# ~/.local/bin/claude-pickup <session-id> — continue a work session as personal
set -euo pipefail
id=${1:?usage: claude-pickup <session-id>}
src=$(ls ~/.claude/projects/*/"$id".jsonl 2>/dev/null | head -1)
[[ -n $src ]] || { echo "session $id not found" >&2; exit 1; }
proj=$(basename "$(dirname "$src")")
mkdir -p ~/.claude-personal/projects/"$proj"
cp -n "$src" ~/.claude-personal/projects/"$proj"/
CLAUDE_CONFIG_DIR=~/.claude-personal exec claude --resume "$id"

The work account keeps its copy as history; new turns land only in the personal copy. And since the shim checks the personal tree first, future bare claude --resume of that ID follows the conversation to its new wallet automatically.

What stays separate (and should)

Credentials and billing — the entire point.
Session transcripts — the shim depends on separate trees.
Folder trust — each account re-asks "do you trust this folder?" once per directory. Expected, answer once.
OAuth'd MCP servers (Linear, Notion, …) — tokens are per config dir; run /mcp once in the new account to re-auth. CLI-based MCP servers that use machine credentials work immediately.

The result

claude              # work (default, unchanged)
claude-personal     # second subscription, same brain
claude --resume X   # figures out the account itself
claude-pickup X     # mid-conversation wallet swap

Same skills, same MCP servers, same hooks, same memory. The only thing that changes is who gets the bill.

Why Redis Splits Into Exactly 16,384 Slots: A Deep Dive Into Distributed Systems Design

Daksh Gargas — Sat, 18 Jul 2026 20:22:13 +0000

If you have ever spun up a Redis Cluster, you probably ran into a strange, highly specific hardcoded number: 16,384.

No matter if you configure a tiny cluster of 3 nodes or a massive enterprise deployment of 500 nodes, the total number of Redis hash slots remains exactly the same.

Why 16,384? Why not 65,536 (2¹⁶), which is the standard boundary for almost every other distributed database, network protocol, and sharding architecture on earth?

To understand why Salvatore Sanfilippo (antirez), the creator of Redis, chose this specific number, we have to look past the surface-level documentation. We have to map out a technical journey from a single server to a decentralized mesh network, looking directly at the math, the memory structs, and the harsh realities of network physics.

Act 1: The Humble Beginning (The Single Instance)

Imagine you are building a new application. You need a fast database, so you spin up a single instance of Redis on a single cloud server.

At this stage, life is simple. To your application, Redis is a giant, super-fast dictionary in memory. You connect to that one server, and you start saving data:

[Your App]  ---->  ( Redis Server: 10.0.0.1 )
                      └── "user:101" -> { name: "Alice" }
                      └── "user:102" -> { name: "Bob" }

Every time you write a key-value pair, it lands in the exact same memory pool. When you ask for "user:101", Redis looks inside its internal memory table, grabs the value, and hands it right back.

Act 2: The Success Wall (When One Server Isn't Enough)

Your application goes viral. Suddenly, you aren't storing thousands of keys; you are storing hundreds of millions of keys.

You hit a physical wall. Your Redis server runs out of RAM. You upgrade the server to a bigger instance (Vertical Scaling), but eventually, you hit the ultimate ceiling: you cannot buy a single machine with enough RAM or CPU power to handle your traffic.

You have to Scale Horizontally. You need to split your massive dictionary across multiple independent Redis servers (Nodes).

               ┌──> [ Node 1 (10.0.0.1) ] -> Stores keys A to I
[Your App] ────┼──> [ Node 2 (10.0.0.2) ] -> Stores keys J to R
               └──> [ Node 3 (10.0.0.3) ] -> Stores keys S to Z

This is where things get messy. If you have 3 different servers, how does your app know which server holds "user:101"? If you guess wrong, you waste time jumping from server to server. We need a predictable way to evenly distribute keys across any number of servers.

Act 3: The Naive Solution (Modulo Hashing)

To solve the distribution problem with technical precision, your first instinct might be to use traditional Modulo Hashing.

When your application wants to store a key, it passes the string through a hashing algorithm to turn it into a consistent, predictable integer. Then, you use the modulo operator (%) against the total number of Redis nodes you currently own ($N$).

$$\text{Node Index} = \text{Hash}(\text{key}) \pmod N$$

If you have $N = 3$ nodes:

$\text{Hash}(\text{"user:101"}) = 125,482 \implies 125,482 \pmod 3 = 1 \longrightarrow \textbf{Node 1}$
$\text{Hash}(\text{"user:102"}) = 984,311 \implies 984,311 \pmod 3 = 2 \longrightarrow \textbf{Node 2}$

The Fatal Flaw: The Resharding Catastrophe

This math works flawlessly—until your traffic doubles again, and you need to add a 4th node ($N = 4$).

Suddenly, the denominator in your modulo operation changes from 3 to 4. Let's recalculate:

$\text{Hash}(\text{"user:101"}) = 125,482 \implies 125,482 \pmod 4 = 2 \longrightarrow \textbf{Node 2}$ (Was Node 1)
$\text{Hash}(\text{"user:102"}) = 984,311 \implies 984,311 \pmod 4 = 3 \longrightarrow \textbf{Node 3}$ (Was Node 2)

By changing $N$ from 3 to 4, up to 75% of your existing keys instantly map to the wrong node. Your application will suffer a massive cache miss storm. To fix this, you would have to take the database offline and move terabytes of data around just to align them with the new math. This is a production nightmare.

Act 4: Abstracting the Infrastructure (The Invention of Hash Slots)

Redis avoids this catastrophic remapping by decoupling your keys from the physical servers. It introduces a mathematical abstraction layer called Hash Slots.

Instead of hashing a key directly to a node, Redis hashes every key into a fixed pool of exactly 16,384 logical slots. This mapping never changes, no matter how many physical servers you add or remove.

Any Key ---> CRC16(Key) % 16384 ---> Hash Slot (0 to 16383)

The physical nodes do not own keys anymore; they own blocks of slots.

How the Fixed Pie is Sliced

Scenario A: The 4-Node Cluster

If you deploy a cluster with 4 master nodes, Redis divides the 16,384 slots evenly among them. Each node gets a massive chunk:

Node 1: Owns Slots 0 to 4,095 (4,096 slots)
Node 2: Owns Slots 4,096 to 8,191 (4,096 slots)
Node 3: Owns Slots 8,192 to 12,287 (4,096 slots)
Node 4: Owns Slots 12,288 to 16,383 (4,096 slots)

Scenario B: The 100-Node Cluster

If your application grows massively and you spin up 100 master nodes, the total number of slots is still 16,384. Redis divides the pie into much smaller pieces:

[16,384 \text{ slots} \div 100 \text{ nodes} \approx 163 \text{ slots per node}]

Node 1: Owns Slots 0 to 162
Node 2: Owns Slots 163 to 325
...
Node 100: Owns Slots 16,221 to 16,383

Now, when you add Node 101, you don't rewrite the hashing math. You simply instruct the existing 100 nodes to hand over 1 or 2 slots to the newcomer. Only the keys residing within those specific moved slots need to be transferred across the network. The remaining 99% of your cluster’s data remains completely untouched and online.

Act 5: What Exactly is inside a Hash Slot?

A common point of confusion is what a slot actually looks like under the hood. A slot does not contain your data, your text, or your values. Instead, a slot contains a list of references (pointers) to the memory locations of your keys.

Inside a single Redis node, there are two distinct layers of dictionaries (hash tables) holding everything together:

The Global Keyspace Dictionary (db->dict): This is the master dictionary for the node. The key is your actual string (like "user:101"), and the value is the actual data object stored in RAM.
The Cluster Slots Dictionary (cluster->slots): This is an array of exactly 16,384 entries managed by the node. Each active slot in this array points to a smaller, dedicated sub-dictionary tracking the keys belonging to it.

[Slot 4500] ───> Points to a list of keys: ["user:101", "user:999", "session:abc"]
                        │
                        └─► (Redis then looks up "user:101" in the master table to find the actual data)

Because you have millions of unique keys but only 16,384 slots, multiple keys are mathematically guaranteed to land in the same slot.

Exploding Slots and Hash Tags

While Redis's internal hash tables handle millions of keys per slot effortlessly, you can run into a Hot Slot bottleneck if you aren't careful. Since all keys in a slot live on one physical node, a sudden spike in traffic to keys sharing a slot can peg that single node’s CPU to 100% while the rest of your cluster sits idle.

However, you can also leverage this behavior to your advantage using Hash Tags. If you put part of a key inside curly braces { }, Redis will only hash what is inside the braces:

user:{101}:profile $\longrightarrow$ Redis only hashes "101" $\longrightarrow$ Slot 7312
user:{101}:orders $\longrightarrow$ Redis only hashes "101" $\longrightarrow$ Slot 7312

By forcing these different keys into the exact same slot, you guarantee they will live on the exact same physical node. This is the only way Redis allows you to run multi-key operations (like transactions) in a clustered environment.

Act 6: The Smart Client (Navigating the Slot Map)

How does your application actually talk to this setup without wasting time? If your application had to query a random node every time just to ask where a slot lives, your network latency would double. Redis Cluster solves this by pushing the intelligence out to the client library (like Jedis, redis-py, or ioredis).

1. The Initial Handshake

When your application boots up, the Redis client library connects to just one known node in the cluster and executes a special command: CLUSTER SLOTS. The node responds with the complete, current routing table of the cluster, which the client caches locally in your application's memory.

2. Zero-Latency Routing

When your code executes redis.get("user:101"), the client library intercepts the call locally inside your app's process:

It runs the key through the hashing math: CRC16("user:101") % 16384.
The result is Slot 4500.
It checks its local cache, sees that Slot 4500 belongs to Node A (10.0.0.1), and routes the TCP request directly to Node A. Under normal operations, your app achieves O(1) routing lookup.

3. Handling the `MOVED` Redirection

What happens if an administrator is actively moving Slot 4500 from Node A to Node B while your app is running? Your client’s local cache becomes outdated.

Your client sends the request for "user:101" to Node A. Node A looks at its internal memory and realizes it just transferred that slot to Node B. Instead of processing the command, Node A fires back a specific error:

-MOVED 4500 10.0.0.2:6379

The client library automatically catches this -MOVED error behind the scenes, updates its local memory cache to note that Slot 4500 now lives at 10.0.0.2, and transparently re-runs the request against Node B.

Act 7: The Architect's Compromise (Why 16,384?)

This brings us to our ultimate architectural riddle: If the total number of slots is a fixed pool, why choose 16,384? Why not make the fixed pool 65,536 (2¹⁶)?

The answer lies in the harsh realities of decentralized networks and the internal mechanics of the Redis Gossip Protocol.

1. The Cost of the Wire (The 2KB vs 8KB Bitmap)

Redis Cluster operates without a centralized orchestrator (like ZooKeeper). To detect dead nodes and handle failovers, every node must constantly broadcast its state to other nodes via heartbeat packets.

Inside every single heartbeat packet, a node must tell the rest of the cluster exactly which slots it currently owns out of that fixed pool. It does this using a raw binary checklist (a bitmap), where a 1 means "I own this slot" and a 0 means "I don't."

Inside the Redis source code, this state tracking looks like this:

struct clusterNode {
    char slots[CLUSTER_SLOTS/8]; // The raw configuration bitmap
    // ... other node metadata like IP, port, flags
};

Let's look at how the math changes based on the size of our fixed pool:

With a 16,384 fixed pool: Each node sends a checklist that is 16,384 bits long. This requires exactly $16,384 \div 8 \text{ bits/byte} = \mathbf{2,048\text{ bytes (2KB)}}$ of data inside the header of every single packet.
With a 65,536 fixed pool: Each node would have to send a checklist that is 65,536 bits long. The packet header size for every single heartbeat immediately boots to $65,536 \div 8 \text{ bits/byte} = \mathbf{8,192\text{ bytes (8KB)}}$.

2. The Fallacy of Compression

You might ask: “Why not just use 65,536 slots and compress the 8KB bitmap before sending it?”

In a pristine, newly launched cluster, a node's slots are perfectly contiguous (e.g., Node 1 owns slots 0 to 655). A bitmap with a solid block of 1s followed by all 0s compresses beautifully down to a few bytes.

However, in a mature production cluster that has undergone months of scaling, sharding, and node failovers, slots get heavily fragmented. Node 1 might end up owning slots 5, 22, 109, 455, 1200, and so on. Mathematically, a highly fragmented bit array behaves like random noise and cannot be compressed efficiently. The CPU overhead required to constantly compress and decompress this data on Redis's single-threaded architecture would severely bottleneck throughput, and the packet would still hit the network at close to its full 8KB size.

3. The Math of a Gossip Storm

A 6KB difference feels trivial on a single web request. But Redis nodes execute their cluster cron loop every 100 milliseconds (10 times a second) to shuffle gossip packets across the mesh.

Let's calculate the network traffic generated purely by background heartbeats in a standard cluster of 200 nodes:

Total Packets: If each of the 200 nodes sends just 1 baseline ping per 100ms, that is 10 pings per node per second. That's $200 \times 10 = 2,000$ PING packets per second sent cluster-wide. Since every PING requires a corresponding PONG response, the total volume hits 4,000 packets per second.
The 2KB Setup (16,384 slots): Including gossip metadata, a heartbeat packet sits at roughly 2.5KB. $$4,000 \text{ packets/sec} \times 2.5\text{KB} = \mathbf{\sim 10 \text{ MB/s of background noise}}$$
The 8KB Setup (65,536 slots): If we change the bitmap to 8KB, the packet size swells to roughly 8.5KB. $$4,000 \text{ packets/sec} \times 8.5\text{KB} = \mathbf{\sim 34 \text{ MB/s of background noise}}$$

In a healthy cluster, 34 MB/s is manageable. But networks are never perfectly healthy. Imagine a minor network switch blip occurs, causing packets to drop for a few seconds.

Suddenly, all 200 nodes realize they haven't heard from their peers. Their "Urgent Check" loops trigger. Instead of pinging 1 node every 100ms, every node aggressively flings forced PINGs to all 199 other nodes simultaneously to figure out who is alive.

At 2KB, the network spike hits ~40 MB/s. The infrastructure absorbs it effortlessly, nodes hear back from each other, and the cluster stabilizes.

At 8KB, the network spike violently jumps to Over 160 MB/s (1.3 Gbps) of pure background chatter. This background surge can completely saturate the network interface cards (NICs) of smaller VM instances. Because the network is saturated with heartbeat bitmaps, your actual client requests (GET and SET commands) get queued up, causing massive latency spikes. Worse, because the heartbeats themselves get dropped in the traffic jam, nodes will falsely assume their healthy peers are dead, triggering a chaotic chain-reaction of accidental master failovers.

4. The 1,000-Node Pragmatic Limit

Sanfilippo designed Redis Cluster with a strict architectural ceiling: the system is not intended to scale beyond 1,000 master nodes.

Let's look at the math at that extreme limit:

At 1,000 master nodes, a 16,384 slot pool means each node manages roughly 16 slots. This provides more than enough granularity for smooth, incremental data rebalancing.
You would only need a 65,536 slot pool if you planned to scale to 10,000+ master nodes (so each node could have at least a few slots). But at 10,000 nodes, the $O(N^2)$ Gossip protocol would completely collapse the network under a tidal wave of heartbeat packets anyway.

Conclusion

Choosing 16,384 was the ultimate engineering compromise. It provided enough slots to cleanly distribute data across a realistic maximum of 1,000 nodes, while ensuring that the mandatory, uncompressible gossip bitmaps stayed at a lightweight 2KB—protecting the cluster from killing its own network bandwidth when things go wrong.

How Meta Turns Old RAM Into Cheap RAM (and the Ideas That Make It Work)

Daksh Gargas — Fri, 10 Jul 2026 16:04:20 +0000

There's a DRAM shortage, memory is expensive, and hyperscalers own mountains of it. So when Meta retires a server, throwing away its perfectly good memory sticks is real money on fire. The problem: old sticks don't slot cleanly into new machines. Meta's fix is a small bridge chip plus a clever reuse of ideas the operating system has had for years. Three ideas do the heavy lifting — NUMA, hot/cold tiering, and CXL — and they stack together nicely.

NUMA: not all RAM is equally close

A modern server usually has more than one CPU chip on the motherboard. Each chip has its own bank of RAM wired directly to it — its local memory. The chips are also linked to each other, so CPU 0 can reach CPU 1's RAM if it needs to. It just has to hop across the link between them first, which costs time.

So access speed depends on where the memory physically sits:

CPU 0 reaching its own local RAM: fast (~80ns)
CPU 0 reaching the other chip's RAM: slower (~140ns), because the request crosses the inter-chip link

(Those numbers are ballpark and vary by hardware.) That's the "non-uniform" in NUMA — Non-Uniform Memory Access. Same request, different latency depending on distance.

Linux has long known about this and tries to help. A mechanism called AutoNUMA watches which CPU actually uses a given chunk of memory, and if a process's data ended up on the far chip, it quietly migrates that data over to the local one to cut the latency. The key pattern to hold onto: watch what gets accessed, then move it somewhere better.

Hot and cold: sort data by how often you touch it

Most workloads don't touch all their memory evenly. A small slice gets hammered constantly; the rest mostly sits idle. Call the busy stuff hot and the idle stuff cold.

Once you look at memory this way, an obvious strategy appears: keep hot data in your fast-but-small memory, and shove cold data into a slow-but-large tier. Because the slow tier only ever holds things nobody's really asking for, you rarely pay its latency penalty. This is the same idea behind CPU caches, the OS page cache, and RAM-versus-SSD — a fast small tier backed by a slow big one, with a placement policy keeping the right things in front.

CXL: a slower doorway for a lot more memory

CXL — Compute Express Link — lets memory talk to the CPU over PCIe, the same general-purpose high-speed lanes your graphics card uses, instead of the dedicated memory channels wired right next to the CPU. That extra hop makes CXL memory slower than native RAM, but far faster than an SSD or the network. And critically, it means memory no longer has to be a tightly-matched neighbor of the CPU — which is exactly why an old stick can join a new server through a bridge chip.

On its own, slower memory sounds like a downgrade. Here's where the three ideas click together.

The payoff: reuse the NUMA plumbing for tiering

CXL memory shows up to Linux as a NUMA node — just a "far" region, like the other chip's RAM. So Meta didn't need a new operating system. They took the AutoNUMA machinery that already does watch access, then migrate and pointed it at a new decision: not "which chip is closer," but "is this page hot or cold?" Hot pages stay in fast local RAM; cold pages get demoted to the slow CXL pool. Meta's version of this is called TPP — Transparent Page Placement — and it was merged into mainline Linux, so it's not a private fork.

The result: old DIMMs that would have been scrapped become a big, cheap, slower memory tier — used a bit like fast swap space — and the OS keeps its latency off the critical path by making sure only cold data lives there. Meta reports up to a 25% reduction in server count for some workloads.

A caveat worth keeping in mind: detecting "hot" isn't free. It leans on things like minor page faults and access-bit scanning, which themselves burn CPU cycles — so part of the real engineering is making the detection cheap enough that tiering doesn't eat its own savings. And the 25% figure comes from Meta's own paper, not independent benchmarks.

Snapshot your terminal state, restore it after a crash — Claude Code sessions included

Daksh Gargas — Tue, 07 Jul 2026 16:17:05 +0000

The problem

Last time I built claude-sessions: one picker to resume any Claude Code session across projects. But a machine crash takes more than Claude with it — it takes your whole terminal layout. Which tabs were open, which directory each one was in, which ones had a Claude session running.

macOS window restoration exists, but it fails this job twice:

It restores windows, not processes — your claude sessions don't come back.
It can't tell a crash from a quit — close your terminal on purpose for a fresh start, and it cheerfully brings back all the old tabs anyway.

The solution

A snapshot daemon plus an explicit restore — no auto-restore, ever.

Every 5 minutes, a launchd job walks every iTerm window and tab via AppleScript, and for each tab resolves the tty → the processes on it (ps) → the working directory (lsof -d cwd) → and whether a claude process is running there, including which session: from its --resume argument, from the transcript file it holds open, or from the newest transcript for that directory. The result is a small JSON file.

Snapshots accumulate as history — the last 100 distinct states, consecutive duplicates skipped, and an empty terminal never overwrites anything.

After a crash:

claude-sessions --restore-crash   # newest snapshot
claude-sessions --restore-pick    # or: fzf through history, pick the right one

Every tab comes back — as tabs of the window you're standing in — cd'd to its old directory, with claude --resume <session-id> rerun wherever Claude was live. Intentional quit? Just don't run it. You are the crash detector; that's the feature.

Three gotchas that cost me an evening

launchd can't read iCloud paths. If your script lives in iCloud Drive (mine syncs via ~/.claude/bin → iCloud), the timer dies with Operation not permitted — macOS TCC silently denies background jobs access to ~/Library/Mobile Documents. Point the plist at a local copy.
A single snapshot file is a footgun. After a crash you reopen a near-empty terminal, the timer fires, and your pre-crash snapshot is gone — replaced by three sad tabs. That's why history, not one file.
Don't restore the original window grouping. My first version faithfully recreated every window — including a junk window the snapshot had captured. Flattening everything into tabs of the current window is what you actually want.

Script, launchd template, and docs:

DenverLifeSciences / claude-sessions

Cross-project session picker for Claude Code CLI — fzf over all your sessions, Enter resumes each in a new tab

claude-sessions

Find and resume any Claude Code session from any project — and rebuild your whole terminal after a reboot — from one fzf picker.

What it does

Cross-project picker. claude --resume only lists sessions for the directory you run it from. claude-sessions lists every session from every project in one picker, newest first. Enter opens the highlighted session in a new iTerm tab (or tmux window) running claude --resume <id> in the right directory — and the picker stays open for the next one.
Crash recovery. A timer snapshots your full iTerm layout every 5 minutes — every window/tab, its working directory, and the Claude session running inside it After a reboot (or an unattended OS update), one command rebuilds the whole set.

Why. Recovering by hand means remembering every repo you had open, cd-ing into each, and running claude --resume there — once per session. This collapses…

View on GitHub

Every Claude Code session across all your projects, in one list — hit Enter to resume

Daksh Gargas — Mon, 06 Jul 2026 22:40:49 +0000

The problem

My Mac hard-crashed with seven Claude Code CLI sessions open, across five repos. All gone.

The built-in recovery is claude --resume, and it doesn't scale to seven:

It only lists sessions for the directory you run it from — you have to remember which repos you were even in, then cd into each one.
It takes over the shell you run it from — so you're spawning windows and retyping paths anyway.

The solution

Claude Code already stores everything you need as plain JSONL:

~/.claude/projects/<encoded-project-path>/<session-id>.jsonl

The first lines of each file carry the session id, working directory, git branch, and your opening message. That's a complete cross-project session index sitting on disk — it just needs fzf pointed at it.

So: claude-sessions, one script.

Every session from every project in one list, newest first, with a live preview of the conversation.
Enter opens the highlighted session in a new iTerm tab (or tmux window): cd <project> && claude --resume <id> — in the right directory, with Claude's own "summary or full session?" prompt appearing in the new tab. The picker stays open for the next one.
Sessions spawned by agent teams are tagged ⛭ agent-name; ctrl-a hides them.

Restoring my seven sessions: Enter, seven times. ~10 seconds.

Install

Needs fzf and python3. Tab-opening is macOS (iTerm2/Terminal); inside tmux it works on Linux too.

curl -fsSL https://raw.githubusercontent.com/DenverLifeSciences/claude-sessions/main/claude-sessions -o /usr/local/bin/claude-sessions
chmod +x /usr/local/bin/claude-sessions

Script, docs, and caveats (the storage format is undocumented — this only ever reads it):

DenverLifeSciences / claude-sessions

Cross-project session picker for Claude Code CLI — fzf over all your sessions, Enter resumes each in a new tab

claude-sessions

Find and resume any Claude Code session from any project — and rebuild your whole terminal after a reboot — from one fzf picker.

What it does

Cross-project picker. claude --resume only lists sessions for the directory you run it from. claude-sessions lists every session from every project in one picker, newest first. Enter opens the highlighted session in a new iTerm tab (or tmux window) running claude --resume <id> in the right directory — and the picker stays open for the next one.
Crash recovery. A timer snapshots your full iTerm layout every 5 minutes — every window/tab, its working directory, and the Claude session running inside it After a reboot (or an unattended OS update), one command rebuilds the whole set.

Why. Recovering by hand means remembering every repo you had open, cd-ing into each, and running claude --resume there — once per session. This collapses…

View on GitHub

Database Rate Limiting: The Missing Piece After a Circuit Breaker

Daksh Gargas — Sat, 27 Jun 2026 20:38:27 +0000

This is an extension to my previous post on Circuit Breakers.

A circuit breaker only decides:

"Should I even try calling Redis?"

When the circuit is open, your application executes the fallback.

For many systems, that fallback is the database.

Request
   │
Circuit Breaker (Open)
   │
Database

And that's where the real problem begins.

The Database Becomes the New Bottleneck

Imagine your system normally handles:

100K requests/sec
Redis serves 99K
Database serves 1K

Redis suddenly goes down.

Without any protection:

100K Requests

↓

Database 💥

Your database was never designed to handle the entire production workload.

A circuit breaker saved you from Redis timeouts—but it didn't save your database.

The Solution: A DB Rate Limiter

Instead of letting every request reach the database, the application enforces a limit.

if circuitBreaker.IsOpen() {

    if !dbRateLimiter.Allow() {
        return 503
    }

    return db.Get(key)
}

If your database can safely handle 5,000 QPS, only those 5,000 requests are allowed through.

The rest fail fast (or can be served from a local cache or stale data if available).

The goal isn't to serve every request.

The goal is to keep the database alive.

Where Does the Rate Limiter Live?

One question I had while learning this was:

"Can't the API Gateway do this?"

Not really.

The gateway only sees:

GET /users/123

It has no idea:

Is Redis down?
Is this endpoint going to Postgres?
Is it calling Elasticsearch?
Is it reading Kafka?
Does this endpoint even touch the database?

Only the service knows when it's about to hit the database.

That's why the rate limiter is typically implemented inside the application, immediately before the database call.

HTTP Handler
      │
Business Logic
      │
Circuit Breaker
      │
DB Rate Limiter   ← Here
      │
Repository
      │
Database

A Simple Implementation

At its core, it's just a token bucket.

Suppose the database can safely handle 500 QPS.

func GetUser(id string) User {

    if !redisCircuitBreaker.IsOpen() {
        return redis.Get(id)
    }

    if localCache.Has(id) {
        return localCache.Get(id)
    }

    if !dbRateLimiter.Allow() {
        return Error503()
    }

    return db.GetUser(id)
}

If there are no tokens left, the request is rejected immediately.

No waiting.

No overwhelming the database.

But What About Multiple Application Servers?

This was another question that came to mind.

Suppose you have:

10 App Servers

Each server allows:

500 QPS

Now the database receives:

10 × 500 = 5,000 QPS

Perfect.

In practice, each instance is usually allocated a portion of the database's total capacity.

Larger systems may use distributed rate limiters or adaptive concurrency limits, but the idea remains the same:

Never allow your fallback path to exceed what your database can safely handle.

Key Takeaways

A Circuit Breaker prevents wasted calls to a failing dependency.
It does not protect your database.
A DB Rate Limiter sits inside the application, just before the database call.
It intentionally rejects excess requests to keep the database healthy.
During outages, preserving the system is often more important than serving every request.

A resilient system isn't one that never fails—it's one that fails without taking everything else down.

A Circuit Breaker Alone Won't Save Your Database

Daksh Gargas — Sat, 27 Jun 2026 20:33:58 +0000

A common misconception is that a circuit breaker protects your database.

It doesn't.

It only protects your application from repeatedly calling a dependency that is already known to be unhealthy.

What happens when Redis goes down?

Without a circuit breaker:

Request
   │
Redis (500ms timeout)
   │
DB

Every request:

Waits for Redis to time out.
Wastes network calls.
Eventually hits the database anyway.

Enter the Circuit Breaker

After Redis fails repeatedly, the circuit opens.

Now requests become:

Request
   │
Circuit Breaker
   │
Fallback

Notice something?

The circuit breaker doesn't decide the fallback. It only decides:

"Should I even try Redis?"

So what is the fallback?

A production system usually follows this order:

Request
   │
Circuit Open?
   │
Yes
   │
Local Cache?
   │
Hit ─────────► Return
   │
Miss
   │
DB Rate Limiter
   │
Allowed?
   │
Yes ─────────► Database
   │
No
   │
Return 503

Why a DB Rate Limiter?

Suppose:

Normal traffic: 100K RPS
Redis serves 99K RPS
Database handles 1K RPS

If Redis crashes and every request falls back to the database:

100K RPS

↓

Database 💥

Instead, protect the database:

if circuitBreaker.IsOpen() {
    if localCache.Has(key) {
        return localCache.Get(key)
    }

    if !dbRateLimiter.Allow() {
        return 503
    }

    return db.Get(key)
}

Only a limited number of requests are allowed to reach the database. The rest fail fast, keeping the system alive.

Where is the DB Rate Limiter?

Not in the API Gateway.

The gateway only sees:

GET /users/123

It has no idea whether your service will:

Query Redis
Query Postgres
Call Elasticsearch
Read Kafka

The service itself knows when it's about to hit the database, so that's where the dependency-specific rate limiter belongs.

👉 Read: Database Rate Limiting: The Missing Piece After a Circuit Breaker

A circuit breaker and a rate limiter solve different problems.

Circuit Breaker: Stop calling a dependency that is already failing.
DB Rate Limiter: Protect the database from being overwhelmed when fallbacks occur.

In production, they almost always work together.

Why Redis Doesn't Implement "True" LRU

Daksh Gargas — Sat, 27 Jun 2026 20:15:57 +0000

One question that recently made me rethink cache eviction was:

If Redis uses LRU, why doesn't it maintain a heap (or a perfectly sorted list) of keys?

The answer comes down to optimizing the common case.

The Problem

Imagine a Redis instance with 10 million keys.

If Redis maintained a perfect LRU structure, every cache hit would need to update it:

GET user:123

↓

Update LRU ordering

↓

Return value

Even though the lookup is O(1), updating a heap would be O(log n), and maintaining a doubly-linked LRU list would still require modifying shared metadata on every single read.

For a cache serving millions of requests per second, that's expensive.

Redis's Approach: Approximate LRU

Instead of maintaining an exact ordering, Redis uses random sampling.

When memory is full and a write arrives:

Randomly sample a small number of keys (default: 5).
Find the least recently used among them.
Evict that key.

At first glance, this seems inaccurate.

What if all 5 sampled keys are hot?

It's possible—but statistically very unlikely for most real-world workloads.

The Clever Optimization: Eviction Pool

Redis goes one step further.

Instead of discarding the remaining sampled keys after each eviction, it keeps the best eviction candidates in a small eviction pool (16 entries internally).

Example:

Iteration 1
------------
Sample: A B C D E

Pool:
A B C D E

Evict A

Remaining Pool:
B C D E

Need more memory?

Iteration 2
------------
Sample:
F G H I J

Merge:
B C D E F G H I J

Keep only the best candidates

Evict the worst one

The pool gradually accumulates better eviction candidates while still sampling only a handful of random keys each iteration.

Why This Works

Redis optimizes for the common case:

Millions of GETs
Relatively few evictions

Instead of paying a maintenance cost on every read, Redis does a small amount of work only when memory is exhausted.

This is a classic systems engineering trade-off:

Accept a near-perfect approximation during rare events to keep the hot path extremely fast.

That's one of the reasons Redis continues to scale so well while delivering cache hit rates that are remarkably close to a true LRU implementation.

Bloom Filters, Explained Properly

Daksh Gargas — Wed, 24 Jun 2026 20:03:13 +0000

Most explanations throw a wall of theory at you and leave out the one thing that actually makes it click. This post fixes that.

The one question a bloom filter answers

Is this item definitely not in the set, or possibly in it?

It can tell you "no" with total certainty, but only ever says "maybe" for yes. It never gives a false negative; it can give a false positive. That asymmetry is the whole point — everything falls out of it. In exchange for the fuzziness, you get tiny memory and blazing speed.

What it's made of

Two things: a bit array (a row of light switches, all starting at 0) and a few hash functions (machines that take an item and spit out a position in the array). No stored words. No list of items. Just switches and hash functions.

How many bits does one item take?

This is the question that trips everyone up. When you add cat, how much room does it take?

Exactly k bits — and k is a number you pick in advance, not something the word decides.

A word has no natural size. You decide up front, "every item sets exactly 3 bits." That's k, the same for everything. cat sets 3 bits, dog sets 3 bits, elephant sets 3 bits. Word length is irrelevant — elephant takes no more room than cat. Which bits? That's what the hash functions decide.

Building the array

Tiny array of 10 slots, k = 3. Add cat:

hashA("cat") -> 4
hashB("cat") -> 4    <- two hashes can land on the same spot
hashC("cat") -> 1

Flip those bits on:

index:  0  1  2  3  4  5  6  7  8  9
        .  ■  .  .  ■  .  .  .  .  .
           ^cat        ^cat

cat lit only 2 distinct bits even though k = 3, because two hashes both said 4. Now add dog (hashes to 7, 1, 9):

index:  0  1  2  3  4  5  6  7  8  9
        .  ■  .  .  ■  .  .  ■  .  ■
           ^            ^  ^     ^
        cat+dog        cat dog  dog

Bit 1 was already lit by cat; dog setting it again does nothing.

The insight: you can't read the array

Here's the part that sticks. Look at that final array:

        .  ■  .  .  ■  .  .  ■  .  ■
        0  1  2  3  4  5  6  7  8  9

If I handed you this array cold, you could not tell me what's in it. You couldn't say "cat and dog are here." All you could say is "switches 1, 4, 7, 9 are on." The array keeps no record of who lit each bit. A lit bit just means somebody hashed there — it doesn't remember who, or how many.

That forgetfulness is the source of everything. It's why the filter is tiny (it's not storing your words, just their smeared fingerprints), and it's why "maybe" can never become "yes."

Querying: same hashes, then an AND

To check cat, hash it again — same outputs, 4, 4, 1 — and check whether those bits are all 1.

Are bits 4 AND 1 both 1?  -> yes -> "possibly present"

It's an AND across the item's own target bits. One 0 anywhere is an instant "definitely not" — it doesn't even check the rest.

Why "No" is certain and "Maybe" isn't

It comes from one fact: bits only ever turn on, never off.

a 0 bit -> "this slot was never touched" -> CERTAIN, nothing erases
a 1 bit -> "someone touched this slot"   -> AMBIGUOUS, the array forgot who

A 0 is proof of absence: if a position is still 0, nothing ever hashed there — so any item needing that bit was definitely never added. A 1 is only circumstantial: it could be your item, or other items that happened to share that slot. When all an item's bits are 1, you can't tell those apart, so the only honest answer is "maybe."

This is also why false negatives are impossible — a real member always finds its own bits lit, because it set them and nothing erases.

The false positive

Query wolf, never added, but it happens to hash to bits 4 and 1 — both already lit by cat:

wolf -> bits 4, 1 -> both 1 -> "maybe present"  -> WRONG

The filter isn't lying. Its real claim is "every bit wolf needs is lit" — which is true. It never promised wolf is present, only that it can't rule it out. And it genuinely can't: "wolf was added" and "cat was added and wolf collides" produce the identical pattern. The array forgot who lit those bits, remember? So it cannot distinguish them.

Why it's useful anyway

A trustworthy "no" lets you skip expensive work:

query the filter
  -> "definitely not"  -> skip the expensive lookup (the common case)
  -> "maybe"           -> do the real lookup to confirm (the rare case)

A false positive costs you one wasted lookup, never a wrong final answer — you always verify a "maybe" against the real source. Real uses: LSM-tree databases (Cassandra, RocksDB) put one in front of each on-disk table to skip reads for keys that definitely aren't there; browser safe-browsing keeps a local filter of bad URLs and only phones home on a "maybe."

The tradeoff, briefly

More bits and more hash functions lower the false-positive rate, at the cost of memory. You pick how many items you'll store and what error rate you'll tolerate; the array size and number of hash functions fall out of that (the sweet spot lands when the array is about half-full of 1s). And you can't delete from a basic bloom filter — clearing a bit might break other items sharing it.

Going deeper. The exact sizing math — deriving the false-positive rate (1 − e^(−kn/m))^k, the optimal m = −(n ln p)/(ln 2)², the optimal k = (m/n) ln 2, and why ln 2 keeps appearing — is laid out clearly in:

Wikipedia: Bloom filter — the standard reference, full derivations

Bloom Filters by Example — interactive, lets you watch the array fill

The original 1970 paper: Burton H. Bloom, Space/Time Trade-offs in Hash Coding with Allowable Errors

The one-paragraph version

A bloom filter is a bit array plus a few hash functions. Adding an item flips the k bits it hashes to; checking looks at those same bits. Any 0 means definitely-not; all 1s mean probably-yes. The key: you can't read the array — a lit bit doesn't remember who lit it, so a 0 proves absence but a 1 is only circumstantial. That one-way guarantee makes it a perfect cheap gate in front of an expensive lookup: trust the "no," verify the "maybe."

Beyond Sub-Agents: One Claude Orchestrating Another (with tmux)

Daksh Gargas — Wed, 17 Jun 2026 17:46:47 +0000

A detached tmux session can run completely independently of any visible terminal window. You can send keystrokes into it, capture everything displayed on screen, and attach a human observer at any time.

In other words, tmux lets you automate an interactive terminal session.

The Core Idea

Suppose you have a detached tmux session:

tmux new-session -d -s worker

You can send input into it:

tmux send-keys -t worker -l "echo hello"
tmux send-keys -t worker Enter

And you can read what's on screen:

tmux capture-pane -t worker -p

That's essentially it.

Write → Terminal
Read  ← Terminal

Once you can write to a terminal and read from it, the terminal becomes programmable.

Anything that runs inside a terminal can now be controlled programmatically.

One Claude Orchestrating Another

Once you realize a tmux session is programmable, an interesting possibility appears.

Instead of asking Claude to spawn a sub-agent, you can ask it to create and manage an entirely separate Claude Code session.

That worker Claude runs independently in its own terminal, while the primary Claude retains the conversation context, understands the broader objective, and remains responsible for planning and decision-making.

From your perspective, you're still talking to a single Claude.

Behind the scenes, that Claude is coordinating another fully capable Claude.

Your primary Claude can:

Create a detached tmux session
Launch a worker Claude inside it
Send prompts
Read responses
Review results
Decide what to do next

The worker Claude isn't a sub-agent.

It's a completely separate Claude Code process running in its own terminal.

Meanwhile, the primary Claude retains all of the context, planning, and decision-making.

You end up with one Claude orchestrating another.

Why Not Just Use a Sub-Agent?

Sub-agents are great for bounded tasks.

But sometimes what you really want isn't a sub-agent.

You want another fully capable Claude Code session.

The challenge is that you don't want to give up the context, planning, and decision-making already accumulated by your current Claude.

You want your existing Claude to stay in charge while delegating work to a fully capable worker.

A tmux-backed Claude worker gives you exactly that.

The primary Claude remains the orchestrator.

The worker Claude remains fully capable.

Minimal Example

# Create worker session
tmux new-session -d -s worker

# Launch Claude
tmux send-keys -t worker \
  'env -u CLAUDECODE -u CLAUDE_CODE_ENTRYPOINT -u CLAUDE_CODE_SSE_PORT claude' \
  Enter

# Send prompt
tmux send-keys -t worker -l "Review this repository"
tmux send-keys -t worker Enter

# Read output
tmux capture-pane -t worker -p -S -1000

You're not talking to Claude through an API.

You're automating a terminal exactly like a human would.

Gotcha: Claude Doesn't Launch (and Prompts Don't Submit)

There are two things that will almost certainly trip you up the first time you try this.

#1 Nested Claude Sessions Exit Immediately

If you launch Claude from inside an existing Claude Code session, the child process inherits Claude-specific environment variables and immediately exits.

The fix is to clear the inherited variables before launching the worker:

env -u CLAUDECODE \
    -u CLAUDE_CODE_ENTRYPOINT \
    -u CLAUDE_CODE_SSE_PORT \
    claude

#2 `send-keys` Doesn't Press Enter

My first attempt looked like this:

tmux send-keys -t worker -l "Review this repository"

Nothing happened.

That's because send-keys only types text into the terminal. It doesn't actually submit the prompt.

You need to explicitly send the Enter key:

tmux send-keys -t worker -l "Review this repository"
tmux send-keys -t worker Enter

Once you realize that, the interaction model becomes surprisingly simple:

send-keys -l → type text
Enter → submit prompt
capture-pane → read output

You're not talking to Claude through an API.

You're automating a terminal exactly like a human would.

Human Observability

A human can attach to the worker at any time:

tmux attach -t worker

The orchestrator and a human can now observe the exact same Claude session simultaneously.

Final Thoughts

The interesting part isn't tmux.

It's realizing that you can ask Claude to create more Claudes, assign them work, review their results, and make decisions based on the outcome.

After that, send-keys and capture-pane are just implementation details.

Gmail ate my formatting. So I built PasteClean.

Daksh Gargas — Wed, 27 May 2026 23:49:28 +0000

The problem that wouldn't leave me alone: I'd draft something in Notes or ChatGPT — clean formatting, bold headings, blockquotes — copy it, paste it into Gmail's compose window, and watch it fall apart.

White text on white background. Fonts swapped. Layouts collapsed. Gmail's renderer strips a lot of HTML, and nothing on iOS fixes it cleanly before the paste.

So I built one.

PasteClean is an iOS app that sits between your writing and Gmail's compose window:

→ Write in a rich text editor
→ Preview exactly how it'll look in Gmail (light and dark mode)
→ Copy — PasteClean sanitizes the HTML and puts Gmail-safe markup on your clipboard
→ Paste. Formatting intact.

It's live on the App Store! 🎊

DEV Community: Daksh Gargas

The 4% rule: picking app background colors that survive cheap phone screens

Why subtle tints die on cheap screens

The 4% rule

Converting your color: the budget-tier formula

Ship it as tiers, not themes

Test on glass, not in Figma

Takeaways

Sources & further reading

One Brain, Two Wallets: Two Claude Code Accounts on One Machine

Step 1: Two config dirs, two aliases

Gotcha #1: .claude.json moves when you set the env var

Step 2: Share the brain

Gotcha #2: --resume doesn't know about accounts

Bonus: moving a conversation between wallets

What stays separate (and should)

The result

Why Redis Splits Into Exactly 16,384 Slots: A Deep Dive Into Distributed Systems Design

Act 1: The Humble Beginning (The Single Instance)

Act 2: The Success Wall (When One Server Isn't Enough)

Act 3: The Naive Solution (Modulo Hashing)

The Fatal Flaw: The Resharding Catastrophe

Act 4: Abstracting the Infrastructure (The Invention of Hash Slots)

How the Fixed Pie is Sliced

Scenario A: The 4-Node Cluster

Scenario B: The 100-Node Cluster

Act 5: What Exactly is inside a Hash Slot?

Exploding Slots and Hash Tags

Act 6: The Smart Client (Navigating the Slot Map)

1. The Initial Handshake

2. Zero-Latency Routing

3. Handling the MOVED Redirection

Act 7: The Architect's Compromise (Why 16,384?)

1. The Cost of the Wire (The 2KB vs 8KB Bitmap)

2. The Fallacy of Compression

3. The Math of a Gossip Storm

4. The 1,000-Node Pragmatic Limit

Conclusion

How Meta Turns Old RAM Into Cheap RAM (and the Ideas That Make It Work)

NUMA: not all RAM is equally close

Hot and cold: sort data by how often you touch it

CXL: a slower doorway for a lot more memory

The payoff: reuse the NUMA plumbing for tiering

Snapshot your terminal state, restore it after a crash — Claude Code sessions included

The problem

The solution

Three gotchas that cost me an evening

DenverLifeSciences / claude-sessions

Cross-project session picker for Claude Code CLI — fzf over all your sessions, Enter resumes each in a new tab

claude-sessions

Every Claude Code session across all your projects, in one list — hit Enter to resume

The problem

The solution

Install

DenverLifeSciences / claude-sessions

Cross-project session picker for Claude Code CLI — fzf over all your sessions, Enter resumes each in a new tab

claude-sessions

Database Rate Limiting: The Missing Piece After a Circuit Breaker

The Database Becomes the New Bottleneck

The Solution: A DB Rate Limiter

Where Does the Rate Limiter Live?

A Simple Implementation

But What About Multiple Application Servers?

Key Takeaways

A Circuit Breaker Alone Won't Save Your Database

What happens when Redis goes down?

Enter the Circuit Breaker

So what is the fallback?

Why a DB Rate Limiter?

Where is the DB Rate Limiter?

Why Redis Doesn't Implement "True" LRU

The Problem

Redis's Approach: Approximate LRU

The Clever Optimization: Eviction Pool

Why This Works

Bloom Filters, Explained Properly

The one question a bloom filter answers

What it's made of

How many bits does one item take?

Building the array

Gotcha #1: `.claude.json` moves when you set the env var

Gotcha #2: `--resume` doesn't know about accounts

3. Handling the `MOVED` Redirection

#2 `send-keys` Doesn't Press Enter