+1, we need this too, and for a slightly different reason that I think makes it even more basic than usage attribution.
We’re a self-hosted enterprise instance and all LLM access has to go through our company’s internal AI gateway. The gateway is OpenAI-compatible (/chat/completions), but it routes by a required request header that names the target model. Without that header every request is rejected with a 400, so today the Assistant can’t connect to it at all. The connection test in the “Connect a model” wizard fails on the missing header even with a valid key.
The funny part is that the rest of n8n already handles this fine. The OpenAI credential lets you set a custom header, so all our workflows (AI Agent + OpenAI Chat Model) run through the gateway without problems. Only the Assistant can’t, because its model setup is just base URL + API key + model name.
What would solve it for us, in order of preference:
-
Let the Assistant use an existing n8n credential (e.g. an OpenAI-type credential). That covers custom headers and credential rotation in one go. Our gateway uses short-lived OAuth tokens that we already refresh automatically inside an n8n credential, so a static key pasted into the Assistant settings would expire within a couple of days anyway.
-
Static custom headers for the Assistant’s model connection, in the UI and/or as an env var (something like N8N_INSTANCE_AI_MODEL_HEADERS taking JSON). Alex’s dynamic per-user headers would build on the same mechanism.