
I run [zpl.tools](https://zpl.tools), a ZPL-to-PDF rendering API written in Rust, on Fly.io. While benchmarking it I found a step in the latency curve between 40 and 45 pages that had nothing to do with the renderer.

## The symptom

<FlyProxyCliffChart />

40 pages take ~0.6 s, 45 pages take ~3.5 s, with no measured processing-time difference on the server side. That pointed me towards fly.io.

The step lands at ~10 MB of request body, and my benchmark labels cross that line between 40 and 45 pages.

## The cause

After searching Fly's forums I found [a mention of similar behaviour](https://community.fly.io/t/replay-with-file-stream/19611/11). It confirmed that `fly-proxy`'s HTTP handler buffers the first 10 MB of a request body so it can retry or `fly-replay` it. Once that buffer fills it stops reading from the client until the app answers, or a hardcoded 3 s timeout fires.

That exactly explains what I observed. A render cannot answer before it has the whole label, so there is no early response for the proxy to see, and every request over 10 MB paid the full 3 s.

Then I wrote [a post on Fly's community forum](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460), where Fly confirmed the behaviour and pointed me in the next direction for the mitigation.

## Nothing releases the pause

The workaround suggested in that earlier thread is that the pause ends when the proxy gets a response from the instance. An interim response looked ideal: it wouldn't force me to commit a status code before parsing the body. So I tested the entire 1xx space: 100, 102, 103, 199. `fly-proxy` keeps waiting through all of them: an interim response doesn't release the buffer.

Fly [suggested to us](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460/4) [HTTP trailers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Trailer), and they would work. It means we would have to commit to a response code before processing the full request. A label can fail to render, exceed a quota, or turn out malformed, and none of that is visible before processing the full request.

API clients expect a standard status code, so I'd have needed a Cloudflare Worker in front to read the trailer and reconstruct the real response. It would have worked, but it is a lot of moving parts to keep a workaround invisible, and I decided against it.

## What the buffer buys

Two `http_service` features need that buffer.

`retry`: covers Fly's own routing rather than your app failing. The proxy can route to an intermediary host that has just died and that it hasn't learned about yet. With the body buffered it sends the request somewhere healthy and the client never notices. Without the body it can't.

`fly-replay` allows you to read a request (up to 10MB in size), then hand it to a different machine or region.

## Why I stopped fighting it

The `retry` is a genuinely good property, and at enough traffic you would hit that window regularly. I have not hit that scale. And a render is idempotent (there's no state to corrupt by doing it twice), so a failed request is safe to send again. I would rather the client retry, or retry under my own policy, than delay every large request.

I never used `fly-replay`.

So the trade is a fixed 3 s on every request over 10 MB, against a rare failure I can absorb and a routing feature I do not need.

## Leaving the HTTP handler

I decided to use a [raw TLS service](https://fly.io/docs/networking/services/). Fly terminates TLS and pipes the TCP connection to the app. Skipping the whole fly.io http processing.

The TTFB dropped instantly. 45 pages went 3.51 s → 538 ms.

<FlyProxyRawTlsChart />

## Autoscaling

The original autoscaling was based on the request count. Dropping to raw TLS makes it possible to scale only by TCP connection count. So I tried that. Behind Cloudflare it is not viable.

Cloudflare doesn't close an origin connection after a response. Its [connection limits documentation](https://developers.cloudflare.com/fundamentals/reference/connection-limits/) puts the Proxy Idle Timeout at 900 s (15 minutes) and states that it "reuses open TCP connections up to the `Proxy Idle Timeout` limit after the last HTTP request", and lists it as not configurable.

Based on my observation, each Cloudflare edge machine holds its own connection pool. So the count `fly-proxy` sees tracks Cloudflare's edge fan-out and idle timers, not how much work is in flight.

Under sustained load the autoscaling either scales too far, or hits the hard limit, which reaches clients as 520s on a quarter of all requests in my benchmark, while the machine sat nearly idle.

Responding with `Connection: close` could help. But it also costs a fresh TLS handshake on essentially every request, plus a cold congestion window on every large upload. That is a tax on exactly the requests I had just made fast.

I measured the handshake on its own, on a body small enough to have no upload ramp to hide it: about 100 requests each, pooled against closed.

<FlyProxyHandshakeChart />

22 ms, and on a large upload the cold congestion window is charged on top of it.

<FlyProxyLargeBodyChart />

No setting makes socket count mean "work in progress." To get that signal back, something has to count dispatched requests.

## Why not just drop Cloudflare

We started using Cloudflare primarily for better visibility into customer latency.
We add a timestamp to the request at the edge, which lets us measure the latency the end user actually observes.
Fly has a header carrying one too, but it isn't in the [documented request headers](https://fly.io/docs/networking/request-headers/), and it is not documented where in the pipeline it gets applied.

So Cloudflare stays and connection counting stays broken. The scaling decision has to move somewhere that understands the workload.

## So I run Pingora

After another [response](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460/6) from the Fly.io team, who confirmed that calling the Machines API yourself costs the same as the built-in autostart, because `fly-proxy` does that internally, I decided to add my own proxy.

The app is now split into two process groups: a **proxy** and a **worker**.

The proxy, built on [Pingora](https://github.com/cloudflare/pingora), terminates the public surface and owns auth and the billing gate. Making the workers stateless rendering nodes. Previously the app was a single monolithic container, and every copy of it carried auth and billing along with the renderer.
This lets us independently scale the worker nodes.

<FlyProxyTopology />

The connection problem went away with it. An always-on proxy is the thing Cloudflare pools its sockets against, and those sockets are no longer anybody's scaling signal: the proxy counts dispatched requests and starts workers on that. The same hour-long benchmark that had failed a quarter of its requests now runs at a zero error rate.

And because the proxy is now the thing holding the public surface, keep-alive came back. Measured from the same Hetzner client across the hosted benchmark suite, against the `Connection: close` build:

| comparison | median ratio | median delta |
| ---------- | ------------ | ------------ |
| vs the `Connection: close` run | 0.828 | −22 ms |
| vs the original keep-alive run | 1.028 | +2 ms |

The −22 ms is almost exactly the per-request handshake I had been paying. Removing `Connection: close` gave back what it cost.

## The final numbers

<FlyProxyApproachesChart />

We managed to cut the request time from ~3.5 s down to ~0.52 s, and streamline the app scaling at the same time.

---

## Suspend, don't stop

The proxy **suspends idle workers rather than stopping them.** A stopped machine has to boot; a suspended one restores a memory snapshot. Across the measured cold requests, a stopped machine processed the request in ~1.51 s and a suspended one in ~0.59 s, 61% faster. A warm worker answers in ~150 ms. The snapshot's storage cost is negligible.

<FlyProxySuspendChart />

## The new bottleneck

The split moved a ceiling rather than removing it. Every request now goes through one proxy machine, and a Fly machine gets 1 Gbit of internal network. That gigabit used to belong to a single renderer; it is now shared by the whole cluster sitting behind the proxy.

At 10 MB a label it takes a lot of concurrent uploads to saturate, and I have not come close. But it is a real limit, and it is the kind you only meet under load.

The fix is the lever the split already bought me: run more than one proxy. It is a small machine, 1 shared CPU and 512 MB, so a second one is cheap, and it brings another gigabit with it.

## Measurement methodology

Three runs in August 2026: the cliff on the 9th, the raw TLS service on the 10th, and the proxy split on the 12th. k6 drove the API one request at a time from a Hetzner cpx12 in FSN1 against Fly machines in Frankfurt. Before the split the API was a single machine on 2 dedicated CPUs and 2 GB of RAM; it is now a proxy on 1 shared CPU with 512 MB and renderers on dedicated compute. Each point is the median of 10 requests, 5 on the heaviest, and the renderer itself is unchanged throughout: the only thing that moves is the network path in front of it.

## Next steps

Next I want to look at machine types for the workers. Shared CPUs are a lot cheaper than dedicated ones, but a sustained render workload runs over its CPU share and gets throttled for it, so I have stayed on dedicated. The proxy is in a position to change that. It already sees the size of every request, so it can predict roughly what a render will cost and track what each shared machine has left, instead of handing work to one that has already burned its budget.


Two weeks ago Claude and I worked out why our staging deploys were flaky. Today it's happening again, and the answer is sitting in some session transcript on my disk. Which one? No idea. I remember a phrase from the conversation, not a session title.

Claude Code's own picker doesn't help here. `claude --resume` lists recent sessions for the current project, by title. If the title doesn't ring a bell, you're done. The transcripts themselves are JSONL files under `~/.claude/projects/`, so the fallback is grepping JSON-encoded lines by hand and copy-pasting session ids into `--resume`. I did that maybe three times before deciding it was a tooling problem.

## The palette

I run my agents inside [herdr](https://herdr.dev) (the terminal-native agent multiplexer from [the previous post](/blog/claude-code-herdr-status-plugin)), so I built the fix as a herdr plugin: [herdr-agent-palette](https://github.com/ondratuma/herdr-agent-palette). Press a key, type what you remember, land where it was said. It fuzzy-searches your live panes and their scrollback too, but the section that fixed this particular pain is **sessions**: every Claude Code session on disk, searched by full transcript content. Not titles. Content.

![The palette searching "staging deploy flaky" across sessions: a list of sessions on the left, each led by how long since it last moved and an open/closed marker, and a transcript preview on the right with the matched words highlighted.](/blog/claude-code-herdr-agent-palette.png)

Each row leads with how long since the session last moved and whether it's still open (`●`) or already closed (`○`); the preview shows the conversation with the query highlighted. `Enter` jumps to an open session's pane, and resumes a closed one in a fresh workspace, cwd set to where it ran. So: type `staging deploy flaky`, hit `Enter`, and ask the two-week-old session "that deploy fix, apply it here too".

That last part is what changed how I use it. Old sessions stopped being an archive I dig through and became something I casually jump back into.

It's a self-contained curses TUI, Python standard library only, with a clean-room [fzy](https://github.com/jhawthorn/fzy)-style matcher that folds diacritics (`Matejcek` matches `Matějček`, which matters more than you'd think in a Czech codebase). Install is one command; the keybinding and the resume-command override (useful if you [run multiple accounts](/blog/claude-code-multiple-accounts)) are in the [README](https://github.com/ondratuma/herdr-agent-palette#install).

The transcripts were on disk all along. All they were missing was a search box.



I run several Claude Code agents at once. [herdr](https://herdr.dev) makes that painless. It's a terminal-native agent multiplexer, like tmux but it knows which panes are running agents and lists them in a sidebar. Spinning up five of them is easy. The hard part is knowing which one needs me right now.

They all sit in the sidebar churning, so I'd tab through them one by one looking for the pane that had been stuck on a question for ten minutes while I babysat a different one. The supervising got more expensive than the work.

## What herdr already shows

herdr detects an agent's status on its own and puts it in the sidebar: `working`, `idle`, `blocked`, `done`. Useful, but coarse for triage:

- `blocked` doesn't say whether the agent is waiting on CI or waiting on **me**.
- `idle` and `done` look about the same when you're scanning fast.
- None of it tells you *how long*. The pane that's needed you for eight minutes looks identical to the one that stopped five seconds ago.

So when I glance at the sidebar, two questions go unanswered: what is this pane actually doing, and how long has it been doing it.

## What the plugin adds

An icon and a live timer per agent pane. The icon disambiguates the stopped states; the timer counts how long the pane has held the current one.

| icon | meaning |
|------|---------|
| ⚡ | working |
| 🔁 | looping (running `/loop`) |
| ⏳ | waiting on something automated: CI, a build, a deploy |
| ✋ | stopped, needs me: a question, a decision, an approval |
| ✅ | done, nothing left |
| 💤 | idle at its prompt box |
| 💀 | stale: hasn't moved in over a day |

![herdr sidebar listing seven agent panes, each with a status icon and a live timer: 🔁 7m release watch running /loop watch-ci, ⚡ 12m auth refactor wiring the token middleware, ✋ 18m schema migration waiting on approval, ⏳ 21m e2e suite waiting on CI, ✅ 26m changelog done, 💤 32m scratch idle, and 💀 30h old spike stale.](/blog/claude-code-herdr-status-sidebar.png)

So a pane reads `✋ 8m`: it's wanted me for eight minutes. I scan the sidebar, find the oldest ✋, and go there. **Triage instead of polling.**

## How it knows: the agent reports itself

herdr can tell that a pane stopped. It can't tell *why* it stopped — but the agent knows why. So the interesting half of this is just a convention I gave Claude, dropped into my global `CLAUDE.md` so every session picks it up:

```markdown
## herdr session status

Call the `herdr-status` helper as your activity changes, to tell the user
what you're doing — above all when you need something from them:

- `herdr-status input`   — ✋ you need me before you can continue
- `herdr-status done`    — ✅ finished, nothing left
- `herdr-status waiting` — ⏳ blocked on something automated (CI, a build)
- `herdr-status looping` — 🔁 working in a loop
- `herdr-status working` — ⚡ back to plain progress

End every turn with `done` or `input` — never leave me guessing which.
```

That last line does most of the work. End on `input` and the pane shows ✋ the instant it stops; end on `done` and it shows ✅. The sidebar always tells me whether a stopped pane is blocked on me or genuinely finished, without my opening it.

The states release on their own. `waiting`, `input`, and `done` clear the moment the agent starts working again, while `working` and `looping` stick until it stops. A pane that says ⏳ flips back to ⚡ by itself once CI comes back and Claude resumes.

## How it knows: a daemon fills the gaps

The self-reports cover intent — *why* a pane stopped. herdr already tracks the coarse state of every pane on its own, idle included (sitting at the prompt), so the plugin never has to scrape output to notice an idle pane; it just renders 💤 for the state herdr already reports. What's left is the time. A small background daemon covers the gaps between events: every tick it advances the timer and drops panes that have gone away.

herdr exposes the plumbing for both halves. A plugin hook fires on the lifecycle transitions (`pane.agent_detected`, `pane.agent_status_changed`) and pushes an update the instant a pane changes state; the daemon polls `herdr pane list` on a timer for everything that isn't an event — no socket subscription, no output scraping. The display rides in two herdr metadata slots: the icon and timer share one as a single `⚡ 6m` string (herdr swaps the icon per detected state), and the self-reported detail goes in the other, so a pane can read `⚡ 6m fixing the parser`. The plugin and daemon write to a shared state file so they never disagree about a pane.

I won't paste the whole thing; it's a few hundred lines of bash and Python. But that's the shape of it, and none of it is exotic.

## A small bonus: renaming panes

herdr labels a pane by its repo or folder by default. When three panes live in the same repo doing different things, that label is useless. One more helper fixes it:

```bash
herdr-status-rename "auth refactor"
```

I wired that into `CLAUDE.md` too, so an agent renames its own pane when its task changes. The sidebar stops being three identical repo names and starts telling me who's doing what.

## The result

The agents got cheap to run in parallel long before they got easy to supervise. This closes the gap. The sidebar went from a list of panes I opened one by one into a board I read at a glance, and the only pane I open now is the one with the oldest ✋.



Not many people seem to know this, so here it is: **the 5-hour usage window in Claude Code doesn't run on a fixed clock.** The counter starts on your *first* prompt, and resets exactly 5 hours later, no matter how much (or how little) you did in between.

## Why you should care

Each window comes with a usage cap. Burn through it in one heavy block and you get the "You've hit your session limit" message mid-flow. Since the window starts on your first prompt, **you control when that cap refills** — and that's the whole trick.

**Start the window early, before you're working.** Ask Claude "what's the weather today?" at 8:00 — from your phone, on the commute — and your resets fall at:

```
08:00  (first prompt)
13:00  reset
18:00  reset
```

Start your heavy work at 10:00 and you'll burn through the morning budget around lunch, just as the 13:00 reset refills it. Without priming, that same 10:00 start wouldn't reset until 15:00. You'd hit the wall at 13:00 and sit idle for two hours. Firing one throwaway prompt at 08:00 buys those two hours back.

You don't even have to be awake for it. Drop a tiny cron job on that first prompt:

```bash
# weekdays at 7:55; the content doesn't matter, it just starts the clock
55 7 * * 1-5  /usr/local/bin/claude -p "hi" >/dev/null 2>&1
```

## The catch

This only shifts your **5-hour** windows around. The separate **weekly** limit resets at a fixed time Anthropic assigns to your account (with its own timing for Opus), and priming a session early does nothing to that ceiling. So this is about *timing*, not *more usage*: you can line your refills up with your heavy blocks, but you can't conjure extra tokens out of thin air.

Small trick, but I reach for it every morning.



On my team we run a weekly support rotation. Whoever's on duty spends a chunk of every day triaging new issues in the error tracker and clearing support tickets off the task board, with one eye on a Slack channel for anything that's started misbehaving.

None of it is hard. It's just *tedious* — the kind of thing you half-do at 4pm on a Thursday. Different tools, different mental models, and the real work doesn't start until everything's collected: is this new, or is it an old issue suddenly spiking?

So I handed the collecting to Claude Code.

## One command, one digest

The shape that worked is not "one giant prompt." It's **one orchestrator skill** that knows the daily routine, delegating to **small specialist skills** that each do exactly one thing.

The orchestrator is dumb on purpose. It says, in effect:

1. Pull unresolved issues assigned to my team from the error tracker (last 14 days), and flag anything new or spiking.
2. List support tickets created since the last check, grouped by status.
3. Read the alerts channel since yesterday, one line per alert, each ending in a concrete next action.
4. Stitch the lot into one dated digest, newest and loudest first.

Each step points at a specialist that owns the messy details: a ticket reader, an order-debugger, and so on. The orchestrator just sequences them and formats the result. When I say *"do the support check"*, it runs the whole routine top-to-bottom and hands me one digest instead of a fan of browser tabs.

## Why split it into many small skills

The temptation is to cram everything into one mega-skill. Don't. The split pays off because:

- A small skill is easy to trust. One that only reads a ticket and renders it as clean markdown is easy to get right, and the same [ticket-reader](/blog/claude-code-script-vs-mcp-tokens) feeds both the daily support check and a monthly "group these tickets and find patterns" pass. Write it once, call it everywhere.
- The orchestrator reads like a checklist. Anyone on the team can open it and see what "support duty" means this week. It's documentation that happens to execute.

This is the bit worth stealing even if you never touch support tickets: **an orchestrator skill that fans out to single-purpose specialist skills.** It's the same instinct as small functions and one job per module, just pointed at your daily ops.

## Checking the runbooks

We keep L1 support runbooks in Notion: the documented first response for the failures that keep coming back. So the orchestrator points one more specialist at them. Once everything's gathered, it reads the runbooks and, for each issue, checks whether one already covers it.

When something matches, the digest links the runbook and quotes the first step it prescribes. Most of what lands on support duty isn't novel; it's the same known failures wearing fresh timestamps, and the playbook for each already exists. Surfacing the match turns "what even is this?" into "we have a page for that," which matters most for whoever's new to the rotation.

## What I did *not* automate

The agent gathers and drafts, matching runbooks included. It does **not** get to decide. A runbook match is a suggestion, not a green light. It tags each issue (act on it, or let it ride) and drafts a "today's focus" shortlist, but a human still makes the call on what's a real bug versus expected noise. The win is that I show up to the judgment part with everything already collected and deduplicated.

Automate the gathering. Keep the judgment. That line is where this stays useful instead of dangerous.



I lean on [a pile of small skills](/blog/claude-code-automating-support-duty) to run my day, and a lot of them touch our task board (Asana). The obvious way to do that is the Asana MCP server, and it's genuinely good. But the moment I started leaning on it for real work (sprint planning, retros, backlog refinement, any analysis that chews through a whole board), a single session pulls *hundreds* of tasks through it. At that volume it started to feel *heavy*. So I measured it, and replaced the hot path with a ~200-line script.

## Where an MCP costs you tokens

Two places, and they're easy to miss:

1. **The tool schemas.** An MCP server registers *every* tool it offers, and each tool's JSON schema sits in the context window. The Asana server alone exposes dozens of tools. That's a fixed tax you pay on every request just to have it available.
2. **The response shape.** When you fetch a task, the API hands back raw JSON: a `gid` and a `resource_type` on every nested object, *all* custom fields (not just the ones that are set), `html_text` duplicating the plain `text` on every comment, and a lot of structural punctuation. You asked for a task; you got a wall of JSON.

For a path I call constantly ("read this ticket in full"), both of those add up fast.

## The replacement

A small script that calls the Asana REST API directly and prints **clean markdown**: title, status, assignee, the custom fields that actually have a value, the description, comments, and an activity timeline. Nothing else.

It's a custom Python CLI wrapped in a skill, and that's the whole trick. The nice part is *where the cost goes*:

- The script's **code never enters the context window**: it runs as a subprocess; only its stdout comes back.
- The skill that documents it is a few hundred tokens, loaded on demand.
- The output is compact markdown instead of a verbose JSON tool-result.

## The measurement

I ran this on a real, content-heavy ticket with 25 custom fields and 45 stories (comments + activity), and compared the two ways of pulling **the same data**:

- **Script path:** ran the reader → captured the rendered markdown.
- **MCP path:** the Asana MCP wraps the same REST API, so I reproduced exactly what `get_task` + `get_stories` dump into context. This is the *conservative* case: I used minified JSON and plain-text comments (not the `html_text` the MCP also carries), so a real MCP dump would be at least this big.

Bytes are exact; token counts are estimates using Claude-tokenizer ratios (prose ≈3.9 chars/token, punctuation-dense JSON ≈3.3).

|                            |  bytes | ~tokens |
| -------------------------- | -----: | ------: |
| asana skill (markdown)     |  7,853 |  ~2,000 |
| MCP `get_task` (JSON)      | 29,035 |  ~8,800 |
| MCP `get_stories` (JSON)   | 14,250 |  ~4,300 |
| **MCP total**              | 43,285 | ~13,100 |

That's **~82% smaller by bytes, ~85% by tokens (roughly 5.5-6.5×), or about 11,000 tokens saved on a single task read.**

## Why the gap is so large

The surprise: the dominant cost isn't the *data*, it's JSON's metadata overhead.

- **Custom fields were 27 KB of the 29 KB task object: ~93% of it.** Every one of the 25 fields ships its full definition: each enum field carries *all* of its options (one field alone returned 23 of them) plus `type`, `gid`, and metadata, when the only thing that matters is the one selected `display_value`. The skill collapses each field to a single line: `**Priority:** High`.
- **JSON repeats `gid` / `resource_type` / `resource_subtype` on every nested object**, and the default task object hauls along `followers`, `hearts`, `likes`, `num_likes`, and friends. The skill drops all of it.
- **The skill discards disabled/empty fields entirely** and renders HTML → markdown instead of carrying raw markup.

So most of what the MCP spends your context budget on is scaffolding you were going to throw away anyway.

This is a heavy ticket, though: lots of fields, lots of comments. The ~6× ratio holds up because the per-field bloat is roughly constant, but a sparse task won't save nearly as much in absolute terms. The heavier your tickets, the more you save.

## The same test across 300 tasks

One ticket proves nothing, so I ran the same measurement against a random sample of 300 tasks from that board (2,615 in total, seeded so it reproduces), bucketed by *data shape*: *chatty* = 25+ stories, *field-rich* = 7+ fields set.

<TokensPerTaskChart />

Estimated tokens, averaged per task:

| data shape                | n   | skill (md) | `get_task` | `get_stories` | MCP total | saved | factor |
| ------------------------- | --: | ---------: | ---------: | ------------: | --------: | ----: | -----: |
| Light                     |  57 |        970 |      9,330 |         1,640 |    10,970 |   91% |  11.3× |
| Field-rich                |  29 |      1,330 |      9,530 |         1,820 |    11,350 |   88% |   8.5× |
| Chatty                    |  37 |      2,180 |      9,940 |         4,290 |    14,220 |   85% |   6.5× |
| Field-rich **and** chatty | 177 |      2,770 |     13,320 |         5,080 |    18,400 |   85% |   6.7× |
| **All 300**               | 300 |      2,210 |     11,780 |         4,020 |    15,790 |   86% |   7.1× |

Exact bytes, same buckets:

| data shape                | n   | skill (md) | `get_task` | `get_stories` | MCP total | saved | factor |
| ------------------------- | --: | ---------: | ---------: | ------------: | --------: | ----: | -----: |
| Light                     |  57 |      3,789 |     30,793 |         5,422 |    36,215 |   90% |   9.6× |
| Field-rich                |  29 |      5,184 |     31,431 |         6,019 |    37,450 |   86% |   7.2× |
| Chatty                    |  37 |      8,510 |     32,789 |        14,142 |    46,932 |   82% |   5.5× |
| Field-rich **and** chatty | 177 |     10,783 |     43,950 |        16,771 |    60,721 |   82% |   5.6× |
| **All 300**               | 300 |      8,633 |     38,864 |        13,251 |    52,115 |   83% |   6.0× |

The shape of it:

- **`get_task` barely moves: ~9,000-13,000 tokens whether the ticket is fat or empty.** The lightest task in the whole sample still dumped a 25 KB object. It's the custom-field schema again: the API hands back all ~25 of the board's fields with their full option lists no matter what the ticket actually uses. The script keeps the ones with a value. That win shows up on *every single read*.
- **`get_stories` is the part that scales** (2.5 KB on a quiet ticket, 64 KB on the loudest) because every comment drags a `gid`, a `resource_type`, and a full author object behind it. The script folds the same conversation into a fraction of that.
- **The median task has 34 stories and 9 set fields**, which lands most of the board in the "field-rich and chatty" row. So the number I actually live with is ~6.7× / 85%, not the 11× the light tickets flash. Light tickets save the biggest *fraction* (the schema floor dwarfs their content); heavy tickets save the most *raw tokens*: 15,000+ each.

Add it up across all 300 reads: **~4.7M tokens through the MCP, ~660K through the script. About 4 million tokens saved, 86%.** On a board I'm reading all day, that's the difference between a session that fits in the window and one that falls over.

## When the MCP is still the right call

This is not "MCPs are bad." The MCP is the better tool for **discovery and breadth**: *find the project named X*, *search tasks matching Y*, *who is this user*. Those are calls where you can't predict the shape ahead of time and would never want to hand-roll a script for each one. I still use it for exactly that.

The rule I landed on: **MCP for exploration, a script for the hot path.** The moment a single call becomes something I do many times a day with a known shape, a script I control wins on three things at once: tokens, output shape, and determinism. Best of both: let the MCP discover, let the script fetch.



If you have a personal Claude account and a work one, logging out and back in every time you switch context gets old fast. The good news: you don't have to. Claude Code reads its config — including who you're logged in as — from whatever directory `CLAUDE_CONFIG_DIR` points at. Give each account its own directory and they stop fighting over the same login.

A few aliases is all it takes:

```bash
alias claude-personal="CLAUDE_CONFIG_DIR=$HOME/.claude-personal claude"
alias claude-work="CLAUDE_CONFIG_DIR=$HOME/.claude-work claude"
alias claude="echo 'Use claude-personal, claude-work'"
```

The first two run Claude against separate config directories, so each keeps its own login. The third one is the trick that makes it stick: it overrides the bare `claude` command to nag you, so you never *accidentally* fire up an ambiguous session and wonder which account you're burning.

## Why this is better than logging in and out

The directories are fully independent, which means you can run **both at the same time** — `claude-work` in one terminal, `claude-personal` in another — without them stepping on each other. Two sessions, two accounts, side by side.

That also means two separate sets of usage limits. Which pairs nicely with [lining up your session windows](/blog/claude-code-session-windows): if you prime each account's window deliberately, you've got two independent 5-hour clocks to play with instead of one.

Drop the aliases in your `.zshrc` (or `.bashrc`), open a new shell, and you're done.



Expose a public API to your customers and a new question lands on you: what are they actually doing with it, and what are they getting back? Sentry will flag when your own code throws, but it stays quiet on the rest. It won't tell you a customer has spent all week getting 400s from one endpoint, and it can't hand you the exact request behind the ticket they just opened.

So log every request they make, not just the ones that crash.

**A request log answers the questions Sentry can't:**

- Which endpoints a customer leans on, how hard, and how that shifts after you ship a change.
- A run of 400s on one endpoint is usually a confusing API, not a bug, and you only catch it by counting.
- When someone opens a ticket, you can pull the exact request they sent and what you sent back.
- After you fix a bug, the log is your list of which customers to email once it's out.

The approach is two Symfony kernel listeners writing to your own tables: one on every request, one on every exception.

## Why two listeners

They hook two different kernel events because they do two different jobs.

The first listens on `kernel.request`. It runs on every request, before your controller, and captures the context while it's all still in front of you: method, path, the user, the headers and body. It's also where you mint an id for the request and stash it, so anything downstream can point back at this exact row.

The second listens on `kernel.exception`, which Symfony only fires when something throws. Its job is the failure: record the status and the exception, link it back to the request that caused it, and hand the user something to quote at support.

Splitting them keeps each one honest. One always runs and only describes the request. The other runs only on failure and only describes the error. Cramming both into one listener means branching on "did anything break?" on every single request, which is exactly what the kernel events already tell you for free.

## This sits next to Sentry, not instead of it

Sentry is still your debugger. It gets the stack trace, the breadcrumbs, the local variables, everything you need to work out why a request blew up. The exception listener replaces none of that. It runs alongside Sentry's own listener and writes one analytical row.

That division is the whole point. Sentry answers "what broke and where". The request log answers "how often, to whom, and on which endpoint": the questions you ask with a `GROUP BY`, not a stack trace. Keep capturing to Sentry exactly as you do now; this adds the layer Sentry was never meant to give you.

## The listeners

Storage and shape are both your call. Persist a row however your app already does it: a Doctrine entity, a raw DBAL insert, whatever you already reach for. And capture whatever you'll actually want to query later. For a request that's usually a uuid, the method and path, the caller, the headers and body, and a timestamp; for an exception, the status code, the exception class, the message, and the uuid of the request behind it. Drop what you don't need, add what you do.

The request listener:

```php
#[AsEventListener(event: RequestEvent::class)]
final class RequestLogListener
{
    public function __invoke(RequestEvent $event): void
    {
        // kernel.request also fires for sub-requests: internal forwards, ESI
        // fragments, the error-page render. Guarding for the main request keeps
        // you to one row per real client call instead of every internal hop.
        if (!$event->isMainRequest()) {
            return;
        }

        $request = $event->getRequest();

        // Mint the id up front and stash it on the request, so the exception
        // listener can point its row back at this one.
        $uuid = Uuid::v7()->toRfc4122();
        $request->attributes->set('_request_log_uuid', $uuid);

        // Strip auth headers before they ever reach the table. A request log is
        // the easiest place to accidentally persist a token in plaintext.
        $headers = $this->redactSecrets($request->headers->all());

        $this->requestLog->store($uuid, $request, $headers);
    }
}
```

The exception listener:

```php
#[AsEventListener(event: ExceptionEvent::class)]
final class ExceptionLogListener
{
    public function __invoke(ExceptionEvent $event): void
    {
        if (!$event->isMainRequest()) {
            return; // same reasoning: only the top-level failure
        }

        $request = $event->getRequest();
        $exception = $event->getThrowable();

        // The uuid the request listener left behind, so the two rows join up.
        $uuid = $request->attributes->get('_request_log_uuid');
        $this->exceptionLog->store($uuid, $exception);

        // Hand the user a reference, but only on a 5xx. A 4xx already carries a
        // meaningful body you don't want to overwrite.
        if ($this->isServerError($exception)) {
            $event->setResponse(new JsonResponse([
                'message' => 'Internal server error',
                'identifier' => $uuid,
            ], 500));
        }
    }
}
```

That identifier is what the user gets back when something fails:

```json
{
  "message": "Internal server error",
  "identifier": "0190f8c2-7b1e-7c4a-9f0c-2a1b3c4d5e6f"
}
```

It's the way back to the full request when they open a ticket about it.

## What you can ask now

The payoff is in the join. Error rate per endpoint over the last week:

```sql
SELECT r.path,
       COUNT(*)    AS requests,
       COUNT(e.id) AS errors
FROM request_log r
LEFT JOIN exception_log e ON e.request_uuid = r.uuid
WHERE r.created_at > NOW() - INTERVAL 7 DAY
GROUP BY r.path
ORDER BY errors DESC;
```

Swap the `WHERE` for `e.exception_type = '...'` and you have the list of `user_id`s to mail once the fix is out.

This only logs what actually throws. If parts of your API return error codes without raising an exception, move the status capture into a response listener instead. Same idea, different hook.

## Keep the write off the hot path

The simplest `store()` is a direct insert, and for plenty of apps that's the right call. The cost is that you've put a database write in front of every request: if the log table is slow or the DB is down, you've tied that to requests that had nothing to do with it. A few ways to cut the coupling, in rough order of effort:

- Move the write to `kernel.terminate`. Symfony fires that event after the response is already flushed to the client, so even a plain insert stops counting against the user's latency. Cheapest win, no new infrastructure; you still pay for the write, you just don't make anyone wait for it.
- Push to a queue, say RabbitMQ through Symfony Messenger. The listener dispatches a small message and returns; a worker drains the queue and writes. A slow or dead log store now buffers messages instead of failing live requests, and traffic spikes smooth out across the workers. The price is a broker and worker processes to run and watch.
- Skip the table and write to your log stream. Emit a structured line through Monolog and let your existing pipeline (Loki, ELK, Datadog) ingest it. Nothing touches your application database, and the request only writes to stdout. You trade the SQL join for whatever query language your log tooling speaks.

Start with the direct insert. Move it to `kernel.terminate` the moment it shows up in your latency, and reach for the queue only when you actually need the decoupling. Building the RabbitMQ path first is usually solving a problem you don't have yet.

Two listeners, two tables. Cheap to bolt on, and it turns "something broke for someone, sometime" into a query you can answer.


> 2024-05-01 update. Vendure added sentry plugin, which might make most of this post useless. I did not have time to explore the plugin yet. https://docs.vendure.io/reference/core-plugins/sentry-plugin/


[Vendure.io](https://vendure.io) is a great framework, but the [official documentation](https://docs.vendure.io/guides/developer-guide/error-handling/) does not specify anything related to error logging, or even where does the error boundary end.

Vendure does by default handle all errors thrown through the graphql and rest endpoints.

But it is quite easy to stop the whole server by simply not handling exception for example in event subscribers.
```typescript
async onApplicationBootstrap() 
{

    this.eventBus
        .ofType(eventType)
        .pipe(filterRule)
        .subscribe(async (event) => {
            throw new Error('Not allowed')
        });
}
```
You will stop the entire server process by throwing exception, and it is quite easy to do such mistake.

# Setup

## Install sentry
```typescript
yarn add @sentry/node
yarn add @sentry/tracing
```

## Initialize sentry
in your vendure-config file
```typescript
Sentry.init({  
    dsn: SENTRY_DSN,  
    tracesSampleRate: 1.0,  
    debug: IS_DEV,  
});

export const config: VendureConfig = {
...
}
```

# Handling for server
Errors that are thrown during the request-response cycle are caught and returned in the graphql. So here we only need to add logging.
## Create Exception filter
```typescript
import { ArgumentsHost, Catch, ExceptionFilter } from '@nestjs/common';  
import * as Sentry from "@sentry/node";  
import "@sentry/tracing";  
  

@Catch()  
export class SentryExceptionFilter implements ExceptionFilter {  
    catch(exception: Error, host: ArgumentsHost) {
        Sentry.captureException(exception)  
    }  
}
```

## In some plugin
```typescript
@VendurePlugin({  
    ...
    providers: [  
        ...
        {  
            provide: APP_FILTER,  
            useClass: SentryExceptionFilter,  
        },  
    ],  
})
```

This captures the error when returing through GraphQL, but it still does not solve the issue for consumers and cronjobs. 

# Handling in event subscribers
To make sure all subscribers are error-free, I created a simple reusable event subscriber.
```typescript
export abstract class BaseSubscriber<T extends VendureEvent & {ctx: RequestContext}> {
    constructor(
        protected transactionalConnection: TransactionalConnection
    ) {
    }

    public async subscribe(event: T): Promise<void> {
        try {
            await this.transactionalConnection.withTransaction(event.ctx, async (ctx) => {
                await this.doSubscribe(ctx, event);
            })
        } catch (e) {
            Sentry.captureException(e);
        }
    }

    protected abstract doSubscribe(ctx: RequestContext, event: T): Promise<void>;
}
```

The actual event subscriber will look like this
```typescript
@Injectable()
export class FulfillmentOnFulfillmentCreatedSubscriber extends BaseSubscriber<FulfillmentEvent> {
    public static eventType = FulfillmentEvent;
    public static filterRule = filter((event: FulfillmentEvent) => event.entity.handlerCode === CONTEST_FULFILLMENT_HANDLER_CODE);

    constructor(
        transactionalConnection: TransactionalConnection
    ) {
        super(transactionalConnection);
    }

    public async doSubscribe(ctx: RequestContext, event: FulfillmentEvent): Promise<void>
    {
        // do your action
    }
}
```
Then add the event subscriber like so in your plugin
```typescript
async onApplicationBootstrap() {
    this.eventBus
        .ofType(CouponFulfillmentOnPaymentSettledSubscriber.eventType)
        .pipe(CouponFulfillmentOnPaymentSettledSubscriber.filterRule)
        .subscribe(this.couponFulfillmentOnPaymentSettledSubscriber.subscribe);
}
```

# Handling for crons
Manually wrapping each cron in the exception handler
```typescript
const createSafeTransactionalCron = (app: INestApplicationContext, time: string, callback: (ctx: RequestContext) => Promise<void>) => {  
    return new CronJob(time, async () => {  
        const sentryLogger = app.get(SentryLogger);  
        const connection = app.get(TransactionalConnection);  
  
        try {  
            await connection.withTransaction(async (ctx) => {  
                await callback(ctx)  
            })  
        } catch (e) {  
            sentryLogger.logException(e);  
        }  
    })  
}
```

## In worker
```typescript
bootstrapWorker(config)  
.then(worker => {  
    const job = createSafeTransactionalCron(worker.app, `*/15 * * * * *`, async (ctx) => {  
        throw new Error('Test error');
    });  
    job.start();  
})
```

This should ensure that the app does not crash, and all exceptions will be visible in Sentry


Blog