
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.

![Grouped bar chart of tokens per task read across 300 Asana tasks, bucketed by data shape. The MCP get_task + get_stories call costs 11,000-18,400 tokens per read; the markdown skill costs 970-2,770, 6.5-11.3× fewer. Across all 300 tasks the skill averages 2,210 tokens against the MCP's 15,790.](/blog/claude-code-script-vs-mcp-tokens-300.svg)

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.


> 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