Feature Request: Include usage data in status line JSON input

Additional Enhancement: Multi-line Status Line Support

To make this feature truly useful, it would be beneficial to also add multi-line status line support.

Current Limitation

According to the status line documentation, only the first line of stdout is displayed:

"The first line of stdout from your command becomes the status line text"

Why Multi-line Support Matters

With usage data available in the JSON input, users would want to display comprehensive information similar to the /usage command output:

Current session:  █▌░░░░░░░░░░░░░░░░░░░░░░░░░ 3% used | Resets 3pm
Week (all):       ▌░░░░░░░░░░░░░░░░░░░░░░░░░░ 1% used | Resets Oct 9, 4pm  
Week (Opus):      ░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0% used

This requires multiple lines to display different usage metrics (session, weekly all models, weekly Opus) with their respective progress bars.

Current Workaround

Some third-party tools like ccstatusline have found ways to create multi-line displays, but this isn't native functionality. Having official multi-line support would enable users to:

1. Display usage data across multiple lines for better readability
2. Show different rate limit windows separately (5-hour, weekly, per-model)
3. Include progress bars alongside other status information
4. Avoid cramming all information into a single line

Proposed Enhancement

Allow status line commands to output multiple lines (e.g., 2-4 lines) that would all be displayed in the status line area, similar to how multi-line shell prompts work (PS1/PS2).

This would complement the usage data availability and make the status line truly useful for monitoring multiple metrics at a glance.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

No, don't close it.

Still needed. I've filed #16629 with a concrete use case: Windows Task Scheduler automation. Between #1886, #8412, and #16629, there's clear demand for programmatic usage data access.

Big +1 for this feature. Please implement this.

+1

+1 for this!

It's the real metric users need to track throughout the day to avoid hitting limits. Having this available in the status line would be much more useful than context window percentage.

Would love to see both the 5-hour and weekly windows exposed, so users can display something like 5h: 34% | Week: 48% right in their prompt. 🚀

+1

I just mistakenly added a dup of this at #18519 . I'll close it and follow this one. Which has been open a long time, which doesn't give me much hope.

+1, this would be extremely useful for workflow management

To make this feature truly useful, it would be beneficial to also add multi-line status line support.

@ankurdesaicopart this seems off topic and over complicates the issue.

First, this doesn't have to be multiline, I just want to display current/weekly usage percentages inline with my other statusbar components.

Second, it already seems possible to have a multi-line statusbar if you want that. If I put echo -e "foo\nbar" in my statusline script, I get two lines in my statusbar.

+1 for this!

+1

My workaround: https://gist.github.com/lexfrei/b70aaee919bdd7164f2e3027dc8c98de

My workaround: https://gist.github.com/lexfrei/b70aaee919bdd7164f2e3027dc8c98de

You are a life saver @lexfrei ! Thanks @anthropics for providing the endpoint in beta!

For anyone landing here: this shipped in v2.1.80. The statusline stdin now includes:

rate_limits.five_hour.used_percentage   (float, e.g. 42.7)
rate_limits.five_hour.resets_at         (unix timestamp)
rate_limits.seven_day.used_percentage
rate_limits.seven_day.resets_at

Gotcha: used_percentage is a float — null|floor crashes jq 1.7.1, so guard with if type=="number" then floor else "--" end.

claude-lens uses these fields to show remaining % plus a pace delta (burning faster or slower than expected). The raw fields above are enough to build your own.

This is a duplicate of #18121, which was fixed as of version 2.1.80.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.