Skip to content

Feature Request: Blocks-based statusline display for subscription users #658

Description

@chy5301

Problem

Currently, the ccusage statusline command displays cost-based metrics (e.g., 💰 $0.23 session / $1.23 today / $0.45 block (2h 45m left)). While this is useful for pay-per-use scenarios, it's less meaningful for subscription users (monthly/yearly Claude Code plans) .

For subscription users, information on block usage may be much more valuable than hypothetical cost calculations.

Proposed Solution

Add a new statusline mode that displays block-based metrics instead of cost-based metrics. This could be implemented as:

Option 1: New flag

ccusage statusline --blocks

Option 2: Configuration option

Allow users to set their preferred statusline mode in the configuration file.

Expected Output

Instead of cost-focused display:

🤖 Opus | 💰 $0.23 session / $1.23 today / $0.45 block (2h 45m left) | 🔥 $0.12/hr | 🧠 25,000 (12%)

Show block-focused display:

🤖 Opus | 📊 88.9% block(33m left) | 🚀 23.1% usage (47.7k/207k tokens) | 📈 26.7% projected | 🧠 50,000 (24%)
# or
🤖 Opus | 📊 88.9% block(33m left) | 🚀 23.1% usage (47.7k/207k tokens) | ✅ WITHIN LIMIT | 🧠 50,000 (24%)

Or similar format showing:

  • Current session progress within the 5-hour block
  • Block token usage and limits
  • Displays projected usage (if current rate continues) or the availability status.
  • Context usage (already implemented)

Reference

The ccusage blocks --live command already provides excellent block-based monitoring in a dashboard format. The same logic could be adapted for the statusline to show:

  • Session progress within current block
  • Token usage vs limits
  • Burn rate in tokens/h instead of $/hr
  • Projected block completion

This would make the statusline much more actionable for subscription users who want to understand their usage patterns within Claude Code's 5-hour billing windows.

Use Case

As a Claude Code subscription user, I want to see how much of my current 5-hour block I've used and at what rate, rather than seeing hypothetical costs that don't apply to my subscription model.

Additional Context

The current cost-based display works well for pay-per-use users, so this feature should be additive rather than replacing the existing functionality. Both modes should be available depending on user preference or subscription type.

Activity

  1. ryoppippi commented on Sep 23, 2025

    @ryoppippi
    Member

    contributions are welcome
    if you want to contribute it, open this issue again and send us a pr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions