Advisor consultations: apply the caller's paid-combo consent and device fallback policy #7859

Area

Proxy and routing

What are you trying to accomplish?

When an admitted request triggers an Advisor consultation, the consultation runs as an internal loopback request. #7718 makes that hop carry the originating caller's provider/model admission scope. I would like the same consultation to follow the originating caller's other routing policy as well, so that an Advisor consultation and a direct request from the same caller make the same routing decisions.

What prevents this today?

Two caller-level settings are evaluated against the internal hop's own admission rather than the originating request's:

• paid-combo consent (allowMeteredComboTargets on an API key, and the combo-level allowMeteredTargets opt-in), and
• device-scoped fallback policy (fallback.devices.<id>).

#7718 was intentionally narrowed to the model-scope part so it could land on its own.

What should OpenCodex do?

An Advisor consultation should apply the originating caller's paid-combo consent and device-scoped fallback policy together with the host's own limits, for every combo pick, nested decision turn, child invocation and fallback hop inside the consultation. If those rules leave no allowed destination, the consultation should return the existing "advisor unavailable" notice to the worker.

Example usage or interface

// config.json
{
  "apiKeys": [{ "id": "laptop", "allowMeteredComboTargets": false }],
  "fallback": { "devices": { "laptop": { "provider": false } } }
}

A request admitted with the laptop key that triggers an Advisor consultation should resolve the consultation's combo picks and fallback hops exactly as a direct laptop request would: no metered combo target and no provider fallback.

Alternatives or workarounds

A carried implementation existed on the #7718 branch (captured, immutable caller policy registered per consultation behind the internal-call capability) and was reverted to keep #7718 limited to model scope. It can serve as a starting point.

Additional context

Follow-up to #7718.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.