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.
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.
\nIf the usage data has no five-hour window:
\n5h figure, no reset timer and no five-hour pressure figure. The weekly figure stays.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.
\nWhen 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.
\nIt 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.
\nThere 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.
" }, "markdown_text": "---\ntitle: 'When your plan has no five-hour limit'\ncanonical: 'https://www.dealmobile.co.uk/writing/when-there-is-no-five-hour-limit'\nurl: 'https://www.dealmobile.co.uk/writing/when-there-is-no-five-hour-limit'\ntype: Post\npublished: '2026-11-01'\nsummary: '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.'\n---\n\n# When your plan has no five-hour limit\n\nPublished 2026-11-01\n\n\n\nMullet 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.\n\n## What changed\n\nMullet 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.\n\nIf the usage data has no five-hour window:\n\n- The HUD drops its five-hour parts: no `5h` figure, no reset timer and no five-hour pressure figure. The weekly figure stays.\n- The guard paces on the weekly limit alone and pauses at 95% of it. The reset time it reports is then the weekly one.\n\nIf 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.\n\nWhen 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.\n\n## The setting\n\nIt is a config option, `hud.five_hour`, with three values:\n\n- `auto`, the default, which follows the data.\n- `on`, which always shows and paces against a five-hour limit.\n- `off`, which never does.\n\nThe environment variable `MULLET_HUD_FIVE_HOUR` overrides it for one run, and `mullet config show hud` lists the current value.\n\nIt 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.\n\n## Tests\n\nThere 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.\n\nMullet’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.\n\nThe code is at