gh aw does not correctly count sub-agent model usage or override isn't working

[ryckmansm]

Bug Report: gh aw does not correctly count sub-agent model usage

Summary

gh aw appears to attribute all token usage to the orchestrator model and does not break out usage for sub-agents invoked with explicit model overrides.

In my workflow Test Sub-Agent Models, three sub-agents were invoked with claude-haiku-4.5, but the audit output and token summary only report claude-sonnet-4.6.

Environment

• gh-aw CLI version: v0.77.5

Reproduction

1. Use a workflow with engine copilot and inline sub-agents configured with:
   • model: claude-haiku-4.5
2. Dispatch three sub-agents (agent-alpha, agent-beta, agent-gamma) with explicit model override claude-haiku-4.5.
3. Run the workflow.
4. Inspect audit output and artifacts:
   • run_summary.json -> token_usage_summary.by_model
   • sandbox/firewall/logs/api-proxy-logs/token-usage.jsonl
   • agent-stdio.log

Expected Behavior

• Either:
  • token/model accounting includes separate entries for sub-agent model usage (claude-haiku-4.5), or
  • audit clearly indicates that sub-agent model overrides were ignored/fell back and why.
• by_model should not imply only one model was used when sub-agents were dispatched with explicit different model overrides.

Actual Behavior

• Audit output reports only orchestrator model usage:
  • by_model contains only claude-sonnet-4.6
  • token-usage.jsonl entries all show model:"claude-sonnet-4.6"
• At the same time, sub-agent dispatch logs show requests with explicit override claude-haiku-4.5.

This creates a counting/attribution gap for sub-agent usage and makes model-level cost/perf analysis unreliable.

Evidence

1) Sub-agent dispatch indicates haiku override

From agent-stdio.log:

● Agent-alpha(claude-haiku-4.5) Get model name
● Agent-beta(claude-haiku-4.5) Get model name
● Agent-gamma(claude-haiku-4.5) Get model name

2) Audit by_model only has sonnet

From run_summary.json:

"token_usage_summary": {
  "by_model": {
    "claude-sonnet-4.6": {
      "provider": "copilot",
      "requests": 15
    }
  }
}

3) Raw token usage also only has sonnet

From sandbox/firewall/logs/api-proxy-logs/token-usage.jsonl:

{"event":"token_usage","provider":"copilot","model":"claude-sonnet-4.6", ...}

Impact

• Incorrect or incomplete model attribution in audit results.
• Misleading cost optimization decisions when sub-agents are intended to use cheaper models.
• Difficult to validate whether sub-agent model overrides are actually honored.

Requested Fix

1. Include sub-agent model attribution in token accounting and by_model aggregation.
2. If fallback/override is ignored, emit explicit machine-readable reason per sub-agent invocation.
3. Add an audit section like:
   • subagent_model_requests (requested/effective)
   • subagent_model_actuals (observed from token logs)
   • mismatch_count and reason codes.

Notes

• It may indicate an underlying runtime override problem, but even then the audit output should surface that mismatch explicitly.
• Potential regression signal: this behavior appears inconsistent with recent gh-aw guidance that sub-agent model: pins are honored in v0.77.4+.

test-subagent-models.md

[e6o]

Ran into a similar issue when trying to measure actual per-agent cost attribution in multi-model workflows. The root problem is that most agent frameworks conflate orchestrator + sub-agent usage into one bucket, which makes it impossible to answer "should this sub-agent even be on Sonnet?"

Two things that helped us:

1. Token attribution by model role: Tag each completion with the agent role (orchestrator/reviewer/coder) AND the model used. Then you can compute cost per role and see if, e.g., your review agents burning Opus tokens are actually producing better reviews than Haiku would.

2. Dynamic model assignment: Instead of hardcoding model overrides per sub-agent, route based on task complexity. Simple lint checks → Haiku. Architecture decisions → Sonnet/Opus. The cost difference is dramatic — we've seen 40-60% reductions when teams switch from "everything on one model" to tiered assignment.

For the gh aw audit specifically, the fix would need to propagate the model ID from the sub-agent's API call metadata into the parent workflow's token summary. Without that, you're flying blind on which agent tier is actually cost-effective.

(Full disclosure: I work on InferCut — we handle model routing/cost optimization for LLM API calls. This exact attribution problem is what we built for.)

[pelikhan]

@e6o what does your router need to execute? I am wondering whether we can have a hook to integrate this kind of tool. Do you support REST APIs with OIDC minted token?