[FEATURE] expose current reasoning effort level in statusline JSON input

Resolved 💬 3 comments Opened Mar 25, 2026 by rtuin Closed Mar 28, 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 statusline JSON payload that Claude Code sends to custom statusline scripts does not include the current reasoning effort level. This makes it impossible to display the active effort level in the statusline.

The reasoning effort level is a key parameter that directly affects model behavior, response quality, and token usage. Unlike other model parameters, it is highly dynamic — it can change through multiple mechanisms during a single session:

  • Default from settings: effortLevel in settings.json or managed settings
  • Environment variable: CLAUDE_CODE_EFFORT_LEVEL
  • In-session changes: the /effort slash command
  • Skill/subagent overrides: individual skills and subagents can declare their own effort level in frontmatter

Because of this layered, dynamic nature, there is currently no single trustworthy source a statusline script can read to determine the currently active effort level. Reading settings.json or the environment variable only captures one layer and will show stale data when the effort changes mid-session.

Proposed Solution

Add an effort_level field to the statusline JSON input, alongside the existing fields like model, context_window, rate_limits, and vim.mode.

The value should reflect the currently active effort level after all layers of configuration have been resolved (settings default -> environment variable -> /effort command -> skill/subagent override), so that statusline scripts always display the correct, real-time value.

Example addition to the statusline JSON:

{
  "model": { "id": "claude-opus-4-6", "display_name": "Opus 4.6" },
  "effort_level": "medium",
  ...
}

This follows the same pattern as vim.mode and agent.name, which are already exposed as dynamic session state in the statusline JSON.

Alternative Solutions

  1. Read settings.json directly in the statusline script — Only captures the persistent default. Does not reflect in-session changes via /effort or skill/subagent overrides. Shows stale data.
  1. Read the CLAUDE_CODE_EFFORT_LEVEL environment variable — Only captures the environment-level override. Does not reflect /effort changes, settings.json defaults, or skill/subagent overrides.
  1. Combine both sources in the script — Still incomplete. The /effort slash command and skill/subagent frontmatter overrides are not visible to external scripts, so there will always be cases where the displayed value is wrong.

None of these alternatives can reliably show the currently active effort level because the resolution logic lives inside Claude Code and is not externally observable.

Priority

Low - Nice to have

Feature Category

Interactive mode (TUI)

Use Case Example

As a power user running Claude Code on Opus 4.6, I typically operate at medium effort to balance speed and quality. However, certain skills and subagents in my configuration override the effort level (e.g., a planning agent runs at high), and I sometimes manually switch with /effort max for complex tasks.

My custom statusline already shows model name, context window usage, rate limits, git branch, and sandbox status. I want to add the current effort level so I can see at a glance whether I'm running at low, medium, high, or max — especially when effort changes implicitly through a skill or subagent invocation, where it's easy to lose track of what level is active.

Without this, I have no way to confirm the active effort level without checking multiple configuration sources, and even then I can't account for in-session or subagent-level overrides.

Additional Context

_No response_

View original on GitHub ↗

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