Ondřej Tůma


Not many people seem to know this, so here it is: the 5-hour usage window in Claude Code does **not** 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.

That little detail is worth a surprising amount.

## Why you should care

Say you sit down at 9:00, fire off your first real prompt, and grind. Your window now resets at 14:00 — right in the middle of the afternoon, exactly when you do *not* want to be told to wait. You accidentally anchored your reset to the worst possible time.

The fix is silly and effective: **start the window on purpose, early, with something throwaway.**

Ask Claude "what's the weather today?" at 6:00 — from your phone, on the way to work — and your windows now fall at:

```
06:00  (first prompt)
11:00  reset
16:00  reset
21:00  reset
02:00  reset
```

Now the resets land in the gaps — your commute, lunch, after dinner — instead of mid-task. You can even put a tiny cron job on it so it happens before you wake up. The window is going to start *somewhere*; you might as well pick where.

## 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 *convenience*, not *more usage* — it stops the short window from resetting at the one moment you need it most.

Small trick, but I reach for it every morning.



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



# The technical side
The technical side was set of extensions for the [vendure](https://vendure.io) ecommerce platform together with custom storefront.

It included extensions for the following functions
- contest events
- coupon codes handling and automated email fulfillment
- integration with [zalando](https://zalando.com)
- gopay integration
- payU integration
- [pohoda](https://pohoda.cz) accounting integration



# Project
Voting platform that enables the judges of a competition to vote for the winner. It was an internal tool developed for the finale in 2021.

It was designed to work for the onboarding and internal processes for next years.



2021 - present	ShipMonk	Backend engineer (Senior PHP)
2020 - 2021	NFCtron	Backend engineer (PHP, Nest.js)
2019 - 2019	AI Center	Tooling developer (Python)
2016 - 2016	MALPRO	Automation developer (Python)

I am a DeveloperStudentCreativeMinimalist

Latest projects

Awincado

Leaves Bar

Miss Czech Republic

Latest blog posts

Contact