[FEATURE] Status line should expose billing type to conditionally display cost

Resolved 💬 4 comments Opened Feb 6, 2026 by PureMintSoftware Closed Feb 10, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The status line JSON input (cost.total_cost_usd) always shows a calculated cost regardless of whether the user is on a Pro plan, extra usage, or using API credits. There's no way to distinguish between the two, so Pro plan users see a misleading cost figure (e.g. Cost:$2.43) that isn't actually being charged to them.

Requested Changes

  1. Add a billing/plan type field to the status line JSON input, e.g.:

{
"cost": {
"total_cost_usd": 2.43,
"billing_type": "pro" | "api" | "pro_overage"
}
}

  1. This would allow status line commands to conditionally show cost only when it's relevant (API usage or overage charges).

Additional Context

  • Setting up a working status line is already difficult (jq isn't always installed, printf percent escaping is tricky, field names aren't well documented)
  • Pro plan users shouldn't have to see a fake cost that implies they're being charged
  • This is a simple metadata addition that would make the status line much more useful

Environment

  • Claude Code on Linux (Ubuntu)
  • Pro plan subscriber
  • Using custom statusLine command in ~/.claude/settings.json

Proposed Solution

Add a billing_type field to the status line JSON input so custom status line commands can conditionally display cost. When billing_type is "pro", the cost field can be hidden or replaced with "Pro Plan". When billing_type is "api" or "pro_overage", the
actual cost is shown. This requires minimal backend changes - the billing context already exists internally, it just needs to be passed through to the status line JSON payload.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗