The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@julien-c I will close my PR and follow and build on your branch, thanks for the ping

I accidentally didn't checkout to a new branch when I made my changes (derived from your branch) @julien-c CLI tests are passing on my end, I can revert or not however you like! sorry

@merveenoyan it's fine 😄

@albertvillanova i think it's fine (maybe better) if the name is kinda generic and does not reference HF explicitly, given one of the goals is precisely:

make the name less HF-centric, given the actual inference is (most of the time) not performed by HF directly

let me know if this makes sense!

Thanks for the clarification, @julien-c.

Let me try to explain my point a bit better. My concern is that the name InferenceClientModel is so generic that it might be confusing to users, especially when thinking about other inference-client-style models.

For instance, LiteLLMModel also fits that description: it uses a client to request models and supports multiple providers like OpenAI, Anthropic, Hugging Face, Anyscale, etc. So from a user perspective, InferenceClientModel could easily be interpreted as referring to something like LiteLLMModel.

My question is: shouldn't we aim for a name that more clearly distinguishes our inference-client model from other similar inference-client models (like LiteLLM), to avoid ambiguity?

We have discussed this internally with @julien-c on Slack .
I agree that the name InferenceClientModel, in the sole context of smolagents, could lead to some confusion : what about other Inference clients like LiteLLM, does this class wrap them?

But in the broader context of the Hub + smolagents, this renaming makes sense.
We will probably have many users coming to smolagents from the Hub, so having Hub expectations like "Hub has this great portal named Inference Providers" (and Julien said that "Inference Client" is going to get pushed a lot in coming months), for users with these priors, the name InferenceClient* makes sense.
Maybe we could make it even clearer for any context, like HubInferenceModel, WDYT @julien-c ?
But else, for me the name InferenceClientModel works.

(leaning towards InferenceClientModel as well for consistency with the existing naming in our ecosystem)

@albertvillanova it's a bit philosophical and i agree the name is generic but we can't change it now as we've strongly pushed InferenceClient in both our Python and JS SDKs.
That being said we also have libraries named "datasets" and "transformers" 😁

I think InferenceClient especially with inference providers is sticking to users, so I wouldn't worry about confusion around it given we have documentation in smolagents (also you can't use it without documentation properly, so I don't think there'd be confusion)

One failing test @julien-c : FAILED tests/test_models.py::TestHfApiModel::test_init_model_with_tokens - TypeError: object.__new__() takes exactly one argument (the type to instantiate)