**Bug Description** Opus 4.5 spun up 6 research agents and exhausted the 5 hours token budget in 3-7minutes! the research agents output wasn't even provided! **Environment Info** - Platform: linux - Terminal: ghostty - Version: 2.0.72 - Feedback ID: 7383180f-db13-47f4-a749-58b132bb7031 **Errors** ```json [] ``` Previous session ran normally and hit usage limit:

[Bug] Opus 4.5 research agents exhaust token budget rapidly without returning any output

Resolved 💬 3 comments Opened Dec 18, 2025 by so0k Closed Dec 22, 2025

Bug Description
Opus 4.5 spun up 6 research agents and exhausted the 5 hours token budget in 3-7minutes! the research agents output wasn't even provided!

Environment Info

Platform: linux
Terminal: ghostty
Version: 2.0.72
Feedback ID: 7383180f-db13-47f4-a749-58b132bb7031

Errors

[]

Previous session ran normally and hit usage limit:

While waiting for the session to reset I did my own user-research.md ~ 7129 tokens

~/go/bin/gotok --quiet --encoding p50k_base < user-research.md
7129

As soon as the 5 hour session reset, I prompted to continue

but within 3 min, the subagents exhausted all my tokens

I received, no warning, no indicator...just blocked..

and even when I add /extra-usage ... the subagents data is gone! So all tokens are wasted?

<details><summary>Detailed Session logs</summary>

continue

∴ Thinking…

  Several research agents have completed. Let me retrieve their outputs and consolidate the findings with the user's research. I still need to wait for the reading time
  research agent (a75a322).

● Several agents completed. Let me retrieve their findings.                                                                          06:06 PM  claude-opus-4-5-20251101

● Task Output(non-blocking) aa8df5a
Research Shiki integration (11 lines)

  Prompt:
    Research Shiki syntax highlighting integration with MDX/rehype in 2025.

    Investigate:
    1. Package choice: @shikijs/rehype vs rehype-shiki vs rehype-pretty-code
    2. Custom theme creation - How to create a theme JSON matching these existing colors:
      - Keywords: Purple (#7c3aed light, #a78bfa dark)
      - Types/Classes: Blue (#2563eb light, #93c5fd dark)
      - Strings: Green (#16a34a light, #86efac dark)
      - Numbers: Pink (#db2777 light, #f472b6 dark)
      - Comments: Gray (#6b7280 light, #9ca3af dark)
    3. Dual theme support - Light/dark mode switching (CSS variables vs class-based)
    4. Line highlighting - Syntax for highlighting specific line ranges
    5. Line numbers - Built-in vs manual implementation
    6. Transformers - @shikijs/transformers for meta string parsing

    The context: A static MDX blog needing VS Code-quality syntax highlighting with light/dark theme support matching existing landing page colors.

    Provide recommended configuration and explain how to create a custom theme.

  Response:
    [Tool: WebSearch] {"query":"Shiki rehype MDX integration 2025 @shikijs/rehype"}
    [Tool: WebSearch] {"query":"Shiki custom theme creation JSON format dual light dark mode 2025"}
    [Tool: WebSearch] {"query":"rehype-pretty-code vs @shikijs/rehype comparison 2025"}
    [Tool: WebSearch] {"query":"Shiki transformers line highlighting meta string syntax 2025"}
    [Tool: WebSearch] {"query":"Shiki theme JSON structure format token colors example 2025"}
    [Tool: WebSearch] {"query":"@shikijs/transformers line numbers implementation 2025"}
    [Tool: WebSearch] {"query":"@shikijs/transformers line numbers implementation 2025"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

● Task Output(non-blocking) ac094a3
Research image optimization (13 lines)

  Prompt:
    Research image optimization strategies for Vite-based static sites in 2025.

    Compare these approaches:
    1. vite-plugin-imagetools - Build-time image processing with URL queries
    2. vite-plugin-image-optimizer - Global image compression
    3. Using both together - Complementary approach
    4. Sharp/imagemin pre-commit - Manual optimization

    For each, evaluate:
    - Setup complexity for a static blog
    - Output formats (WebP, AVIF support)
    - Responsive image generation (srcset)
    - Lazy loading support
    - Build time impact
    - Compatibility with co-located assets (images in same folder as MDX)

    The context: A static MDX blog where images are co-located with posts (e.g., blog/my-post/diagram.png). Need optimized images for performance (Lighthouse ≥90 target).

    Recommend the best approach and explain why.

  Response:
    [Tool: WebSearch] {"query":"vite-plugin-imagetools 2025 setup guide WebP AVIF responsive images"}
    [Tool: WebSearch] {"query":"vite-plugin-image-optimizer 2025 configuration static site"}
    [Tool: WebSearch] {"query":"Vite image optimization 2025 best practices MDX blog performance"}
    [Tool: WebSearch] {"query":"Sharp imagemin Vite build time optimization 2025"}
    [Tool: WebSearch] {"query":"vite-plugin-imagetools srcset responsive images lazy loading 2025"}
    [Tool: WebSearch] {"query":"vite-plugin-imagetools build time performance impact large projects"}
    [Tool: WebSearch] {"query":"vite-plugin-imagetools MDX markdown co-located images import"}
    [Tool: WebSearch] {"query":"combining vite-plugin-imagetools vite-plugin-image-optimizer best practices"}
    [Tool: WebSearch] {"query":"combining vite-plugin-imagetools vite-plugin-image-optimizer best practices"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

● Task Output(non-blocking) aec7a72
Research MDX+Vite best practices (11 lines)

  Prompt:
    Research best practices for @mdx-js/rollup integration with Vite in 2025.

    Investigate:
    1. Plugin configuration - Correct order with @vitejs/plugin-react
    2. remark/rehype plugin chain - Recommended plugins for:
      - Frontmatter parsing (remark-frontmatter, remark-mdx-frontmatter)
      - Heading IDs (rehype-slug)
      - TOC extraction (@stefanprobst/rehype-extract-toc or alternatives)
      - Syntax highlighting with Shiki (@shikijs/rehype)
    3. Custom component registration - MDXProvider vs file-level imports
    4. TypeScript support - Type definitions for MDX files
    5. Hot reload - HMR behavior for MDX content changes

    The context: A Vite 5 project adding MDX support for a blog. Need build-time compilation with Shiki syntax highlighting, frontmatter as exports, and TOC extraction.

    Provide a recommended vite.config setup and explain the plugin order.

  Response:
    [Tool: WebSearch] {"query":"@mdx-js/rollup Vite 5 plugin configuration order 2025"}
    [Tool: WebSearch] {"query":"remark-frontmatter remark-mdx-frontmatter MDX 3 Vite 2025"}
    [Tool: WebSearch] {"query":"Shiki rehype syntax highlighting MDX Vite configuration 2025"}
    [Tool: WebSearch] {"query":"rehype-slug rehype-extract-toc MDX table of contents 2025"}
    [Tool: WebSearch] {"query":"MDX TypeScript types vite-env.d.ts module declaration 2025"}
    [Tool: WebSearch] {"query":"MDX HMR hot module reload Vite plugin development 2025"}
    [Tool: WebSearch] {"query":"MDX HMR hot module reload Vite plugin development 2025"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

● Task Output(non-blocking) aaad696
Research React 18 vs 19 (13 lines)

  Prompt:
    Research React 18 vs React 19 for a static MDX blog in 2025.

    Investigate:
    1. React 19 stability - Is it production-ready as of Dec 2025?
    2. Bundle size comparison - React 18 vs 19 gzipped
    3. MDX compatibility - Any issues with @mdx-js/rollup?
    4. New features relevant to static blogs - Actions, compiler, etc.
    5. Breaking changes - Migration concerns from 18 to 19

    The context: A static MDX blog that uses React only for rendering MDX content and interactive components (TOC, search). No SSR, just build-time prerendering.

    Recommend which version to use and explain why.

  Response:
    [Tool: WebSearch] {"query":"React 19 stable release production ready December 2025"}
    [Tool: WebSearch] {"query":"React 19 vs React 18 bundle size comparison gzipped 2025"}
    [Tool: WebSearch] {"query":"React 19 MDX compatibility @mdx-js/rollup issues 2025"}
    [Tool: WebSearch] {"query":"React 19 new features static site generation compiler 2025"}
    [Tool: WebSearch] {"query":"React 19 breaking changes migration from React 18 2025"}
    [Tool: WebSearch] {"query":"React 19 breaking changes migration from React 18 2025"}
    [Tool: WebSearch] {"query":"static MDX blog React 19 build time rendering 2025"}
    [Tool: WebSearch] {"query":"React 19 compiler benefits static site MDX prerendering"}
    [Tool: WebSearch] {"query":"React 19 compiler benefits static site MDX prerendering"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

● Task Output(non-blocking) a9b654e
Research SSG strategies for Vite (11 lines)

  Prompt:
    Research SSG (Static Site Generation) strategies for Vite + React + MDX blogs in 2025.

    Compare these approaches:
    1. vite-plugin-ssr / Vike - Full SSR framework
    2. Custom prerender script - Manual static generation using Vite's build API
    3. vite-plugin-press - ServiceStack's content plugin

    For each, evaluate:
    - Setup complexity
    - Build-time MDX compilation support
    - Compatibility with multi-page output (separate HTML per post)
    - Bundle size impact
    - Active maintenance status (check npm/GitHub)
    - Ability to customize rehype/remark plugins

    The context: A static blog where pages are pre-rendered at build time (not SSR). React is only needed for MDX components, not routing. Need full control over Shiki
    syntax highlighting and TOC extraction.

    Recommend the best approach for this use case and explain why.

  Response:
    [Tool: WebSearch] {"query":"vite-plugin-ssr Vike SSG static site generation 2025"}
    [Tool: WebSearch] {"query":"Vite React MDX static site generation prerender 2025"}
    [Tool: WebSearch] {"query":"vite-plugin-press ServiceStack 2025 MDX"}
    [Tool: WebSearch] {"query":"vite-react-ssg npm github 2025 maintenance status"}
    [Tool: WebSearch] {"query":"Vite custom prerender script build API React static generation 2025"}
    [Tool: WebSearch] {"query":"@mdx-js/rollup Vite React rehype remark plugins 2025"}
    [Tool: WebSearch] {"query":"@mdx-js/rollup Vite React rehype remark plugins 2025"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

● Task Output(non-blocking) a75a322
Research reading time calculation (12 lines)

  Prompt:
    Research reading time calculation approaches for MDX blogs in 2025.

    Compare these approaches:
    1. remark-reading-time - Remark plugin (build-time in MDX pipeline)
    2. Custom Vite plugin - Calculate during build
    3. reading-time npm package - Manual calculation in build script

    For each, evaluate:
    - Integration with @mdx-js/rollup pipeline
    - Accuracy (handles code blocks, frontmatter exclusion)
    - Output format (minutes, words per minute configurable)
    - How to export the value alongside frontmatter
    - Maintenance status

    The context: A static MDX blog using @mdx-js/rollup for compilation. Need to display reading time on post cards and article pages. Average reading speed assumption:
    200 words/minute.

    Recommend the best approach and explain why.

  Response:
    [Tool: WebSearch] {"query":"remark-reading-time MDX plugin 2025"}
    [Tool: WebSearch] {"query":"reading-time npm package MDX blog integration"}
    [Tool: WebSearch] {"query":"Vite plugin calculate reading time MDX @mdx-js/rollup"}
    [Tool: WebSearch] {"query":"Vite plugin calculate reading time MDX @mdx-js/rollup"}
    [Tool: WebSearch] {"query":"remark-reading-time github maintenance status 2024 2025"}
    [Tool: WebSearch] {"query":"custom remark plugin reading time MDX frontmatter export"}
    [Tool: WebSearch] {"query":"reading-time package npm code blocks accuracy 200 wpm"}
    [Tool: WebSearch] {"query":"reading-time package npm code blocks accuracy 200 wpm"}

    --- RESULT ---
    Limit reached · resets 11pm (Asia/Saigon) · /upgrade to Max or add funds to continue with extra usage

∴ Thinking…

  The research agents hit rate limits and couldn't complete their web searches. However, I have the user's comprehensive research in user-research.md which already covers all
  these topics thoroughly. Let me:

  1. Update the research.md to consolidate the user's research (which is already comprehensive)
  2. Continue with Phase 1 artifacts - quickstart.md
  3. Update agent context
  4. Re-evaluate Constitution Check

  The user's research already provides excellent coverage of:
  - SSG Strategy: Custom prerender script recommended
  - Image Optimization: Both plugins recommended
  - Reading Time: remark-reading-time recommended
  - MDX Pipeline: Full configuration provided
  - React Version: React 19 recommended

  Let me update todos and continue with the remaining Phase 1 work.

● The research agents hit rate limits, but your user-research.md is comprehensive and covers everything needed. Let me consolidate it06:07 PMe claude-opus-4-5-20251101ontinue with Phase 1.

</details>

View original on GitHub ↗

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