Use case
When using engine: copilot with a BYOK custom provider (COPILOT_PROVIDER_BASE_URL pointed at an OpenAI-compatible gateway such as OpenRouter), a single agentic run fans out into many LLM calls. Providers increasingly expose native, per-request observability keyed off request metadata:
- OpenRouter groups requests sharing a
session_id (request body) or x-session-id header into its Logs → Sessions view ("track multi-step agents"), and uses it as a sticky-routing key for better cache hits. It also splits usage by app via HTTP-Referer / X-OpenRouter-Title and by user.
- Similar story for Helicone (
Helicone-Session-Id / Helicone-User-Id), etc.
Today a gh-aw workflow has no way to set any of these on the requests the Copilot engine makes to the BYOK provider, so an operator running many workflows can't tell which provider-side calls belong to which run/flow, nor group one run's calls together in the provider's own dashboard.
Current state
The Copilot engine BYOK surface is limited to four env vars — COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_API_KEY, COPILOT_PROVIDER_TYPE, COPILOT_MODEL (GitHub docs). There is no knob for custom request headers or for a session/user identifier.
Note the AWF apiProxy path doesn't help here: BYOK to a custom provider currently requires sandbox.agent: false (the apiProxy strips BYOK auth — see #20590), which bypasses the proxy, so apiProxy-level header work like #35192 does not apply to this flow.
Ask
A frontmatter knob on engine: to forward custom headers (and/or a session/user id) to the BYOK provider request, e.g.
engine:
id: copilot
env:
COPILOT_PROVIDER_BASE_URL: https://openrouter.ai/api/v1
COPILOT_PROVIDER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
headers:
x-session-id: ${{ github.run_id }} # or auto-populated, see below
x-openrouter-title: my-workflowEven better: gh-aw could auto-populate a provider session/user id from data it already models — forward gh-aw.episode.id as x-session-id (one episode = parent run + dispatched child workflow_calls, exactly a "session") and gh-aw.run.actor as user. This is the provider-request analogue of what #33640 did for Langfuse via OTEL spans, so any BYOK provider's native dashboards group a run's calls with zero per-workflow config.
Why this is general
Implementation note
Copilot CLI BYOK today honors only the four COPILOT_PROVIDER_* vars, so realizing this may require either (a) a Copilot CLI passthrough for extra request headers, or (b) gh-aw routing BYOK traffic through a thin header-injecting proxy. Flagging that the fix may span gh-aw + Copilot CLI.
Use case
When using
engine: copilotwith a BYOK custom provider (COPILOT_PROVIDER_BASE_URLpointed at an OpenAI-compatible gateway such as OpenRouter), a single agentic run fans out into many LLM calls. Providers increasingly expose native, per-request observability keyed off request metadata:session_id(request body) orx-session-idheader into its Logs → Sessions view ("track multi-step agents"), and uses it as a sticky-routing key for better cache hits. It also splits usage by app viaHTTP-Referer/X-OpenRouter-Titleand byuser.Helicone-Session-Id/Helicone-User-Id), etc.Today a gh-aw workflow has no way to set any of these on the requests the Copilot engine makes to the BYOK provider, so an operator running many workflows can't tell which provider-side calls belong to which run/flow, nor group one run's calls together in the provider's own dashboard.
Current state
The Copilot engine BYOK surface is limited to four env vars —
COPILOT_PROVIDER_BASE_URL,COPILOT_PROVIDER_API_KEY,COPILOT_PROVIDER_TYPE,COPILOT_MODEL(GitHub docs). There is no knob for custom request headers or for a session/user identifier.Note the AWF apiProxy path doesn't help here: BYOK to a custom provider currently requires
sandbox.agent: false(the apiProxy strips BYOK auth — see #20590), which bypasses the proxy, so apiProxy-level header work like #35192 does not apply to this flow.Ask
A frontmatter knob on
engine:to forward custom headers (and/or a session/user id) to the BYOK provider request, e.g.Even better: gh-aw could auto-populate a provider session/user id from data it already models — forward
gh-aw.episode.idasx-session-id(one episode = parent run + dispatched childworkflow_calls, exactly a "session") andgh-aw.run.actorasuser. This is the provider-request analogue of what #33640 did for Langfuse via OTEL spans, so any BYOK provider's native dashboards group a run's calls with zero per-workflow config.Why this is general
Implementation note
Copilot CLI BYOK today honors only the four
COPILOT_PROVIDER_*vars, so realizing this may require either (a) a Copilot CLI passthrough for extra request headers, or (b) gh-aw routing BYOK traffic through a thin header-injecting proxy. Flagging that the fix may span gh-aw + Copilot CLI.