DEV Community: Daksh Gargas

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

A cross-project session picker for Claude Code CLI.

Your machine crashes with seven Claude Code sessions open across five repos. claude --resume only lists sessions for the directory you run it from — so recovery means remembering every repo you were in, cd-ing into each one, and picking from a list, seven times.

claude-sessions instead lists every session from every project in one fzf picker, newest first. Hit Enter and the session opens in a new iTerm tab (or tmux window) running claude --resume <id> in the right directory — while the picker stays open for the next one.

enter   open session in a new tab (picker stays open)
ctrl-a  hide/show agent-teammate sessions (⛭)
ctrl-r  refresh the list
esc     quit

Each line shows the session's age, project directory, git branch (when not main/master), and its opening message. A preview pane shows the last few user/assistant exchanges of the…

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

A cross-project session picker for Claude Code CLI.

enter   open session in a new tab (picker stays open)
ctrl-a  hide/show agent-teammate sessions (⛭)
ctrl-r  refresh the list
esc     quit

Each line shows the session's age, project directory, git branch (when not main/master), and its opening message. A preview pane shows the last few user/assistant exchanges of the…

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.

It 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! 🎊

Google's Workspace CLI returns raw JSON. `gdocs-to-md-mcp` returns markdown. Here's why that matters.

Daksh Gargas — Tue, 12 May 2026 05:45:17 +0000

The Problem

Google recently released a Workspace CLI with MCP support — so technically, your AI assistant can read a Google Doc now. But what it gets back is raw API JSON: a 500-line nested tree of StructuralElement objects, ParagraphElement arrays, and TextRun objects with style metadata buried three levels deep.

Your LLM can parse it. But it shouldn't have to.

Why Markdown Matters for LLMs

Think about what markdown gives an LLM that raw JSON doesn't:

# Heading tells it "this is a new section" — no need to infer structure from nested objects
`bold*`* signals emphasis — in JSON, that's a textStyle.bold: true property buried inside a TextRun object
| tables | stay readable inline — in JSON, that's a matrix of TableCell arrays inside TableRow arrays inside a Table object
- lists just work — in JSON, you're parsing bullet.nestingLevel and listProperties.nestingLevels[n].glyphType

An LLM can read markdown the way a human reads a document. JSON forces it to reconstruct the document from parts.

And the research backs this up. An arXiv study found up to 40% performance variance in LLM output depending on whether the input was plain text, Markdown, JSON, or YAML. A benchmark testing 11 table formats showed Markdown-KV hitting 60.7% accuracy — 16 points ahead of CSV and JSON alternatives. Markdown is also 10-15% more token-efficient than JSON for the same content, which adds up fast at scale.

Even the vendors agree: Anthropic recommends XML tags with markdown/plain text for document input. OpenAI recommends markdown formatting for code-related tasks. Google Gemini recommends markdown headings for structuring prompts.

The Solution

gdocs-to-md-mcp — a local MCP server that fetches Google Docs and converts them to clean markdown. Headings, bold, italic, tables, lists, links — all preserved.

One command to set up:

npx gdocs-to-md-mcp setup

The interactive wizard walks you through everything — GCP project selection, OAuth credentials, API enablement, Google sign-in — with clickable links that take you to the exact right page. No hunting through Cloud Console. It even auto-configures Claude Code when it's done.

How It Looks

Once set up, just paste a Google Docs URL:

"Read this doc and summarize the key decisions: https://docs.google.com/document/d/1abc.../edit"

Claude calls read_google_doc, gets clean structured markdown, and actually understands the document — sections, emphasis, tables, all of it. Compare that to the raw \n\n-delimited text blob from the default Google Drive integration. Night and day.

Three tools, nothing more:

read_google_doc — URL or doc ID in, markdown out
search_google_docs — find docs by keyword
list_recent_docs — see what's been updated recently

No 80-tool mega-server. No Gmail. No Calendar. Just Google Docs to markdown, done right.

Install globally with npm install -g gdocs-to-md-mcp or just run it directly with npx — your call.

GitHub: github.com/D4G4/gdocs-to-md-mcp
npm: npmjs.com/package/gdocs-to-md-mcp

[Update]: Simon Willison recently wrote about the unreasonable effectiveness of HTML for LLMs, which might make you wonder — should this tool output HTML instead?

The key distinction: Simon's argument is about LLM output — when you ask an LLM to explain something back to you, HTML is richer (SVGs, interactive widgets, navigation). That's a presentation win.

Our tool solves the opposite direction — feeding content into the LLM. For input comprehension, the research still favors markdown: 40% better performance, 15% fewer tokens, and all three major vendors recommend it for document input.

tl;dr: Markdown for what goes in. HTML for what comes out. Different problems, different formats.

Sources: Why Markdown > JSON for LLM Document Comprehension

Does Prompt Formatting Have Any Impact on LLM Performance? — Up to 40% performance variance across formats
MDEval: Evaluating Markdown Awareness in LLMs — 20K-instance benchmark on LLM markdown comprehension
Which Table Format Do LLMs Understand Best? — Markdown-KV at 60.7% accuracy, 16 points ahead of CSV/JSON
Markdown is 15% more token efficient than JSON — Real-world token comparison on identical content
LLMs are bad at returning code in JSON — All tested models performed significantly worse with JSON
Anthropic — Claude Prompting Best Practices — Recommends XML + markdown/plain text for document input
OpenAI — Prompt Engineering Guide — Recommends markdown formatting for code tasks
Google Gemini — Prompt Design Strategies — Recommends markdown headings for structuring prompts

I Built a Smarter 20-20-20 App Because Every Other One Annoyed Me

Daksh Gargas — Sun, 10 May 2026 21:09:46 +0000

The 20-20-20 rule is a simple habit recommended by optometrists to reduce eye strain:

Every 20 minutes, look at something 20 feet away for 20 seconds.

The problem is that most 20-20-20 apps are so annoying that I end up disabling them within a week.

They interrupt you mid-thought.

They popup during meetings.

They remind you even if you just stepped away from your desk.

So I built Blink.

Instead of blindly firing timers, Blink tries to understand context:

🧠 in flow? it waits for a natural pause
🚶 away from your desk? timer resets automatically
🎙️ in a meeting? timer pauses
🤖 waiting for AI output? timer keeps running

The goal was simple:

build a break reminder smart enough that you forget it's running until the exact moment you need it.

Blink needs Accessibility permissions to work — which is a pretty big trust ask.

That’s why it’s fully open source.

You can see exactly what it does:

reads input timing, never content
no analytics
no telemetry
no network calls

Everything happens locally, and every line of code is public.

Once we squash the remaining bugs, I’ll push it to the App Store.

If you try it out, I’d love feedback.

And if this sounds interesting to you, contributions are very welcome.

Download now :D

https://blink20.net

GitHub

https://github.com/D4G4/blink

Save those $$ GitHub Actions Minutes: How We Built a Commit-Driven CI System for iOS

Daksh Gargas — Thu, 23 Apr 2026 17:34:47 +0000

If you're building an iOS app with GitHub Actions, you're probably burning through macOS runner minutes like they're free.

Spoiler: they're not — macOS runners cost 10x more than Linux runners, and a 25-minute test run that fires on every push adds up fast.

We run a Swift/SwiftUI app with 3000+ tests across BLE integration, calibration logic, snapshot testing, and more. Here's how we went from "run everything on every push" to an opt-in, routable, self-hosted-friendly CI.

TL;DR — you can get the speed of self-hosted runners without the usual operational overhead, and in a way that's completely developer-independent:

No shared build box to maintain,
no daemons running on anyone's laptop,
no hardcoded machine names in CI configs.

Every developer's Mac is self-aware: it reads its own identity from the runner config on disk, auto-starts in single-job mode only when a commit explicitly asks for it, and shuts down the moment the job finishes. One line in a commit message routes the build to the right machine — and the same workflow works unchanged whether you're running on GitHub's cloud or on someone's M-series laptop.

The rest of this post walks through how we got there: a commit-driven CI system where the commit message controls exactly what runs, where it runs, and whether it runs at all.

The Problem

Our test suite takes ~25 minutes on GitHub-hosted macOS runners — and that's not even running all the tests, just a subset. Most of that time is build time; the actual tests finish in seconds. But every push triggered that same partial suite, even for a one-line copy change.

We were spending hundreds of dollars a month on CI that mostly told us "yes, the code you didn't touch still works."

The Solution: `[ci: ...]` Commit Directives

We put CI control directly in the commit message body. One line, declarative, readable in git log:

feat(theme): update color palette

[ci: tags=theme exclude=snapshot]

That's it. This commit runs only the theme-tagged tests and skips snapshot tests. Total CI time: ~3 minutes instead of 25.

The Full Directive Syntax

[ci: tags=<t1,t2> exclude=<t1,t2> runner=<name> final record-snapshots]

Every key is optional:

Key	What it does
`tags=theme,calibration`	Run only these Swift Testing tags
`exclude=snapshot`	Skip these tags
`final`	Run the full test suite (pre-merge gate)
`runner=<name>`	Route to a self-hosted runner (dynamically resolved — see below)
`record-snapshots`	Re-record snapshot reference images

No directive = no CI run. Normal development commits don't burn any minutes.

How the Parsing Works

Both our workflows (targeted-tests.yml for scoped runs, regular-tests.yml for full suite) share a parse-directive job that runs on a cheap ubuntu-latest runner. It:

Checks out the repo (needs git history)
Reads the latest non-merge commit message
Extracts the [ci: ...] block with a simple grep/sed pipeline
Outputs structured values (tags, exclude, runner-name, etc.) for downstream jobs

# Parse [ci: ...] block from commit message
CI_BLOCK=$(echo "$MSG" | grep -oE '\[ci:[^]]+\]' | head -1)
TAGS=$(echo "$CI_BLOCK" | grep -oE 'tags=[^ ]+' | sed 's/tags=//')
RUNNER=$(echo "$CI_BLOCK" | grep -oE 'runner=[^ ]+' | sed 's/runner=//')

The expensive macOS jobs only start if the parse job says so. If there's no directive, the workflow exits cleanly with a green check — no wasted minutes, no red X.

Tag-Based Test Scoping with Swift Testing

Swift Testing's @Test(.tags(...)) system makes this possible. Every test is tagged by feature area:

@Test(.tags(.calibration))
func calibrationConvergesWithinTolerance() { ... }

@Test(.tags(.bluetoothManager))
func connectDisconnectCycle() { ... }

Our test runner script translates comma-separated tags into xcodebuild flags:

# tags=calibration,homePage becomes:
xcodebuild test \
  -only-testing-tags calibration \
  -only-testing-tags homePage

This means a developer working on calibration only runs calibration tests. A theme change only runs theme tests. The feedback loop goes from 25 minutes to under 3.

Self-Hosted Runners: Your Machine, Your Speed ⚡

GitHub-hosted macOS runners are decent machines, but your M-series MacBook Pro is probably faster — especially since it already has a warm DerivedData cache and resolved SPM packages.

We added a runner=<name> directive that routes the CI job to a specific self-hosted runner:

fix(ble): stabilize BLE tests

[ci: tags=bluetoothManager,bptManager runner=daksh-personal]

But how does a developer — or a Claude Code agent composing a commit — know what name to use? They don't hardcode it. We wrote a tiny helper script:

$ scripts/ci/runner-name.sh
daksh-personal

It reads the name from the runner's own config file (more on that below). So a commit looks like this:

git commit -m "fix(ble): stabilize tests

[ci: tags=bluetoothManager runner=$(scripts/ci/runner-name.sh)]"

The shell substitutes the real name at commit time. No one memorizes anything, and AI agents use the same script.

How It Works

Each developer registers their Mac as a GitHub Actions self-hosted runner, picking any name they want (daksh-personal, janes-studio, build-mac-01 — whatever) and adding that name as a runner label
When you run ./config.sh, the GitHub Actions runner writes a .runner JSON file to the runner directory. This is a standard part of the runner infrastructure — we didn't create it. It looks like this:

   {
     "agentId": 22,
     "agentName": "daksh-personal",
     "poolId": 1,
     "poolName": "Default",
     "serverUrl": "https://pipelines...",
     "gitHubUrl": "https://github.com/your-org/your-repo",
     "workFolder": "_work"
   }

The agentName field is whatever you typed at the "Enter the name of the runner" prompt. Both runner-name.sh and the post-push hook read it dynamically — nothing is hardcoded in CI configs or documentation:

   # runner-name.sh — prints the local runner name
   python3 -c "
     import json
     config = open('actions-runner/.runner', 'rb').read().decode('utf-8-sig')
     print(json.loads(config)['agentName'])
   "

You set the name once during setup and never think about it again. Each machine knows its own identity.

The workflow uses a dynamic runs-on — if the commit says runner=daksh-personal, the job lands on exactly that machine:

   runs-on: ${{ inputs.runner-name != '' && inputs.runner-name || 'macos-26' }}

On self-hosted runners, we skip setup-xcode and cache steps (unnecessary — everything's already there)
A post-push hook automatically starts the runner in single-job mode (./run.sh --once)

The runner picks up one job, runs it, and exits. No permanently running service. No wasted resources when you're not using it.

The Auto-Start Hook — This Is Where It Gets Magical

Here's the part that feels like cheating.

A self-hosted runner is useless if you have to remember to start it. "Let me open a terminal, cd into the runner directory, run ./run.sh --once, wait for the job, then Ctrl-C" — nobody's doing that twenty times a day. The whole value proposition collapses the moment it requires manual effort.

So we made it disappear. A Claude Code hook (checked into .claude/settings.json) fires automatically after every git push:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "if": "Bash(git push*)",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/ci/start-self-hosted-runner.sh"
          }
        ]
      }
    ]
  }
}

The script does three things, in order:

Reads the last commit message and extracts the runner=<name> field from the [ci: ...] block.
Reads the local runner name from actions-runner/.runner — a JSON config file written once during ./config.sh setup — and checks if it matches the directive. If this machine isn't the target (or there's no directive at all), it exits silently. No noise, no side effects. Every developer's machine is self-aware: the script doesn't need to know who you are, it reads the identity from the runner config that already exists on disk.
If this machine is the target, it launches the runner in background, single-job mode: ./run.sh --once &. The runner registers with GitHub, picks up exactly one job, executes it, and exits.

That's the entire interaction. You write a commit message with runner=<your-runner-name>, you push, and by the time you've switched back to your editor, your laptop is already building. The feedback loop for BLE tests went from ~25 minutes (cloud runner cold start + build + test) to ~30 seconds (warm cache, already-resolved SPM packages, M-series silicon). A 50x speedup, triggered by a line in a commit message.

And because it's --once, there's no daemon, no background service, no "did I remember to stop the runner?" It's entirely demand-driven: it exists only while your job needs it.

The hook is the glue that makes the rest of the system feel invisible. Without it, self-hosted runners are a clever-but-annoying option. With it, they're the default path for anything hardware-adjacent — and you stop thinking about CI altogether. You just commit, push, and the right machine runs the right tests.

The Build-Once, Test-Many Pattern

For the full test suite ([ci: final]), we don't want to build the project three times. Our regular-tests.yml workflow:

Build job: Compiles once, packages DerivedData as an artifact
Logic tests job: Downloads the artifact, runs xcodebuild test-without-building
Snapshot tests job: Same artifact, runs only snapshot-tagged tests

Jobs 2 and 3 run in parallel. Total wall time is build + max(logic, snapshots) instead of build * 3.

Why Self-Hosted Runners Are Even Faster: Warm DerivedData

On GitHub-hosted runners, every job starts clean — no DerivedData, no resolved SPM packages. The build job has to compile everything from scratch every time. On a self-hosted runner, DerivedData persists in $HOME/DerivedData/CI between CI runs. That means:

SPM packages stay resolved. No re-downloading, no re-linking. The -skipPackageUpdates flag in quick mode skips the resolution step entirely.
Incremental builds. If you changed one file, xcodebuild recompiles that file — not the entire project.
Build-graph validation, not recompilation. Test jobs run build-for-testing before test-without-building to validate that the build products are still valid. This takes 65–90 seconds — not zero, but far less than a cold build.

We measured this over 5 consecutive CI runs on the same self-hosted runner:

Run	Build job	Notes
1 (cold-ish)	3m 1s	First run after the DerivedData path fix
2	1m 6s	Warm cache — SPM resolved, most objects cached
3	1m 44s	Small code change, incremental recompile
4	1m 44s	Same pattern
5	1m 39s	Consistent ~1.5 min steady state

The first run pays the cold tax. Every subsequent run benefits from the warm cache. On GitHub-hosted runners, every run is Run 1.

The Safety Net: When We Still Run Everything

To be clear — we're not skipping tests, we're scheduling them. The full suite is still the source of truth, and it absolutely runs at the moments that matter:

Before a PR merges. A [ci: final] commit (or the equivalent on the merge commit) runs the entire suite as the pre-merge gate. Nothing lands on main without it.
On a regular cadence for long-lived branches, so drift doesn't pile up silently.
Always before an App Store submission. Shipping to users is the one place where "fast feedback" loses to "zero surprises" — the full suite runs, snapshots and all, no exceptions.

The point of commit directives isn't to avoid testing. It's to find the middle ground between rapid iteration and stability: don't pay the 25-minute tax on a typo fix, do pay it when the blast radius justifies it. CI is still the source of truth — we're just choosing when to consult it.

Results

Metric	Before	After
Average CI time per push	25 min	0-3 min
Monthly macOS runner minutes	~2,000	~300
Time to BLE test feedback	25 min (cloud)	~30s (self-hosted)
Commits that trigger CI	100%	~15%
Build job (self-hosted, warm)	n/a	~1.5 min
Build job (cloud, cold)	~3 min	~3 min
Full suite wall time (self-hosted)	n/a	~13 min

The key insight: most commits don't need CI at all. When they do, they rarely need all the tests. And when you need fast feedback on hardware-adjacent code (BLE, sensors), your own machine is 50x faster than waiting for a cloud runner to boot, build, and test.

The second insight: DerivedData persistence is the real speedup on self-hosted. The build-once-test-many pattern saves one redundant build, but the warm DerivedData cache across CI runs saves the SPM resolution and cold compilation that dominates cloud runner time. A self-hosted build job consistently finishes in ~1.5 minutes versus ~3 minutes on a cold cloud runner — and that gap widens as your dependency graph grows.

Getting Started

You don't need our exact setup. The pattern is:

Tag your tests by feature area (Swift Testing, pytest markers, Jest tags — whatever your framework supports)
Parse the commit message in a cheap Linux job before spinning up expensive runners
Default to not running — opt-in is cheaper than opt-out
Let devs use their own machines for fast iteration via self-hosted runners in single-job mode — read the runner identity from the local config so nothing is hardcoded per-developer

The commit message is the interface. It's visible in git log, reviewable in PRs, and doesn't require any dashboard or config file changes. Just write your message and push.

What You Need After Cloning the Repo

The CI directives ([ci: tags=...], [ci: final]) work out of the box — they're parsed by GitHub Actions workflows already in the repo. But if you want to use runner=<name> to run tests on your own machine, here's the one-time setup:

Self-hosted runner setup (one-time, ~5 min)

1. Install the GitHub Actions runner

cd /path/to/your-project/..   # parent of the repo
mkdir actions-runner && cd actions-runner

# Go to repo Settings → Actions → Runners → "New self-hosted runner"
# Select macOS / ARM64, then follow the download + extract instructions:
curl -o actions-runner-osx-arm64-X.Y.Z.tar.gz -L <URL_FROM_GITHUB>
tar xzf ./actions-runner-osx-arm64-X.Y.Z.tar.gz

2. Configure the runner

./config.sh --url https://github.com/your-org/your-repo --token <TOKEN_FROM_SETTINGS_PAGE>
# Pick any name you want (e.g. "daksh-personal", "janes-studio")
# This name gets written to .runner and is what you'll use in commit messages

3. Add your runner name as a label

This is the step you'll miss the first time. GitHub's runs-on matches labels, not runner names — and ./config.sh only assigns generic labels (self-hosted, macOS, ARM64). You need to add your runner name as a custom label:

cd /path/to/your-repo
RUNNER_NAME=$(scripts/ci/runner-name.sh)
RUNNER_ID=$(gh api repos/your-org/your-repo/actions/runners \
  --jq ".runners[] | select(.name==\"$RUNNER_NAME\") | .id")
gh api -X POST repos/your-org/your-repo/actions/runners/$RUNNER_ID/labels \
  --input - <<< "{\"labels\":[\"$RUNNER_NAME\"]}"

4. That's it

Everything else is already in the repo:

.claude/settings.json — a post-push hook that auto-starts the runner when your commit includes runner=<your-name>
scripts/ci/runner-name.sh — reads your runner name from the local config so you never hardcode it
scripts/ci/start-self-hosted-runner.sh — matches the commit directive against the local runner and starts it in single-job mode

Your first self-hosted CI run:

git commit -m "fix(ble): stabilize

[ci: tags=bluetoothManager runner=$(scripts/ci/runner-name.sh)]"
git push
# Hook fires → runner starts → picks up the job → exits when done

No daemon, no background service, no config files to edit. Clone, configure once, push.

What's Your Take?

This is the setup that worked for us — a small team, an iOS app, a specific test suite. But I'm genuinely curious how other teams are solving the same problem. What tradeoffs did you make that we didn't? What's broken about this approach that I'm not seeing?

Some things I'd love POV on:

Path-based triggers vs commit directives — we picked commits because they're explicit and reviewable, but paths: filters are simpler. When has one clearly beaten the other for you?
Self-hosted runners at scale — we have a handful of developer Macs. Does this pattern hold up with 20+ engineers, or does it fall apart on coordination?
The "no CI by default" call — is this reckless on a larger team, or is the pre-merge gate enough of a safety net?
Something we haven't even considered — Bazel remote cache? Merge queues? Monorepo-style affected-test detection? Tell me what we're missing.

Let's improve this together so anyone reading it later walks away with the best possible playbook — not just ours.

We're building a health-tech companion app at Denver Life Sciences. If you have questions about this setup or want to see the workflow files, drop a comment below.

DEV Community: Daksh Gargas

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

The insight: you can't read the array

Querying: same hashes, then an AND

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

The false positive

Why it's useful anyway

The tradeoff, briefly

The one-paragraph version

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

The Core Idea

One Claude Orchestrating Another

Why Not Just Use a Sub-Agent?

Minimal Example

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

#1 Nested Claude Sessions Exit Immediately

#2 send-keys Doesn't Press Enter

Human Observability

Final Thoughts

Gmail ate my formatting. So I built PasteClean.

Google's Workspace CLI returns raw JSON. `gdocs-to-md-mcp` returns markdown. Here's why that matters.

The Problem

Why Markdown Matters for LLMs

The Solution

How It Looks

Sources: Why Markdown > JSON for LLM Document Comprehension

I Built a Smarter 20-20-20 App Because Every Other One Annoyed Me

Download now :D

GitHub

Save those $$ GitHub Actions Minutes: How We Built a Commit-Driven CI System for iOS

The Problem

The Solution: [ci: ...] Commit Directives

The Full Directive Syntax

How the Parsing Works

Tag-Based Test Scoping with Swift Testing

Self-Hosted Runners: Your Machine, Your Speed ⚡

How It Works

The Auto-Start Hook — This Is Where It Gets Magical

The Build-Once, Test-Many Pattern

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

The Solution: `[ci: ...]` Commit Directives