[BUG] Insanely high usage (56% 5h pro) after "continue" (Claude Sonnet 4.6 - auto effort) with just a few file edits
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?
Honestly, the usage is so random:
Often the usage speaks initially on a fresh session - no skills loaded, and just two mcp's: Serena and Context7.
Plugins: typescript-lsp, pyright-lsp.
Serena lists some files in initial prompt for reference (small .md memory files).
Initial prompt is a few paragraphs worth of small list of memory (.md) files and when to load them.
They are loaded on-demand (AGENT discretion).
It tends to settle down around 25% and then get pretty good usage out of Sonnet.
But this is what I would expect from an Opus 4.6 high effort planning prompt.
This is just insane.
I typed "continue" went AFK to have lunch, expecting a few small fixes, or it waiting for permissions.
But it stopped after some tiny edits.
Serena tool calls are usually lighter than file reads as well, and these files are not huge anyway.
Code is pretty well chunked up and organized.
Explain this...
● Bash(git status && git log --oneline -12)
⎿ On branch dev
Your branch is ahead of 'bitbucket/dev' by 7 commits.
(use "git push" to publish your local commits)
… +17 lines (ctrl+o to expand)
⎿ You're out of extra usage · resets 2pm (Europe/Amsterdam)
/upgrade or /extra-usage to finish what you’re working on.
✻ Cogitated for 4m 13s
2 PM :
❯ continue
● Working tree is clean. The STATUS has P9-6.4h (TYPE_CHECKING generator fix) and P9-6.13 (dev-up check) as next tasks. Dev-up will fail
at BRK-2 regardless — let me do P9-6.4h first so the generator is correct before re-running it, then dev-up.
Loading the needed memories:
● serena - Read Memory (MCP)(memory_name: "backend/src/core/codegen/orm_dto_generator")
⎿ {
"result": "# orm_dto_generator — ORM and DTO Generator\n\n## What it is\n\n`backend/src/core/codegen/orm_dto_generator.py` —
the code generator that produces SQLAlchemy ORM models and Pydantic DTO models from feature config YAMLs.\n\nClass: `OrmDtoGe
… +14 lines (ctrl+o to expand)
● serena - Read Memory (MCP)(memory_name: "global/prescriptive/authoring/python/type_checking_imports")
⎿ {
"result": "# TYPE_CHECKING Import Pattern\n\nUse `if TYPE_CHECKING:` for imports needed only in annotations (avoids circular
\nimports, zero runtime cost):\n\n```python\nfrom typing import TYPE_CHECKING\n\nif TYPE_CHECKING:\n from src.core.features
… +5 lines (ctrl+o to expand)
● Now let me find the relevant generator code:
● serena - Get Symbols Overview (MCP)(relative_path: "backend/src/core/codegen/orm_dto_generator.py", depth: 1)
⎿ {
"result": "{\"Constant\": [\"GENERATED_FILE_MARKER\", \"GENERATED_PACKAGE_MARKER\", \"GENERATED_AT_PATTERN\", \"GM001\", \"G
M002\", \"GM003\", \"GM004\", \"GM005\", \"GM006\", \"GM007\", \"_BEGIN_MARKER_TPL\", \"_END_MARKER_TPL\", \"_LEGACY_BEGIN\",
… +20 lines (ctrl+o to expand)
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_render_model_module", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: true)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_render_model_module\", \"kind\": \"Method\", \"relative_path\": \"backend/src
/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 481, \"end_line\": 548}, \"body\": \"@classmethod\\n
… +21 lines (ctrl+o to expand)
● Now I need to understand _ModelRenderContext and how relationships are resolved:
● serena - Find Symbol (MCP)(name_path_pattern: "_ModelRenderContext", relative_path: "backend/src/core/codegen/orm_dto_generator.py",
include_body: true)
⎿ {
"result": "[{\"name_path\": \"_ModelRenderContext\", \"kind\": \"Class\", \"relative_path\": \"backend/src/core/codegen/orm_
dto_generator.py\", \"body_location\": {\"start_line\": 153, \"end_line\": 159}, \"body\": \"@dataclass(frozen=True)\\nclass _
… +3 lines (ctrl+o to expand)
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_resolve_relationship_target_class", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: true)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_resolve_relationship_target_class\", \"kind\": \"Method\", \"relative_path\":
\"backend/src/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 1211, \"end_line\": 1242}, \"body\": \
… +10 lines (ctrl+o to expand)
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_render_model_relationship", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: true)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_render_model_relationship\", \"kind\": \"Method\", \"relative_path\": \"backe
nd/src/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 1316, \"end_line\": 1378}, \"body\": \"@classm
… +25 lines (ctrl+o to expand)
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_collect_model_render_context", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: true)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_collect_model_render_context\", \"kind\": \"Method\", \"relative_path\": \"ba
ckend/src/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 404, \"end_line\": 438}, \"body\": \"@class
… +10 lines (ctrl+o to expand)
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_render_inline_column_relationship", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: true)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_render_inline_column_relationship\", \"kind\": \"Method\", \"relative_path\":
\"backend/src/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 1262, \"end_line\": 1314}, \"body\": \
… +19 lines (ctrl+o to expand)
● Now I have full context. Let me also check the ModelEntry type to understand the relationships field:
● serena - Find Symbol (MCP)(name_path_pattern: "ModelEntry", relative_path: "backend/src/core/codegen/orm_dto_generator.py",
include_body: true)
⎿ {
"result": "[]"
}
Searched for 2 patterns (ctrl+o to expand)
● Good. Now I have everything needed. The fix requires:
1. A new helper method _collect_cross_module_type_checking_imports
2. Updated _render_model_module to use it
Let me implement:
● serena - Find Symbol (MCP)(name_path_pattern: "OrmDtoGenerator/_resolve_relationship_target_class", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", include_body: false)
⎿ {
"result": "[{\"name_path\": \"OrmDtoGenerator/_resolve_relationship_target_class\", \"kind\": \"Method\", \"relative_path\":
\"backend/src/core/codegen/orm_dto_generator.py\", \"body_location\": {\"start_line\": 1211, \"end_line\": 1242}}]"
}
● Now implementing. First insert the helper after _resolve_relationship_target_class, then update _render_model_module:
● serena - Insert After Symbol (MCP)(name_path: "OrmDtoGenerator/_resolve_relationship_target_class", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", body: "\n @classmethod\n def
_collect_cross_module_type_checking_imports(\n cls,\n model_items: list[tuple[str,
ModelEntry]],\n *,\n module_path: str,\n context: _ModelRenderContext,\n )
-> list[tuple[str, str]]:\n \"\"\"Collect cross-module relationship targets that need
TYPE_CHECKING imports.\n\n Args:\n model_items: Model names and specs for the
module being rendered.\n module_path: Dotted module path being rendered.\n
context: Global rendering context.\n\n Returns:\n Sorted unique (source_module,
class_name) pairs for TYPE_CHECKING block.\n \"\"\"\n class_to_module: dict[str, str]
= {}\n for impl_path in context.model_by_impl:\n if \".\" in impl_path:\n
mod, target_cls = impl_path.rsplit(\".\", 1)\n class_to_module[target_cls] =
mod\n\n cross_module: set[tuple[str, str]] = set()\n\n for model_name, model_spec in
model_items:\n for rel_spec in (model_spec.relationships or {}).values():\n
target_class = cls._resolve_relationship_target_class(\n
current_class_name=model_name,\n current_model=model_spec,\n
target=rel_spec.target,\n context=context,\n )\n if
target_class == model_name:\n continue\n target_module =
class_to_module.get(target_class)\n if target_module and target_module !=
module_path:\n cross_module.add((target_module, target_class))\n\n for
col_spec in model_spec.columns.values():\n if col_spec.fk is None or
col_spec.fk.relationship is None:\n continue\n target_class =
cls._resolve_relationship_target_class(\n current_class_name=model_name,\n
current_model=model_spec,\n target=col_spec.fk.target,\n
context=context,\n )\n if target_class == model_name:\n
continue\n target_module = class_to_module.get(target_class)\n
if target_module and target_module != module_path:\n
cross_module.add((target_module, target_class))\n\n return sorted(cross_module)\n")
⎿ {
"result": "OK"
}
● serena - Replace Symbol Body (MCP)(name_path: "OrmDtoGenerator/_render_model_module", relative_path:
"backend/src/core/codegen/orm_dto_generator.py", body: "@classmethod\n def
_render_model_module(\n cls,\n model_items: list[tuple[str, ModelEntry]],\n
*,\n source_hints: list[str],\n module_path: str,\n context:
_ModelRenderContext,\n ) -> str:\n \"\"\"Render one generated model module.\n\n
Args:\n model_items: Model names and validated specs for one module.\n
source_hints: YAML source hints included in the header.\n module_path: Dotted module path
being rendered.\n context: Global rendering context for relationship and inheritance\n
resolution.\n\n Returns:\n Generated model module source code.\n
\"\"\"\n\n used_mixins = {\n mixin_name\n for _, model_spec in
model_items\n for mixin_name in model_spec.mixins\n }\n mixin_import_lines
= [\n f\"from {cls.MIXIN_IMPORT_PATHS[mixin_name]} import {mixin_name}\"\n for
mixin_name in sorted(used_mixins)\n if mixin_name in cls.MIXIN_IMPORT_PATHS\n ]\n
docstring_lines = [\n \"Generated at: <generated>\",\n
GENERATED_FILE_MARKER,\n *[f\"Source YAML: `{hint}`\" for hint in source_hints],\n
\"Edit model definitions in YAML and regenerate via OrmDtoGenerator.\",\n ]\n
header_lines = ['\"\"\"', *docstring_lines, '\"\"\"', \"\"]\n\n cross_module_imports =
cls._collect_cross_module_type_checking_imports(\n model_items, module_path=module_path,
context=context\n )\n typing_import = (\n \"from typing import
TYPE_CHECKING, ClassVar\"\n if cross_module_imports\n else \"from typing
import ClassVar\"\n )\n import_lines = [\n \"from datetime import date,
datetime, time\",\n typing_import,\n \"import uuid\",\n \"\",\n
\"import sqlalchemy as sa\",\n \"from pydantic import JsonValue\",\n
\"from sqlalchemy.dialects import postgresql\",\n \"from sqlalchemy.orm import Mapped,
mapped_column, relationship\",\n \"from pgvector.sqlalchemy import Vector\",\n
\"\",\n *mixin_import_lines,\n \"from src.core.tsm_db.database import
Base\",\n ]\n if mixin_import_lines:\n import_lines.append(\"\")\n
if cross_module_imports:\n import_lines.extend([\n \"if
TYPE_CHECKING:\",\n *[f\" from {mod} import {cls_name}\" for mod, cls_name in
cross_module_imports],\n \"\",\n ])\n lines = [line for line in
header_lines + import_lines if line is not None]\n\n for model_name, model_spec in
model_items:\n lines.extend(\n cls._render_model_class(\n
model_name,\n model_spec,\n context=context,\n
)\n )\n lines.extend([\"\", \"\"])\n\n return
\"\\n\".join(lines).rstrip() + \"\\n\"")
⎿ {
"result": "OK"
}
● Now verify it runs correctly:
● Bash(cd **********************backend && source .venv/bin/activate.fish 2>/dev/null;
.venv/bin/python -m src.core.codegen.orm_dt…)
⎿ Wrote 50 generated model files.
● Generator runs clean with 50 files. Let me verify the TYPE_CHECKING block appears correctly in a generated file with cross-module
relationships:
Searched for 1 pattern, read 1 file (ctrl+o to expand)
● That's a legacy file from the old generator. Let me check one from our new generator:
Read 1 file (ctrl+o to expand)
● TYPE_CHECKING, ClassVar in the typing import, and the if TYPE_CHECKING: block correctly importing User from the user module. Now
update STATUS and commit:
● Update(*************************/STATUS_plan-9.md)
⎿ Added 1 line, removed 1 line
141
142 ### Component: Generator enhancement — `TYPE_CHECKING` imports
143
144 -- [ ] P9-6.4h Add `TYPE_CHECKING` imports to `_render_model_module` in `orm_dto_generator.py` — generated ORM files em
-it `Mapped["User"]` etc. with no import; fix: build `class_name→module_path` lookup from `context.model_by_impl`, coll
-ect cross-module relationship targets per module, emit `from typing import TYPE_CHECKING, ClassVar` + `if TYPE_CHECKIN
-G:` import block; affects all generated ORM files (Python 3.14)
144 +- [x] P9-6.4h Add `TYPE_CHECKING` imports to `_render_model_module` in `orm_dto_generator.py` — added `_collect_cross_
+module_type_checking_imports` helper; generator now emits `TYPE_CHECKING, ClassVar` + `if TYPE_CHECKING:` block for cr
+oss-module relationship targets; generator ran clean (50 files); verified in `workspace_orm.py` (`User` import)
145
146 ### Component: Generated ORM models and Pydantic schemas (`orm/`, `dto/`)
147
● Bash(cd **********************************&& git add backend/src/core/codegen/orm_dto_generator.py
backend/src/**********************************o…)
⎿ M backend/src/core/codegen/orm_dto_generator.py
M backend/src**********************************STATUS_plan-9.md
M backend/src/core/**********************************_orm.py
… +19 lines (ctrl+o to expand)
● Good — the regenerated ORM files show the TYPE_CHECKING additions. Stage and commit everything together:
● Bash(git add backend/src/ && git commit -m "$(cat <<'EOF'
plan-9(P9-6.4h): generator TYPE_CHECKING imports for cross-module relationships…)
⎿ [dev aef0f8c0] plan-9(P9-6.4h): generator TYPE_CHECKING imports for cross-module relationships
22 files changed, 239 insertions(+), 375 deletions(-)
● aef0f8c0. P9-6.4h done. Next is P9-6.13 — starting make dev-up to verify what currently breaks (BRK-2 import failures expected). Shall
I proceed?
✻ Cogitated for 3m 42s
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
🔋:2.2k/90.3k | 💰:2.47/50.00 | 📨:22/746 | ⌛️:4h 16m | 🤖:sonnet(Sonnet 4.6)
⏵⏵ accept edits on (shift+tab to cycle)
14:49 <img width="1242" height="286" alt="Image" src="https://github.com/user-attachments/assets/5e172291-9514-422a-a1be-2b2e7af8f673" />
### What Should Happen?
FIx the random high usage problems
### Error Messages/Logs
```shell
Steps to Reproduce
- Run Claude Code with --model sonnet.
- Set /effort auto
- Hit the 5h limit within a session.
- Press continue
- Cry
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
v2.1.92
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
_No response_
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
56% usage after continuing with a few edits means the resumed session carried massive accumulated bloat from the previous run. Cozempic v1.6.11's guard daemon prunes at configurable thresholds —
tool-result-agecompacts old tool results (10-40% savings),compact-summary-collapseremoves pre-compaction content (85-95%), and 16 other strategies target different bloat types.pip install cozempic && cozempic initThe guard auto-starts on every session and keeps files lean so
--continuedoesn't burn your quota.Having the same experience. Something changed about 18 hours ago that feels like a real inflection point and the system is no longer usable. I'm on the 20x sub and my 5h quota reset recently, after a few short conversations it is now at 40% 16 minutes later. Never seen anything even close to this before with Claude Code. Something seems very broken. Have almost never hit a 5h limit before even with extensive usage, this is a massive change. Also seeing a lot of 429 rate limit errors even at off peak times.
Github marked this as a possible duplicate from "initial high usage after continue" load, but honestly it's indeed an "addon" if you will.
I tested it again: Now with the screen recorder on, and "continue" with immediate refresh in browser: immediate 6% jump in the 5h quota.
Mind you: This was on medium effort preset, and it jumped before Claude even produced an output.
So yes, that's indeed an issue as well that something I any many had become familiar with in January (initial high usage jumps), and were told that there were "1-2%" "edge cases" where "some accounts" would see this.
This actually seemed to have been fixed somewhere in February, where it dropped back to about 1%-2% in alignment with the amount of tokens used for loading of the initial contexts (seen in /context).
Thanks, I'll give it a look and try.
Still is a bug, the behavior doesn't make sense.
I don't do long running threads, and never auto-compact: start with a fresh session every time and a hand-off prompt if I managed to get it squeezed in.
How can this "accumulated bloat" be pushed to the server to be billed, when it was already accounted for in the last session?
And how can that ever be like 50% of the whole context window, when the context window itself for that session hadn't even run out. You can see
Looks to be it.
The session file stands out as a 1.6MB file with most of the content about 80% to the stop.
Seeing a lot of '"ephemeral_5m_input_tokens":126177}" prior
And also seeing a lot of parentuuid references and "acompact" files for subagents.
Which all kind of confuses me, given I have auto-compact turned off and like I said: When context runs out, I start a new session.
I have just archived all sessions right now, and will look at your tool and see if it can guard me indeed
Why the short cache lifetime? Wouldn't it be more logical to see a long lived cache job on usage depletion in such a case?
Can't believe this is a "feature" and not a bug :)
Hi, if you see this again, can you please run /feedback and share the id here? That will make it possible for us to debug what's going on, or if it's already fixed in the latest.
The usage spike after "continue" happens because the full accumulated session context gets sent to the API on resume — every old tool result, progress tick, and stale output from before you went AFK. That 56% burn in a few edits is the model re-reading hundreds of KB of dead context each turn.
Cozempic's guard daemon prunes the JSONL session file before the resumed session hits the API. Key strategies for this case:
tool-result-age: stubs old tool results that are no longer relevantcompact-summary-collapse: removes pre-compaction messages already captured in summariesprogress-tick-strip: removes the repetitive progress/heartbeat messages that accumulateOn a session like yours with lots of Serena tool calls and a long history, you'd typically see 40-70% reduction in context size, which directly translates to lower token burn per turn after "continue".
https://github.com/Ruya-AI/cozempic
Hey all, we have root caused and fixed this. Detailed technical post-mortem here: https://www.anthropic.com/engineering/april-23-postmortem. If you see any more issues/weirdness, please don't hesitate to run
/feedback+ open an issue.Not entirely convinced that the issue is completely resolved.
Version: v2.1.119
From what it looks like there is still a big carry-over of history into the session on a 'continue' :
Initial very rapid increase to about 39% usage, then subsequently settling down (increase to action ratio diminished massively).
I can share you the logs in confidential matter which the actual work efforts being produced, and even it being Opus 4.7 (low setting) this is just a massive jump for essentially moving
But came down to this:
And all for about :
When I noticed and checked, slightly less than 40%
<img width="1646" height="393" alt="Image" src="https://github.com/user-attachments/assets/46d14d13-0460-476e-9a2c-a155df81ec03" />
This basically makes a plus plan useless afaic.
there is no point with the 5h window to even try a $20 plan, because there is just no point in waiting only to get screwed over again on the next session.
@bcherny See #53514 I created a new issue, because I'll grant that some issue has been resolved by you guys. If you like me to continue here (reopen) and close the other one that's fine as well.
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.