---
title: 'When your plan has no five-hour limit'
canonical: 'https://www.dealmobile.co.uk/writing/when-there-is-no-five-hour-limit'
url: 'https://www.dealmobile.co.uk/writing/when-there-is-no-five-hour-limit'
type: Post
published: '2026-11-01'
summary: 'Mullet 2.5.0 copes with a Claude plan whose usage data has no five-hour window: the HUD drops the five-hour figures and the budget guard paces on the weekly limit. A setting lets you override what it detects.'
---

# When your plan has no five-hour limit

Published 2026-11-01

![No five-hour limit. data has a 5h window: 5h, reset timer, weekly. no 5h window: weekly figure only. pause point: 95% of the weekly limit. setting: hud.five_hour: auto | on | off.](https://www.dealmobile.co.uk/sites/default/files/styles/almanac_shot_md/public/content/images/posts/when-there-is-no-five-hour-limit/hero.png.webp?itok=AMrGIFoG)

Mullet 2.5.0 copes with a Claude plan whose usage data has no five-hour window. The HUD drops the five-hour figures, and the budget guard paces and pauses on the weekly limit alone. A setting, `hud.five_hour`, overrides what Mullet detects. My notes say some plans send no five-hour window to Claude Code’s status line. I have not checked which plans, so treat that as unverified.

## What changed

Mullet shows your usage in a small HUD, and a budget guard reads the same numbers to decide when a job should slow down or stop. Both expect two limits: a five-hour window and a weekly one. In 2.5.0 they also cope when the five-hour window is absent.

If the usage data has no five-hour window:

- The HUD drops its five-hour parts: no `5h` figure, no reset timer and no five-hour pressure figure. The weekly figure stays.
- The guard paces on the weekly limit alone and pauses at 95% of it. The reset time it reports is then the weekly one.

If the data does have a five-hour window, nothing changes. The guard still pauses only when 95% of the five-hour limit and 90% of the weekly limit are both used.

When a single reading leaves the five-hour window out, the earlier figure is carried forward only while that window’s reset time is still in the future, so a stale value cannot stick.

## The setting

It is a config option, `hud.five_hour`, with three values:

- `auto`, the default, which follows the data.
- `on`, which always shows and paces against a five-hour limit.
- `off`, which never does.

The environment variable `MULLET_HUD_FIVE_HOUR` overrides it for one run, and `mullet config show hud` lists the current value.

It is a per-user setting because plans differ. I cannot tell you which plans have a five-hour window and which do not. That is whatever the usage data says, which is why the default follows the data and nothing is hard-coded to one account.

## Tests

There are 24 new tests for this. A usage object that lacks the `has_five_hour` field is treated as having a five-hour window, as before. An existing test passes the guard a bare stand-in object with no such field, and I left that test as it was, because it covers exactly the case of usage data with a field missing.

Mullet’s whole suite has about 18,700 tests, by pytest’s collection count on 1 November. I have not run Mullet against every kind of plan, so if your HUD shows something odd, set `hud.five_hour` to `off` or `on` and tell me what the data looks like.

The code is at <https://github.com/tomgould/mullet-public>.

- **Projects:** [Mullet](https://www.dealmobile.co.uk/projects/mullet.md)
- **Tags:** [AI](https://www.dealmobile.co.uk/writing/tag/ai.md), [Python](https://www.dealmobile.co.uk/writing/tag/python.md), [Testing](https://www.dealmobile.co.uk/writing/tag/testing.md), [Mullet](https://www.dealmobile.co.uk/writing/tag/mullet.md)

---

Index of this site: [llms.txt](https://www.dealmobile.co.uk/llms.txt)