Subagent models are ignored when using GitHub Copilot provider — All Premium Requests billed to orchestrator model (Claude Opus 4.6) #20859

Activity

1. berrujaime

   added

   bugSomething isn't workingSomething isn't working

   on Apr 3, 2026
2. github-actions

   assigned

   rekram1-node

   on Apr 3, 2026
3. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   windows

   on Apr 3, 2026
4. github-actions commented on Apr 3, 2026

   

   github-actionsBot

   on Apr 3, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [Bug] Model parameter ignored when launching subagent with agent name #18615: [Bug] Model parameter ignored when launching subagent with agent name — reports that when an agent name is specified, the explicitly configured model is overridden by the agent's built-in fallback chain, which is very similar to subagent models being ignored
   • Desktop App Consuming Separate Premium Requests Per Subagent (GitHub Copilot Provider) #16937: Desktop App Consuming Separate Premium Requests Per Subagent (GitHub Copilot Provider) — related issue about GitHub Copilot billing discrepancies with subagents

   If your issue is distinct from the above (e.g., the billing attribution specifically rather than model selection), please clarify the difference.
5. berrujaime commented on Apr 3, 2026

   

   berrujaime

   on Apr 3, 2026

   Author

   More actions

   This issue is not a duplicate of the two mentioned.

   #18615 is about the model parameter being ignored when launching a subagent by agent name (it falls back to the agent's built-in chain). In my case, the subagents are correctly using the models I configured. I can confirm this with opencode stats --models, where I see messages and tokens being consumed on Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro, etc.
   #16937 is about the Desktop App consuming separate premium requests per subagent (higher total usage). My issue is different: it's about billing attribution.

   Actual problem:
   Even though OpenCode internally executes the subagents with their configured cheaper models, all Premium Requests (300 in my case) are being billed by GitHub Copilot exclusively to the orchestrator's model (Claude Opus 4.6). In the GitHub Copilot usage CSV, the other models show 0 requests.

   In short:

   Model selection works correctly at runtime.
   Billing attribution fails with the GitHub Copilot provider: everything is charged to the expensive main agent model.

   Can this be reviewed by the team? It appears there is an issue with how the model is passed to the GitHub Copilot API when using subagents in "subagent" mode.
6. gndk commented on Apr 4, 2026

   

   gndk

   on Apr 4, 2026

   More actions

   Subagents should not consume any additional requests at all since they are not user requests. Which is also the behaviour I see when using the same model for subagents. Maybe your mismatch actually is caused by the model switch in subagent config?
7. berrujaime commented on Apr 4, 2026

   

   berrujaime

   on Apr 4, 2026

   Author

   More actions

   Subagents should not consume any additional requests at all since they are not user requests. Which is also the behaviour I see when using the same model for subagents. Maybe your mismatch actually is caused by the model switch in subagent config?

   No, it's not caused by a model switch.
   When I configure subagents with different/cheaper models (Claude Sonnet 4.6, GPT-5.4, Gemini, etc.), they internally use those models correctly. I can clearly see this in opencode stats --models, with thousands of input/output tokens consumed on the cheaper models.
   However, in the GitHub Copilot usage CSV, all premium requests (hundreds) are still attributed only to the orchestrator model (github-copilot/claude-opus-4.6). The other models show 0 requests.
   When all subagents use the same model as the orchestrator, billing works fine (only 1 premium request). The problem only appears when using different models in subagents.
   This looks like a billing attribution issue with the GitHub Copilot provider when model switching is used in subagent mode.
8. kendotpm commented on Apr 13, 2026

   

   kendotpm

   on Apr 13, 2026

   Last edited by kendotpm

   More actions

   However, in the GitHub Copilot usage CSV, all premium requests (hundreds) are still attributed only to the orchestrator model (github-copilot/claude-opus-4.6). The other models show 0 requests.

   That's exactly how github copilot bills.

   If you try the reverse (free orchestrating to premium), you won't see any premium usage increases. For how long I don't know, its been patched out of VS and CLI when you go this reverse direction.

   If you were to parallelize your sub-agents as full-blown agents and have your orchestrator shipping messages to them as new sessions (not via the task tool, just straight up non-interactive bash calls), you'd see all that usage pile up in Github billing.

   @gndk's first sentence is accurate. Emphasis mine:

   Subagents should not consume any additional requests at all since they are not user requests.

   ---

   Orchestrators don't save you requests, they save you context so your smart orchestrator can keep everything together while your cheaper coders / reviewers don't clog up the orchestrator's context (particularly important on copilot's miniscule context sizes).

   Here's Opus explaining how the copilot plugin is instrumented in opencode.

   ---

   Two-Layer System

   The plugin lives at packages/opencode/src/plugin/copilot.ts in the OpenCode monorepo.

   Layer 1 — Fetch wrapper (runs on every API call)

   Parses the request body to determine x-initiator:

   • OpenAI format: isAgent = last.role !== "user" — if the last message is a tool result (role "tool") or assistant, it's agent-initiated
   • Anthropic format: isAgent = !(last.role === "user" && hasNonToolCalls) — special handling for mixed content (tool_result + text in same message)
   • Parse failure: defaults to "user" (conservative — may overcount)

   Layer 2 — chat.headers plugin hook (runs before fetch, can override)

   Three cases:

   1. Compaction request → forces x-initiator: "agent" (free)
   2. Sub-session (has parentID) → forces x-initiator: "agent" (free)
   3. Neither → does NOT set header (defers to Layer 1)
      Plugin output spreads AFTER fetch-level, so the plugin hook wins when it sets a value.

   The Agent → Subagent Chain for 0x orchestrator → 3x subagent.

   User prompt
     → Orchestrator session (parentID = NULL)
         → Fetch wrapper: last.role = "user" → x-initiator: "user"
         → Plugin hook: no parentID → no override
         → RESULT: BILLED at model multiplier (0× for GPT-4.1)
   
     → Orchestrator calls Task tool → spawns subagent session (parentID = orchestrator's sessionID)
         → Every API call in subagent:
             → Fetch wrapper: would set "user" or "agent" based on message roles
             → Plugin hook: parentID IS SET → forces "agent" (overrides fetch wrapper)
             → RESULT: FREE — always, regardless of model or message role
   

   The parentID check is the mechanism that makes subagent calls unconditionally free. It doesn't matter what model the subagent uses or what the message roles look like — if parentID is set, the plugin forces "agent" and billing never sees it.

   Edit: formatting
9. thdxr

   removed

   bugSomething isn't workingSomething isn't working

   windows

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on May 3, 2026
10. thdxr

    assigned

    nexxeln

    and unassigned

    rekram1-node

    on May 3, 2026
11. gauravlochan commented on Jun 2, 2026

    

    gauravlochan

    on Jun 2, 2026

    More actions

    That's exactly how github copilot bills.

    The parentID check is the mechanism that makes subagent calls unconditionally free. It doesn't matter what model the subagent uses or what the message roles look like — if parentID is set, the plugin forces "agent" and billing never sees it.

    @kendotpm That is so strange. So the fix would have to come from GitHub?
12. github-actions commented on Aug 2, 2026

    

    github-actionsBot

    on Aug 2, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
13. github-actions

    closed this as not plannedon Aug 2, 2026