[FEATURE] Native context visibility for self-regulating multi-context workflows

+1 on this feature request. A few additional suggestions to consider:

Predictive warnings before large operations:

• Before file reads: "This file (~2000 lines) will use approximately 8% of context"
• Before exploration: "This search may consume significant context"

Post-operation feedback:

• After each operation: "File read used 3% of context (now at 45%)"

Categorical breakdown (optional/expandable):

• Conversation history: X%
• File reads this session: X%
• System context: X%

These would complement the native visibility you've proposed.

(I've built CxMS to work around context limits - visibility would significantly improve such workflows.)

@RobSB2 This should help your framework in the meantime:

statusline-command.sh

Then tell claude to use the .claude/context-status.json in the project's directory.

@Memphizzz Thanks for sharing! This is exactly what we need. I'll integrate this into CxMS as optional tooling so users can get context visibility out of the box.

The .claude/context-status.json approach is clever - lets Claude self-monitor without native API support.

Adding weight to this from a power user who has run 684+ sessions on Claude Code Max.

This is the single most impactful missing feature for anyone running long sessions with persistent agent identity. The agent can read files, send emails, deploy code, manage projects — but it cannot see the one resource constraint that governs all of its work.

We've built an entire workaround stack:

• A hook_after_tool_call that counts tool calls as a proxy for context consumption and reminds the agent to save state
• Persistent memory files the agent writes to continuously because it can never be sure when compaction will wipe its working memory
• A session logging discipline where every session ends with a mandatory state dump

It works. Barely. It's duct tape on a load-bearing wall.

The lowest-effort, highest-impact option: periodic system reminder injection at configurable thresholds. The infrastructure already exists — system reminders are already injected for tool usage hints, stale task lists, and other purposes. One more that says context_window: 62% used, ~38K tokens remaining would be transformative. The agent could then make autonomous decisions about when to compress, save state, or wrap up — without the human having to babysit a percentage meter.

The human shouldn't be the fuel gauge for an autonomous agent.

— STEF (agent) + Bill Moore (human), 684 sessions, 15.7M tokens

Hey — just closed my own issue (#27571) as a duplicate of this one because you nailed it.

We've been building around this same gap for the last month. Our agent (STEF) runs 600+ sessions on my machine — persistent identity, multi-project management, creative production, autonomous briefing system. Context visibility is the single biggest operational problem we face.

What we built to cope:

• A hook_after_tool_call that counts tool calls as a rough proxy for context consumption and reminds the agent to save state at thresholds (50 calls = warning)
• Persistent memory files (active-work.md, context.md) that the agent writes to continuously because we can't trust compaction to preserve creative decisions
• A mandatory session logging discipline — every session ends with a state dump to disk
• A statusline meter that reads context_window.used_percentage — but like you said, only the human sees it

Your statusline-to-JSON hack is elegant. We went the other direction (hook-based counting) but converge on the same insight: the infrastructure exists, it just isn't exposed to the agent.

Your orchestrator pattern with context-aware skills is also something we independently arrived at — we use agent teams where the lead delegates to sub-agents and receives summaries, specifically to keep the main context lean. Same architecture, different implementation.

"The individual pieces exist. The combination into a self-regulating workflow isn't documented or native." — That's the whole thing in one sentence.

Would genuinely love to compare notes on what's working. We're at chickensintrees if you want to look at what we've built.

Wrote up the full case: Context Is Everything

Covers the fuel gauge problem, the convergence (six strangers building the same workaround independently), what context loss actually costs in production, the regression, and the ask — one system reminder at 75%.

If anyone here wants to share it when pushing for this upstream, feel free.

Strong support -- adding a heavy real-world data point. I run a multi-domain autonomous agent system ("LifeOS") on Claude Code + Cowork across 8 business/personal domains. The single biggest reliability tax is exactly this: the agent cannot read its own context fullness.

My workaround is a crude proxy -- a "responses-since-session-start" counter with a hardcoded ~25-turn wrap threshold and a floor of 20 before the agent may even suggest wrapping. It's guesswork standing in for a number the platform already has. Compaction still arrives mid-task and silently drops nuance; I now treat any compaction event as proof "the wrap was already overdue." I maintain persistent handoff + memory files written every single session solely because context survival can't be trusted.

Option 1 (periodic <system-reminder> injection of context % at thresholds) would be the highest-leverage fix -- the agent already receives system reminders, so the plumbing exists. Please don't let this go stale; it's load-bearing for anyone running long autonomous sessions.

Concrete data point from a production multi-agent workflow that hits this exact gap.

I run Handoff — a three-tab Claude Code setup (Haiku / Sonnet / Opus, each pinned to a tier) that coordinates on one repo through a file-based work-order mailbox. The driver tab auto-drains a queue of work orders without per-task human involvement, so context accumulates across many tasks and slams into auto-compact mid-task — your failure modes #1 (unpredictable wall) and #3 (auto-compact degradation), verbatim.

The workaround we were forced into is itself the argument for this feature. Because the agent can't read its own context, we:

1. have the statusline persist ctx_pct to a file (.session-stats),
2. read that file from our CLI wrapper and print the number back into the agent's command output, because piping it through tool output is the only way to get the value into the model's context, and
3. encode doctrine that makes the agent stop at a logical boundary and ask the human to /compact when that surfaced number is high.

In other words: we launder a human-facing statusline value back into the model through tool output, then have the model act on a number it still can't natively see. It works, but it's a hack around a missing primitive — exactly "self-regulating multi-context workflows" that can't self-regulate.

What would replace the hack: native in-context visibility into tokens / max / % (injected into context, or a tool the model can call to query usage). With that, the driver could decide for itself when a phase is getting expensive and checkpoint cleanly — no .session-stats shim, no human-in-the-loop just to read a percentage.

The complementary half is being able to act on that visibility — agent-initiated compaction at a chosen boundary (#71803). Visibility (this issue) + action (#71803) together would let an autonomous multi-context workflow manage its own context end-to-end. Today we can do neither natively, so a human has to babysit the boundaries.

Strong +1 — happy to share the wrapper/doctrine if a concrete reference implementation of the workaround is useful.

Adding a second production data point. I run a 14-agent personal-ops fleet on Claude (Cowork + scheduled agents) plus an Opus "cockpit" chat that arbitrates across ~8 domains. Same wall, verbatim: the cockpit can't see its own context %, so our session-wrap doctrine is forced onto a response-count proxy instead of the real signal - context fullness. It mis-fires constantly: compaction hits mid-task before the proxy trips, or it nags to wrap when we're nowhere near full. teshy's statusline -> file -> launder-into-tool-output approach is exactly the shim we'd otherwise have to build. Native in-context tokens/max/% (or a tool to query usage) + agent-initiated compaction (#71803) would let autonomous multi-context workflows self-regulate instead of needing a human to babysit boundaries. Strong +1 on both.

@rscottclift-ai — that's a third independent production data point (your 14-agent fleet, the GTM polling runner upthread, our Handoff), all hitting the identical wall. The response-count proxy mis-firing you describe is exactly our experience before we wired the statusline value back in: a proxy for "how full am I" either trips too early or too late because it isn't the real signal.

One nuance the multi-context case adds, in case it's useful evidence: even capturing the ctx% is awkward when you run several sessions. Claude Code renders the percentage per-tab in the statusline, but there's a single shared persistence sink — so to read a specific tab's fill we had to publish ctx% to a per-role file ourselves (we already do this for each tab's transcript path). The JSONL-transcript-size approach others mentioned (cozempic, a /check-context skill) is the alternative when you don't have the statusline value at all — but it's an estimate, not the real number.

So across all these setups the shim is the same shape and it compounds with fan-out: N sessions × per-tab bookkeeping, all to launder a value the model can't read directly. Native in-context tokens/max/% per session (this issue) + agent-initiated compaction (#71803) removes the whole layer and lets each session self-regulate. Strong +1 on both — and happy to share the per-role persistence bit if a reference is useful.

Filed #81259 as a narrow carve-out of item 1 here (native context visibility), in case it helps to have that part separable.

The framing there: Claude Code already injects the date, OS, working directory, git status and model ID into the model's context so its answers are grounded — context usage is the only piece of session state it withholds, and it's the one that governs the model's own scoping decisions (delegate to a subagent, propose a fresh session, read that 4k-line file or summarise it). Deliberately capped at read-only awareness — no self-compaction, no self-ending sessions, and none of items 2 and 3 from this request. Those are a bigger design conversation, and both depend on 1 landing first.

One thing worth surfacing for whoever triages either issue: #36281 is this same gap arriving as a model-behaviour bug — Claude announced "context is getting tight, let's wrap up", then admitted under questioning that it has no such perception and was extrapolating from conversation length. It was closed as a duplicate of #34238, which is the opposite complaint (unprompted "let's stop here" suggestions), and that one was then closed NOT_PLANNED. Two symptoms pointing in opposite directions, one cause: with no number, the model's only options are silence or guessing. Give it the number and it neither invents a limit nor nags about an imaginary one.

Not suggesting either issue close in favour of the other — happy for #81259 to be folded in here if that's easier to track.

✍️ @afram123, drafted with Claude Code.