Report the effective service tier after payload overrides in usage events

[seakee]

Problem

CLIProxyAPI usage events expose the service tier from the original client request and the tier reported by the upstream response, but they do not expose the effective tier after payload.default, payload.override, and protocol translation have been applied.

This makes the following requests indistinguishable to downstream usage consumers:

Request A: no override

• Client does not send service_tier.
• No matching override changes it.
• Recorded values:

{
  "service_tier": "auto",
  "response_service_tier": "default"
}

Request B: overridden to Priority

• Client does not send service_tier.
• payload.override changes the final outbound request to priority.
• Recorded values are still:

{
  "service_tier": "auto",
  "response_service_tier": "default"
}

Codex responses may report default even when Priority/Fast mode was selected in the request. Therefore, response_service_tier cannot be used to reconstruct the effective request tier.

Impact

Downstream monitoring and billing systems cannot determine whether the final outbound request used Priority/Fast mode.

For example, CPA Manager Plus may display auto and apply a 1× multiplier even though CLIProxyAPI changed the outbound request to priority and the request should be billed using the Fast multiplier.

Downstream context:

• fix(usage): bill Codex Fast from requested tier seakee/CPA-Manager-Plus#415
• fix(usage): bill Codex Fast from requested tier seakee/CPA-Manager-Plus#415 (comment)

Trying to reproduce CLIProxyAPI override evaluation in downstream applications is unreliable because the result can depend on:

• request headers;
• protocol;
• original payload fields;
• default and override rules;
• match ordering;
• protocol translation.

CLIProxyAPI is the only component that can reliably observe the final outbound request.

Expected behavior

Usage events should preserve three separate concepts:

{
  "service_tier": "auto",
  "effective_service_tier": "priority",
  "response_service_tier": "default"
}

Suggested meanings:

• service_tier: tier requested by the original client.
• effective_service_tier: tier present in the final outbound request after defaults, overrides, and protocol translation.
• response_service_tier: tier reported by the upstream response.

The effective tier should be extracted after all request transformations are complete and before the request is sent upstream.

Compatibility

effective_service_tier should be optional so existing SDK users, plugins, usage queues, and downstream consumers remain compatible.

When the final outbound protocol does not support a service tier or the effective value is unknown, the field may be omitted.

Relationship to existing issues

This is distinct from #4355.

Issue #4355 confirmed that the Codex response-side service_tier may remain default and should not be used to determine whether Fast Mode was requested. This issue asks CLIProxyAPI to expose the authoritative final request-side value so downstream consumers do not need to infer it from the response.

This is also distinct from #4189, which concerns service-tier metadata in the Interactions response translator. This issue concerns provider-independent usage-event accounting after payload overrides.

Acceptance criteria

• Usage events can expose the tier from the final outbound request.
• The value is captured after payload defaults, overrides, and protocol translation.
• Original, effective, and response tiers remain separate fields.
• Codex Priority/Fast requests remain identifiable even when the response reports default.
• The field is propagated through relevant SDK and usage queue representations.
• Existing consumers remain backward compatible.