Deprecate virtual_key argument in chat_portkey()

[maciekbanas]

Fixes #786

[maciekbanas]

@shajoezhu would you like to test if the new solution works for your examples?

[hadley]

I wonder if it's too aggressive to immediately deprecate? Is there some other way we could tell if the user has opted in to the model catalog?

[maciekbanas]

I think you may be right. I will get back with a more gentle solution.

[maciekbanas]

@hadley I introduced new model_provider parameter next to virtual_key - though, it is also optional.

[maciekbanas]

It works now this way - if there is no model_provider (passed as empty character "") nor virtual_key, chat_portkey() still chats, if the given model, e.g. "gpt" is available in user's Portkey AI. It seems like defining model_provider is not necessary (but it probably depends on configs/settings used by different hosts).

If user passes proper model_provider, that he has got in his Model Catalog, chat_portkey() will work, if wrong model_provider will be passed (non-existing in Model Catalog), an error occurs. Technically, in Portkey, model provider can be passed through:

• body

curl https://api.portkey.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-portkey-api-key: $PORTKEY_API_KEY" \
  -d '{
    "model": "@openai-prod/gpt-4o",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

• or headers:

curl https://api.portkey.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-portkey-api-key: $PORTKEY_API_KEY" \
  -H "x-portkey-provider: @openai-prod" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello!"}]
  }

I applied second solution to ellmer (headers).

FYI @shajoezhu @hadley

[shajoezhu]

@shajoezhu would you like to test if the new solution works for your examples?

will do. thank you!

[shajoezhu]

lgtm! thanks @maciekbanas

tested all working!

[shajoezhu]

i think it is nice to have the deprecation option for the virtual_key, it seems that free account has not fully moved away from the virtual key?

[maciekbanas]

@shajoezhu you mean the public free account? Yes, they still use virtual keys, I am a bit confused. Still, in my solution, you can still pass virtual_key to chat_portkey().

[shajoezhu]

@shajoezhu you mean the public free account? Yes, they still use virtual keys, I am a bit confused. Still, in my solution, you can still pass virtual_key to chat_portkey().

hi @maciekbanas , yes, i agree with your solution. there is no problem here

[hadley]

@maciekbanas I took a slightly different direction because my reading on the portkey docs suggests that they want you to write @provider/model rather than supplying a model_provider separately. Take a look and let me know what you think.

[maciekbanas]

@hadley I think your solution is more clear - we need to specify a provider together with the model, as recommended by Portkey. If not, client tries to reach for a virtual key. I like it. Wonder what is @shajoezhu 's opinion. Joe, can you test it on your use cases?