Claude Code Hooks and Subagents on an Aggregator Key: Which Calls Hit Which Backend

Why this mapping matters

When you run Claude Code against an aggregator endpoint, a single "session" is rarely one request. The main loop calls the model repeatedly, hooks can spawn their own calls, and subagents run in separate contexts. On a pay-per-token key, each of those calls is billed independently, and it bills against whichever model the request names.

Understanding the shape of that traffic lets you route cheap work to cheaper models, keep expensive reasoning on stronger ones, and avoid surprises when you review usage.

The three layers of calls

Treat a Claude Code session as three layers:

• The main loop — the interactive or headless conversation. Every turn that needs a model response is one request.
• Hook-triggered calls — commands wired to lifecycle events. A hook is just a shell command; it only makes a model call if the command itself does, or if it instructs Claude Code to.
• Subagent invocations — delegated tasks. A subagent runs its own reasoning loop with its own context, so it produces its own request stream, separate from the parent conversation.

Only the first layer is automatic. The other two exist because you configured them, which means you control which backend they reach.

How the aggregator key fits in

You point Claude Code at the aggregator's base URL and authenticate with one API key. That key fronts multiple providers, so the model name in each request decides the backend and the price.

Practical consequences:

• Every request carries a model identifier. If nothing overrides it, requests inherit the default model configured for the session.
• Hooks and subagents that issue their own requests inherit that default unless you explicitly set a different model for them.
• Billing is per request against the resolved model. There is no single "session price."

On this platform, requests are charged at the official per-model price multiplied by 1.3, settled from your USDC balance on Base. That multiplier is uniform, so relative cost differences between phases come from which model each phase uses, not from a per-phase surcharge.

Which calls hit which backend

A useful mental model, layer by layer:

Main loop

Hits the model you launched with (the default). This is where most of your token spend usually lives, because it carries the full conversation context on each turn.

Hook-triggered calls

A hook fires on an event. Whether it produces a request depends on what the hook does:

• A hook that runs a linter, formatter, or shell test makes no model call — nothing is billed.
• A hook that invokes a CLI or script which itself calls the API makes a call against whatever model that script names, not the session default.
• A hook that feeds instructions back to Claude Code can cause the main loop to make an additional request against the session default.

So the rule is: a hook bills against the backend its command chooses, or against the session default if it re-enters the main loop.

Subagent invocations

A subagent is a delegated reasoning task. It makes its own requests and typically starts with a fresh, smaller context. It bills against the model configured for that subagent definition, or the session default if none is set. Because subagents often do bounded, lower-stakes work — searching, summarizing, isolated refactors — they are the natural place to route to a cheaper model.

A routing strategy that holds up

1. Keep a strong default for the main loop. Interactive reasoning benefits most from a capable model.
2. Route subagents deliberately. Set an explicit model on subagent definitions for narrow tasks. Many teams use a lighter model here because the task is scoped.
3. Audit hooks for hidden calls. Any hook that shells out to the API should name its model explicitly so it never silently inherits a pricey default.
4. Leave non-model hooks alone. Formatting and linting hooks cost nothing on the API side; don't over-engineer them.

Reading your usage after a session

Since each request is logged separately, you can reconstruct the map after the fact:

• Group usage by model name to see how spend splits between the main loop, subagent models, and hook scripts.
• Compare request counts to session length — a spike in requests usually means a hook is re-entering the loop or a subagent is iterating more than expected.
• Watch context size on main-loop requests; repeated full-context turns dominate cost even at a single model tier.

Common pitfalls

• Assuming hooks are free. They are free only if they don't call a model.
• Letting subagents inherit the default by accident. An unconfigured subagent runs on your most expensive setting.
• Hardcoding model names in hook scripts. Centralize them so a change in routing doesn't require editing every script.
• Forgetting the multiplier when budgeting. Every request — main loop, hook, subagent — is billed at official price × 1.3 against your USDC balance.

If you also contribute keys

If you supply an upstream key that the platform routes through, your contribution is credited at the official price × 1.1 (× 1.2 for premium tiers) in USDC. That credit flow is separate from what you pay as a caller; keep the two ledgers distinct when you reason about session cost.

Bottom line

One API key, many possible backends. The main loop uses your default; hooks use whatever their command names; subagents use whatever you configure for them. Set model choices explicitly at each layer, keep non-model hooks model-free, and review usage by model name to confirm the traffic landed where you intended.