[BUG] Insanely high usage (56% 5h pro) after "continue" (Claude Sonnet 4.6 - auto effort) with just a few file edits

Status Fixed / completed
Maintainer reply ✓ Yes — bcherny
Activity 11 comments · opened Apr 6, 2026 · closed Apr 24, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

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

  1. Run Claude Code with --model sonnet.
  2. Set /effort auto
  3. Hit the 5h limit within a session.
  4. Press continue
  5. 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_

View original on GitHub ↗

11 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/40696
  2. https://github.com/anthropics/claude-code/issues/43657
  3. https://github.com/anthropics/claude-code/issues/38029

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

junaidtitan · 4 months ago

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-age compacts old tool results (10-40% savings), compact-summary-collapse removes pre-compaction content (85-95%), and 16 other strategies target different bloat types.

pip install cozempic && cozempic init

The guard auto-starts on every session and keeps files lean so --continue doesn't burn your quota.

trader642 · 4 months ago

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.

milankubin · 4 months ago
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).

milankubin · 4 months ago
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-age compacts old tool results (10-40% savings), compact-summary-collapse removes pre-compaction content (85-95%), and 16 other strategies target different bloat types. pip install cozempic && cozempic init The guard auto-starts on every session and keeps files lean so --continue doesn't burn your quota.

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

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-age compacts old tool results (10-40% savings), compact-summary-collapse removes pre-compaction content (85-95%), and 16 other strategies target different bloat types. pip install cozempic && cozempic init The guard auto-starts on every session and keeps files lean so --continue doesn't burn your quota.

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 :)

bcherny collaborator · 4 months ago

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.

junaidtitan · 4 months ago

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 relevant
  • compact-summary-collapse: removes pre-compaction messages already captured in summaries
  • progress-tick-strip: removes the repetitive progress/heartbeat messages that accumulate
pip install cozempic
cozempic treat --rx standard   # one-shot cleanup before resuming
# or run the guard daemon to prune continuously:
cozempic guard --rx standard

On 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

bcherny collaborator · 4 months ago

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.

milankubin · 4 months ago
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:

 continue                                                                                                                                                                 

●  source .venv/bin/activate.fish; python -c "import jsonschema, referencing; print…)
  Read 1 file (ctrl+o to expand)

● source .venv/bin/activate.fish; python -c "from jsonschema import Draft202012Val…)
  ⎿  OK both available

  Searched for 2 patterns, read 1 file (ctrl+o to expand)

● Good — Feature.is_core_feature exists. Now let me look at yaml_load to find where validation is invoked, then build the Python validator. First, let me check
  yaml_utils.py:
  Read 1 file (ctrl+o to expand)
● Now I have what I need. Implementing #36. Replacing ys subprocess with Python jsonschema + a URI retriever that handles core://, semantics://, and relative refs:
  Read 1 file (ctrl+o to expand)
● Now replace the ys subprocess body with Python jsonschema+referencing:
● Update (..........)
  ⎿  Added 104 lines, removed 29 lines
● Now check if _resolve_ys_executable, _summarize_output, the shutil and SubprocessExecutor imports are still used. If not, 
  Searched for 1 pattern, read 1 file (ctrl+o to expand)
  ⎿  Found 1 new diagnostic issue in 1 file (ctrl+o to expand)
● Update
  ⎿  Added 16 lines, removed 17 lines
● Now make  X FATAL, and split core vs non-core feature failure:
● Update()
  ⎿  Added 16 lines, removed 17 lines
● Update(
  ⎿  Added 11 lines

Then some docker restart with very conservative greps/ tails
     … +12 lines (ctrl+o to expand)
     … +16 lines (ctrl+o to expand)
     ....+ 11 lines                                                                                                                    │
     … +62 lines (ctrl+o to expand)
     … +14 lines (ctrl+o to expand)

+ a grep returning 4 lines
+ another bash command to restart the container with sleep,wait, tail-3 very selective sed | grep.

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.

milankubin · 4 months ago

@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.

github-actions[bot] · 3 months ago

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.