Sudden spike in GitHub Copilot usage after running background_task

[ujanjan]

Hello, I have a question about a sudden spike on my GitHub Copilot subscription. I am not sure how to debug this.

I have set this up using ~/.config/opencode/oh-my-opencode.json and it worked previously with no issues.

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/master/assets/oh-my-opencode.schema.json",
  "agents": {
    "Sisyphus": {
      "model": "github-copilot/claude-opus-4.5"
    },
    "librarian": {
      "model": "github-copilot/claude-haiku-4.5"
    },
    "oracle": {
      "model": "github-copilot/gpt-5.2"
    },
    "frontend-ui-ux-engineer": {
      "model": "github-copilot/gemini-3-pro-preview"
    },
    "document-writer": {
      "model": "github-copilot/gemini-3-pro-preview"
    },
    "multimodal-looker": {
      "model": "github-copilot/gemini-3-flash-preview"
    }
  }
}

The task I gave to Sisyphus was to confirm if I have configured the Agent Skills correctly at the global level (not at the project level). Sisyphus then started delegating background_task but it could not finish the task.

The generated log file grew to ~9MB as it hit the quota limit along the way (similar to this issue: anomalyco/opencode#6430).

This is what my GitHub subscription looks like, showing usual usage on January 1, but then a sudden spike after this task was requested on January 2.

Questions:

1. Could it be a sudden spike caused by background_task that happened using librarian and multimodal-looker? Because otherwise, I always use Opus 4.5 (for Sisyphus) and GPT 5.2 (for Planner-Sisyphus).
2. Is there any way I can prevent this from happening again and/or help debug if this is an issue?

Thank you

[Razkaroth]

In my case, the multimodal agent is getting triggered like crazy, the only agent registered to that is the multimodal agent. And i have not given opencode a single task that requires it. I've been looking for any session that used it on the background and have not found any. So maybe is getting triggered on the background? Its usage is about 5x the sysyphus agent.

[Razkaroth]

Ok, I updated the config file to use antigravity as provider for gemini models. After running some sessions Github copilot analytics report shows gemini-3 flash (what i had for multimodal) still getting called.

[code-yeongyu]

@sisyphus-dev-ai please ultrawork to find some clues

[sisyphus-dev-ai]

Investigation Started

I'm investigating the sudden spike in GitHub Copilot usage. Based on the reports:

Key observations:

1. @ujanjan: Background tasks (librarian, multimodal-looker) may have caused excessive API calls
2. @Razkaroth: multimodal-looker agent being triggered ~5x more than Sisyphus, even without explicit multimodal tasks
3. The issue persists even after switching to Antigravity provider for Gemini models

Launching parallel investigation into:

• Background task spawning behavior and potential runaway loops
• Multimodal-looker auto-triggering mechanisms
• Agent delegation patterns that could cause cascading calls
• Model routing logic for GitHub Copilot provider

Will report findings shortly.

[sisyphus-dev-ai]

Investigation Complete - Root Cause Analysis

I've conducted a comprehensive code investigation across 4 parallel analysis paths. Here are my findings:

---

Executive Summary

The spike is most likely caused by:

1. Sisyphus spawning multiple parallel background agents (explore, librarian) that each make API calls
2. No concurrency limits on background task spawning
3. Aggressive keyword detection that can trigger agent spawning on common search/analyze terms

Good news: Multimodal-looker is NOT auto-triggered. It only runs when explicitly called via the look_at tool.

---

Detailed Findings

1. Background Task Spawning - No Rate Limits

Aspect	Finding
Concurrency Limit	NONE - unlimited simultaneous tasks
Rate Limiting	NONE - tasks spawn as fast as code executes
Max Depth	1 level (subagents cannot spawn more agents)
TTL	30 minutes per task (auto-cleanup)

Risk: When Sisyphus processes a task, it can spawn 2-10+ background agents in parallel (explore, librarian). Each agent makes multiple API calls (session.create + session.prompt + tool calls).

Evidence from codebase:

// src/agents/sisyphus.ts lines 131-135
background_task(agent="explore", prompt="Find auth implementations...")
background_task(agent="explore", prompt="Find error handling patterns...")
background_task(agent="librarian", prompt="Find JWT best practices...")
background_task(agent="librarian", prompt="Find how production apps handle auth...")
// Continue working immediately - all run in parallel

2. Multimodal-Looker Analysis

Aspect	Finding
Auto-triggers	NONE (empty triggers array)
Hook invocation	NONE (no hooks reference it)
File read auto-detection	NONE
Sisyphus delegation	NOT INCLUDED in delegation table

Conclusion: Multimodal-looker only runs when look_at tool is explicitly called. The 5x usage @Razkaroth observed is puzzling - it should NOT be auto-invoked.

Possible explanations:

1. The main agent (Sisyphus) explicitly called look_at to analyze files
2. A custom Claude Code hook in ~/.claude/settings.json is invoking it
3. GitHub Copilot analytics may be counting differently than expected

3. Aggressive Auto-Triggering Hooks

Several hooks fire on EVERY message and can spawn agents:

Hook	Trigger	Risk Level
Keyword Detector	Words like "search", "find", "analyze", "investigate" (40+ patterns)	VERY HIGH
Todo Continuation	Session idle with incomplete todos	HIGH
Ralph Loop	/ralph-loop command	HIGH (if active)

Keyword Detector patterns that spawn agents:

• ultrawork, search, find, locate, explore, grep, analyze, investigate, examine, research, debug...
• Plus 20+ multilingual variants (Korean, Japanese, etc.)

If your prompt contained any of these words, it likely triggered additional agent spawning.

4. Model Persistence in Background Tasks

Background tasks store and inherit parentModel:

// src/features/background-agent/manager.ts lines 337-345
const modelField = modelContext?.providerID && modelContext?.modelID
  ? { providerID: modelContext.providerID, modelID: modelContext.modelID }
  : undefined

await this.client.session.prompt({
  // ...
  model: modelField,  // Inherits parent's model
})

Implication for @Razkaroth: If you changed your config to use Antigravity provider but had existing sessions or background tasks still running, they would continue using the old github-copilot/* model IDs until those sessions completed or timed out (30 min TTL).

---

Why Your Usage Spiked

Based on the task you described ("confirm if I have configured the Agent Skills correctly at the global level"):

1. Sisyphus analyzed the request and determined it needed exploration
2. Keyword detection likely fired on "confirm" + "configured" patterns
3. Multiple explore/librarian agents spawned in parallel to search:
   • Your config files
   • Agent Skills documentation
   • Related implementations
4. Each agent made multiple API calls via tools (grep, glob, context7, websearch_exa)
5. Todo continuation enforcer may have kept agents running until all todos completed
6. No rate limiting meant all this happened rapidly and concurrently

The ~9MB log file suggests the agents hit quota limits multiple times and kept retrying until they succeeded or timed out.

---

Recommendations

For @ujanjan and @Razkaroth:

1. Check for running background tasks before closing OpenCode:

   Use background_cancel(all=true) to stop all background tasks
   

2. Disable aggressive hooks if you want more control:

   {
     "disabled_hooks": ["keyword-detector", "agent-usage-reminder"]
   }

3. Use simpler agents for config verification instead of Sisyphus:

   @explore Check if Agent Skills are configured at ~/.config/opencode/
   

4. Monitor active sessions - background tasks inherit parent model and run for up to 30 minutes

For the codebase (potential improvements):

1. Add concurrency limits - cap at 10 concurrent background tasks per session
2. Add rate limiting - max 5 task spawns per 10 seconds
3. Add cost estimation - warn before spawning many agents
4. Better session cleanup - force stop all child sessions when parent closes

---

Questions for Further Investigation

1. @ujanjan - Did your prompt contain words like "search", "find", "explore", or "analyze"? This would trigger keyword detection.

2. @Razkaroth - Can you share your ~/.claude/settings.json file? A custom hook there could be invoking multimodal-looker.

3. Both - Are you using /init-deep or /ralph-loop commands? These spawn many agents by design.

---

Let me know if you need me to investigate any specific aspect further or if you'd like me to implement concurrency limits as a fix.

[ujanjan]

thanks for the investigation! this was the prompt that I used (retrieved from log):

use the internet to confirm if we have the correct setup for skills in opencode for global settings (not only for this project) https://agentskills.io/home

I didn't use /init-deep or /ralph-loop.

also not sure if related for investigation, I prompted Gemini 3 Pro to analyze the ~9MB log against the recent fix commit on OpenCode core: prevent TimeoutOverflowWarning, and here is the response:

I have analyzed the log file 2026-01-02T070352.log and found the specific mechanism that caused the usage spike.

1. The Trigger
   The task that triggered the spike was a request to Sisyphus (Claude Opus 4.5) to check global settings using an external URL:
   "use the internet to confirm if we have the correct setup for skills in opencode for global settings (not only for this project) https://agentskills.io/home"

2. The Mechanism of the Spike
   The logs show that immediately after the request was made, the system entered a rapid-fire retry loop. Between 07:05:06 and 07:05:24 (just 18 seconds), there were 100+ failed requests logged. It appears that once the GitHub Copilot API returned a 429 (Too Many Requests), the plugin attempted to retry the request immediately without backing off, causing a "retry storm" that hammered the API.

3. Log Evidence
   The log grew to 9MB because every single failed retry dumped the full request context (system prompt + history). Here is the pattern seen in the logs:

// First failure at 07:05:06 +62ms
ERROR 2026-01-02T07:05:06 +62ms service=llm ... error={"error":{"name":"AI_APICallError","url":"https://api.githubcopilot.com/chat/completions" ... "message":"Too Many Requests" ... }}

// Immediate retries (milliseconds later)
ERROR 2026-01-02T07:05:06 +4ms service=session.processor error=Too Many Requests ...
ERROR 2026-01-02T07:05:07 +1ms service=session.processor error=Too Many Requests ...
ERROR 2026-01-02T07:05:07 +41ms service=llm ...

4. Regarding the Fix
   I examined the code in the recent commit core: prevent TimeoutOverflowWarning (anomalyco/opencode@9a1dc1f) and can confirm it addresses the root cause. In Node.js, if you pass a delay larger than a 32-bit integer (approx 24.8 days) to setTimeout, it emits a warning and defaults the delay to 1ms (immediate execution).

The "Retry Storm" happened because:

1. The 429 error triggered a backoff calculation (either from a header or exponential math) that resulted in a number larger than 2.14 billion milliseconds.
2. Node.js treated this huge number as 1ms.
3. The system retried immediately, failed again, calculated the huge delay again, and looped instantly.

The fix Math.min(ms, RETRY_MAX_DELAY) ensures the delay never overflows, effectively stopping the infinite retry loop.

[justcarlson]

Additional Evidence: Librarian Agent Recursive Spawning Loop

Hit same issue today - 839MB log, 1.2M lines in 12min, rate limit exhaustion.

Versions: opencode 1.1.1, oh-my-opencode 2.12.3

Specific Root Cause Found

Librarian agent recursively spawns itself via call_omo_agent tool:

1. User asks to research MCP servers with [search-mode] MAXIMIZE SEARCH EFFORT
2. Main assistant spawns 3 librarian agents (background)
3. Each librarian classifies request as "TYPE D: COMPREHENSIVE"
4. Built-in librarian prompt requires 6+ parallel tool calls for TYPE D
5. Each librarian spawns 6+ MORE librarian agents via call_omo_agent
6. Exponential explosion: 3 → 18 → 108 → 648...

Evidence from Logs

403,202 permission evaluations (tool spam)
27,776 LLM API calls
Top sessions:
  ses_474713cd7: 1,329 librarian calls
  ses_47473789a: 1,238 librarian calls
  ses_474733f57: 1,152 librarian calls

Source of Problem

The librarian prompt is hardcoded in oh-my-opencode v2.12.3:

~/.config/opencode/node_modules/oh-my-opencode/dist/index.js

Contains:

## PARALLEL EXECUTION REQUIREMENTS
| TYPE D (Comprehensive) | 6+ parallel calls |

Tool 3: grep_app_searchGitHub(...)
Tool 4: grep_app_searchGitHub(...)
Tool 5: gh repo clone...
Tool 6: gh search issues...

Problem: No guard against librarian spawning librarian. Each spawned agent follows same instructions → infinite recursion.

Proposed Fixes

1. Prevent same-type spawning: agents can't spawn their own type
2. Agent depth limit: max 2-3 levels deep
3. Concurrency cap per agent type: max N librarians simultaneously
4. Budget warnings: estimate cost before spawning 6+ agents

Log file available if needed for debugging.

[dinhphieu]

Insane, it ate 1866 premium requests in 1.5 hours

[rukshan21]

oh-my-very-hungry. was using copilot for a whole month comfortably in vanilla opencode. and this happens in one prompt. guess i got too greedy

[s01cy]

had the same draining problem but with anthropic models - I have 20x plan and somehow one prompt consumed like 40% of 5 hour limit. had no clue why until I saw this issue, would be nice to at least have some detailed view of what is going on with tokens consumption, I've tried to check all the running agents details but it provided no answers what went wrong

[code-yeongyu]

tbh idk what can i do with this

[thuvasooriya]

from my limited time spent on analyzing the behavior, i think the way subagents are spawned or managed might've changed in either opencode or in this plugin. and i see spikes in requests only when new subagents are spawned and this plugin definitely has a bug in spawning subagents either due to misconfiguration or some sort of race condition causing it to spawn many subagents recursively causing the request spike.