feat(adapters): Support additional headers for OpenAI backend

[planetf1]

Which issue(s) does this pull-request address?

Closes: #532

Description

Adds support for OpenAI provider to add additional headers

export OPENAI_EXTRA_HEADERS='{"MY_API_KEY": "ab592c9f3e001b"}'

To test also set:

OPENAI_API_KEY=my-api-key
OPENAI_CHAT_MODEL=my-model
OPENAI_API_BASE=https://my-endpoint/
OPENAI_EXTRA_HEADERS={"MY_API_KEY": "ab592c9f3e001b"}

Currently draft - will be testing more

Note also that #527 may update some parameter values/usage to align more closely with typescript version

Tested ok

Checklist

• I have read the contributor guide
• I have signed off on my commit
• Linting passes: yarn lint or yarn lint:fix
• Formatting is applied: yarn format or yarn format:fix
• Unit tests pass: yarn test:unit
• E2E tests pass: yarn test:e2e
• Tests are included
• Documentation is changed or added
• Commit messages and PR title follow conventional commits

[vabarbosa]

thanks... just a couple comments. your thoughts are appreciated

[vabarbosa]

extra_headers is supported across multiple services, e.g.,

• https://docs.litellm.ai/docs/providers/anthropic#passing-extra-headers-to-anthropic-api
• https://docs.litellm.ai/docs/providers/bedrock#passing-extra-headers--custom-api-endpoints

to that end should this really be OPENAI_EXTRA_HEADERS and should it be in openai adapter? i would think we want this in the base LiteLLM adapter so it could be applicable across all adapters (and replace the OPENAI_ prefix with something less service specific)

[planetf1]

Yes, I'd agree - if we can do this at the litellm level it will be much more flexible

[vabarbosa]

LiteLLM also accepts extra_headers params:

so do we have to copy it over to headers? we end up with both headers and extra_headers in the _settings

[planetf1]

it probably should be extra_headers so that we just augment what is already there?

[planetf1]

I can look at this tomorrow to refactor to make more generic. (if urgent ok to merge than update after)

[Tomas2D]

I would say that more adapters will use it so I would extract it into a separate file (maybe utils/strings.py)

[planetf1]

Rather than adding multiple environment variables and managing precedence across inheritance, are we ok to just add a single one?

Previously we had OPENAI_EXTRA_HEADERS (in the above working code)

If this is set at the LiteLLM adapter level it might be LIGHTLLM_EXTRA_HEADERS

It might be more generic in future if we use BEEAI_EXTRA_HEADERS or BEEAI_LLM_EXTRA_HEADERS ... ? But the implementation would then differ, and potentially be incomplete.

My thought is to just have a single variable, to name it BEEAI_LLM_EXTRA_HEADERS, but only to implement it in LiteLLM adapter