[FEATURE] Expose Thinking Mode Status in StatusLine JSON Input

yes, I support this request. I hope thinking state can be added to status line.

yes, i keep toggling it off by mistake and not knowing

i've got massive sausage fingers

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.

bump to prevent auto-close

bump to delay auto close again

Please implement this 🙏

The effort level for Opus 4.6 should also be added. We really need to be able to see the current state of thinking and effort clearly.

👍 Adding support from #23929 (closed as duplicate).

Use Case: I've implemented a custom statusline showing context usage, model info, and git status. The missing piece is thinking mode status - I have no way to know if extended thinking is active without it.

Current Problem:

• Reading ~/.claude/settings.json only shows configured value, not runtime state
• Tab key toggles aren't reflected
• Easy to work in wrong mode without realizing

Impact: This affects anyone using custom statuslines (which is becoming more common as statusline configuration improved in recent releases).

Implementation: Should be straightforward - just add one field to existing statusline JSON structure. Backward compatible since old scripts ignore unknown fields.

Would be happy to help test or even contribute a PR if there's guidance on where the statusline JSON is constructed.

bump to delay auto close again, pls implement 🙏

+1 this would be a good feature.
however I made my status bar script work and it updates the bar after changing thinking effort /model

<img width="699" height="72" alt="Image" src="https://github.com/user-attachments/assets/03143b31-3dee-4c6c-a273-cbc6e03d0ed7" />

+1, this would be super helpful

+1 we needs effort infomation, high, medium, low.

+1 waiting for this feature

Seeing the effort would be great!

+1 for this feature, and specifically requesting that reasoning effort level be included alongside thinking mode.

What I need:

• reasoning_effort.configured — what the user set (low/medium/high/max/auto)
• reasoning_effort.resolved — what level is actually being used right now (especially important when set to auto, so users can see what the system chose)

Current pain points:

1. The spinner-based effort display (#31565) is intermittent — shows for early messages then disappears
2. No way for custom statusLine scripts to show effort level at all
3. When using auto effort, there's no visibility into what level was actually selected

Proposed addition to statusLine JSON:

{
  "model": {
    "id": "claude-opus-4-6",
    "display_name": "Opus 4.6",
    "thinking_enabled": true,
    "reasoning_effort": {
      "configured": "auto",
      "resolved": "high"
    }
  }
}

The workaround of reading CLAUDE_CODE_EFFORT_LEVEL env var or settings.json only shows the configured value, not what auto resolves to. Having both in the JSON would make custom status lines much more useful.

Follow-up to my previous comment — after more research, I want to refine the request:

The built-in right-side effort indicator (○ ◐ ●) was changed in v2.1.72 from persistent to transient/brief. This means:

1. The data clearly exists internally — Claude Code already knows the effort level and displays it briefly
2. Making it persistent (or at least configurable) would solve most of the UX problem
3. Exposing it in the statusLine JSON would let custom scripts show it permanently on the left side

Ideal solution would be both:

• A setting like "persistEffortIndicator": true to keep the built-in right-side indicator visible
• AND adding reasoning_effort (configured + resolved) to the statusLine JSON for custom scripts

The resolved level when using auto is especially valuable — v2.1.73 notes that /effort shows what auto resolves to "matching the status bar indicator", so the resolved value is already computed.

The latest comments here align with #37764 and #37701 — all requesting effort/thinking state in stdin. I shared a --slurpfile workaround in #37764 that reads effortLevel from settings.json in the same jq call that processes stdin — no extra file I/O. Works for the persisted default, but Tab toggles and mid-session /effort changes aren't reflected.

Native stdin support is the real fix. I use the workaround in claude-lens and it covers ~90% of use cases, but the remaining 10% (mid-session changes) needs this issue resolved.

+1 we needs effort information: high, medium, low, max, auto

This issue was fixed as of version 2.1.119.

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.