[BUG] Claude Code stuck with "Usage credits required for 1M context" even after /clear and available usage limit

Open 💬 4 comments Opened Jun 4, 2026 by devcicm

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code stuck with Usage credits required for 1M context even after /clear, restarting the session, and having usage limit available

I am reporting a recurring issue in Claude Code related to the 1M context mode. The error appears even though I still have usage available, approximately half or less than half of my allowed usage limit.

Error message

API Error: Usage credits required for 1M context - run /usage-credits to turn them on, or /model to switch to standard context

The same error also appears during compaction:

Error during compaction: API Error: Usage credits required for 1M context - run /usage-credits to turn them on, or /model to switch to standard context

Observed behavior

The issue started happening after I used the Opus 4.8 model for the first time. Before that, when I reached a normal usage limit, Claude Code would simply tell me that I had to wait for a certain amount of time before continuing, or that I could use credits.

Now the behavior is different: the session gets stuck with the 1M context error, even though it does not look like my general usage limit is fully exhausted.

Steps I already tried

I tried several workarounds without success:

  1. Cleared the session using:
/clear
  1. Closed the session completely and started a new one.
  1. Modified environment variables to avoid using 1M context.
  1. Switched models using:
/model
  1. Tried to continue after clearing and restarting the session.

The error still kept appearing.

Temporary workaround that worked

The only way I was able to unblock the session was the following:

  1. Switched the model to Haiku.
  2. Allowed the session to compact using Haiku.
  3. Switched back to Sonnet.
  4. After that, Claude Code allowed me to continue working.

This seems to indicate that the problem is not directly related to the general usage limit, but rather to the internal session state, compaction behavior, or automatic selection of 1M context.

Additional context

The error appeared after a session where the agent explored several files and consumed a considerable amount of tokens. However, the important point is that the system should not become permanently blocked or require 1M context credits if there is still available capacity under the normal usage limit.

Before using Opus 4.8, this behavior did not happen to me. The previous flow was clearer: if I reached a usage limit, Claude Code would simply show the waiting time required to continue, or the option to use credits.

Expected behavior

I would expect one of the following behaviors:

  • Claude Code should automatically use standard context if 1M context is not enabled.
  • /clear should actually release the state causing the error.
  • Closing and reopening the session should clear the internal state related to 1M context.
  • /compact should not try to use 1M context if it is not enabled.
  • Switching models should apply correctly to the current session, not only to new sessions.
  • The error message should clearly distinguish between the general usage limit, 1M context credits, and a corrupted or blocked session state.

Actual behavior

The session gets stuck with:

Usage credits required for 1M context

This happens even after using /clear, closing and reopening the session, modifying environment variables, and switching models. I was only able to continue by temporarily switching to Haiku, letting the session compact, and then switching back to Sonnet.

What Should Happen?

Technical suspicion

My suspicion is that Claude Code is automatically trying to use 1M context during compaction, or after using Opus 4.8, even though I did not explicitly request 1M context. It also seems like the context-related state remains attached to the session and is not properly cleared by /clear or by closing and reopening the session.

It would be useful to confirm whether this is a known bug or if there is an official recommended way to permanently force standard context for existing sessions.

Error Messages/Logs

procede a implementar el plan completo

● Lanzo 3 agentes de exploración en paralelo para entender el estado actual de todos los archivos antes de diseñar el
  plan final:

● 3 Explore agents finished (ctrl+o to expand)
   ├ Explore validator, lexer errors, and executor · 10 tool uses · 55.4k tokens
   │ ⎿  Done
   ├ Explore MCP stream tools and StreamRegistry · 7 tool uses · 42.1k tokens
   │ ⎿  Done
   └ Explore DSL kinds, shorthands patterns, and system prompts · 25 tool uses · 36.4k tokens
     ⎿  Done
  ⎿  API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to
     standard context

✻ Brewed for 2m 35s

> /model
  ⎿  Set model to Haiku 4.5 and saved as your default for new sessions

> /compact
  ⎿  Error: Error during compaction: API Error: Usage credits required for 1M context · run /usage-credits to turn them
     on, or /model to switch to standard context

> /model
  ⎿  Set model to Sonnet 4.6 (default) and saved as your default for new sessions

> continua
  ⎿  API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to
     standard context

✻ Worked for 2s

> /model                                                                                                                  ⎿  Set model to Opus 4.8 and saved as your default for new sessions

> continua
● Exploration gave me precise data. Let me read the critical insertion points directly before designing the final plan —  particularly _compilePacket (which I now suspect drops warnings entirely) and the BxValidator rule structure.

  Read 2 files (ctrl+o to expand)

● Critical finding from exploration that reshapes the plan: the static linter (BxValidator, with rules W001–W040 already  covering box/unknown-kind, malformed hex, missing units, etc.) is never run in the streaming path. _compilePacket
  only runs the schema validator + executor — so every gotcha warning the linter could emit is silently dropped during
  emit_packet/emit_batch. The lint exists; it's just disconnected.

Steps to Reproduce

none

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v2.1.162

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

<img width="1365" height="726" alt="Image" src="https://github.com/user-attachments/assets/c5d01a52-182a-4cbf-8a18-5c49432c448e" />

View original on GitHub ↗

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