feat: Client Versioning (+ Provider Trait and ClientBuilder)

[0xMochan]

• I have looked for existing issues (including closed) about this

Feature Request

As model providers start getting more competitive, the provider API routes might adjust and evolve over time. We should consider specifying a standardized versioning with clients (maybe via a builder or something) that helps in specifying how requests should be made to the API.

Motivation

Cohere recently released a v2 of it's chat endpoint.

Proposal

• A generic ClientBuilder can be defined to build out specific clients. That way, we can make the ClientBuilder as the singular interface for building all clients and agents.
• A Provider trait that helps simplify current and future provider implementation (specifically for top-level clients).
  • This should make it much easier for having different versioned clients since they'd share the same set of methods to make agents, extractors, etc.

impl Provider<V> for Client<V> {
    ...
}

impl Client<1> {
    pub fn completion ...
}

impl Client<2> {
    pub fn completion ...
}

Alternatives

Only support the latest version. Against this suggestion primarily because LLM and their providers are moving so quickly that many people might be building agents that could become dated in only a month. The providers leave older version endpoints operational so it would be a shame if someone's Agent stopped working due to a breaking change.

The only positive with supporting a latest version is that it simplifies the number of clients per providers but making a provider generic over a Version might be suitable for this.

[milancermak]

When I was looking through the source code, I've noticed that the way a completion request is created for Anthropic is not correct. It's modeled after the OpenAI API not the Anthropic one.

IIUC tackling this issue would resolve that, right? If so, could you provide a little bit more detail on how you envision the refactor? I could work on it if that's ok.