# Llama 3.1 70B API access?

**URL:** <https://discuss.huggingface.co/t/llama-3-1-70b-api-access/177106>\
**Category:** Site Feedback\
**Created:** [June 23, 2026, 3:02pm UTC](https://discuss.huggingface.co/t/llama-3-1-70b-api-access/177106 "2026-06-23T15:02:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![temporarycaution](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@temporarycaution](https://discuss.huggingface.co/u/temporarycaution)\
**Post date:** [June 23, 2026, 3:02pm UTC](https://discuss.huggingface.co/t/llama-3-1-70b-api-access/177106/1 "2026-06-23T15:02:04Z")

</div>

I see “You have been granted access to this model” on the page for [Llama 3.1 70B](https://huggingface.co/meta-llama/Llama-3.1-70B), and the test widget works; but when I try to access it through a third-party app, or make a test API call through curl, I get the error “Model not supported by provider featherless-ai”. The same call works fine for other models. Why is that, and how can I access Llama outside the tester?

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [June 23, 2026, 10:22pm UTC](https://discuss.huggingface.co/t/llama-3-1-70b-api-access/177106/2 "2026-06-23T22:22:51Z")

</div>

There’s been a lot of confusion around how Inference Providers are supposed to be used:

* * *

I don’t think “You have been granted access to this model” necessarily contradicts “Model not supported by provider featherless-ai”.

The short version is:

| Check | What it means |
| --- | --- |
| “You have been granted access” on the model page | You have access to the gated model repo / weights / model page resources. |
| The browser widget works | Some provider/path available from the widget could run something for that page. It does not necessarily prove your third-party app is using the same provider, model id, task, token scope, or endpoint. |
| `Model not supported by provider featherless-ai` | The selected provider, here `featherless-ai`, may not currently expose the exact model id and task that your API call is asking for. |

So I would first check the **exact model id + provider + task** combination before debugging the token or curl syntax too much.

The quickest first check is the model search page with the Inference Providers filter:

[https://huggingface.co/models?inference\_provider=all](https://huggingface.co/models?inference_provider=all)

Then search for the exact model id and, if needed, narrow the provider filter to Featherless. If the exact model/provider combination is not listed there, changing the curl call probably will not make that provider serve the model.

Also, one subtle point: `meta-llama/Llama-3.1-70B` and `meta-llama/Llama-3.1-70B-Instruct` are not interchangeable.

- [`meta-llama/Llama-3.1-70B`](https://huggingface.co/meta-llama/Llama-3.1-70B) is the base/pretrained model.
- [`meta-llama/Llama-3.1-70B-Instruct`](https://huggingface.co/meta-llama/Llama-3.1-70B-Instruct) is the instruction-tuned/chat-oriented model.

If your third-party app is making chat-completion-style calls, I would first verify whether the **Instruct** variant is available through the provider you are trying to use, rather than assuming that access to the base repo means the provider can serve it through chat completions.

A practical order of checks would be:

1. Confirm the exact model id:

2. Check whether that exact model is currently exposed through Inference Providers:

3. If you are explicitly forcing Featherless, try not forcing it:

4. If it works with `auto` but fails with `featherless-ai`, that suggests a provider-specific availability/mapping issue, not a general Llama access issue.

5. Check the local client version if you are using Python:

6. If you still get the error, the useful info to post back would be:

> **Why this error can happen even when model access is granted**
>
> There are several separate layers here:
> 
> | Layer | Example | Failure mode |
> | --- | --- | --- |
> | Gated model access | “You have been granted access” | You can access the repo/model card/weights, but that does not guarantee a serverless provider is serving it. |
> | Inference Provider availability | model appears in provider mapping | The model may be available through one provider but not another. |
> | Exact model id | base vs Instruct | `Llama-3.1-70B` may differ from `Llama-3.1-70B-Instruct`. |
> | Provider-side id | provider alias | The provider may use a slightly different `providerId`. |
> | Task | chat completion vs text generation | The provider may support `conversational`/chat but not `text-generation`, or vice versa. |
> | Client version | `huggingface_hub` version | Older clients may not know about a newly added provider. |
> | Endpoint generation | old vs new router | Old examples may still use deprecated `api-inference.huggingface.co` paths. |
> 
> The docs describe Inference Providers as a Hub-integrated layer across model pages, widgets, SDKs, and HTTP clients:
> 
> - [Inference Providers documentation](https://huggingface.co/docs/inference-providers/en/index)
> - [Inference Providers on the Hub](https://huggingface.co/docs/hub/models-inference)
> - [Your First Inference Provider Call](https://huggingface.co/docs/inference-providers/en/guides/first-api-call)
> 
> The “first API call” guide starts by finding a model with the “Inference Providers” filter, then trying the widget, then moving from the widget to code. That is why I think the first diagnostic step should be “is this exact model currently exposed through an Inference Provider?” rather than “do I have access to the gated repo?”

> **How to check the provider mapping more precisely**
>
> The Hub API docs show a few useful checks.
> 
> List models served by a provider:
> 
> ```bash
> curl -s "https://huggingface.co/api/models?inference_provider=featherless-ai" | jq ".[].id"
> 
> ```
> 
> List models served by any provider:
> 
> ```bash
> curl -s "https://huggingface.co/api/models?inference_provider=all" | jq ".[].id"
> 
> ```
> 
> Check one model’s inference status:
> 
> ```python
> from huggingface_hub import model_info
> 
> for model_id in [
> "meta-llama/Llama-3.1-70B",
> "meta-llama/Llama-3.1-70B-Instruct",
> ]:
> info = model_info(model_id, expand="inference")
> print(model_id, "=>", info.inference)
> 
> ```
> 
> Check the provider mapping for one exact model:
> 
> ```bash
> curl -s \
> "https://huggingface.co/api/models/meta-llama/Llama-3.1-70B-Instruct?expand=inferenceProviderMapping" \
> | jq ".inferenceProviderMapping"
> 
> ```
> 
> The provider mapping is useful because it can show things like:
> 
> - `status`
> - provider-side model id / `providerId`
> - task, such as `conversational` or `text-generation`
> 
> Docs: [Hub API - Inference Providers](https://huggingface.co/docs/inference-providers/hub-api)

> **Base model vs Instruct model**
>
> This may be relevant here because the post mentions `Llama-3.1-70B`.
> 
> The model card for [`meta-llama/Llama-3.1-70B`](https://huggingface.co/meta-llama/Llama-3.1-70B) shows local examples using `/v1/completions` with a `prompt`, which is closer to text completion.
> 
> The [`meta-llama/Llama-3.1-70B-Instruct`](https://huggingface.co/meta-llama/Llama-3.1-70B-Instruct) model is the instruction-tuned/chat-oriented variant. Meta’s model card text says the instruction-tuned models are intended for assistant-like chat, while the pretrained models can be adapted for natural-language generation tasks.
> 
> So if the third-party app is a chat app, I would test the Instruct model id first.
> 
> Possible ids to compare:
> 
> ```plaintext
> meta-llama/Llama-3.1-70B
> meta-llama/Llama-3.1-70B-Instruct
> meta-llama/Meta-Llama-3.1-70B
> meta-llama/Meta-Llama-3.1-70B-Instruct
> 
> ```
> 
> The important part is not just whether one of these pages exists. The important part is whether the **exact id you pass to the router** is mapped to the **provider** and **task** you are using.

> **Provider selection: auto vs forcing Featherless**
>
> If you explicitly request Featherless, for example with a provider argument or a model suffix, the router should be understood as trying that provider path.
> 
> Examples:
> 
> ```python
> from huggingface_hub import InferenceClient
> 
> client = InferenceClient(
> provider="featherless-ai",
> api_key="<HF_TOKEN>",
> )
> 
> ```
> 
> or with the OpenAI-compatible router:
> 
> ```python
> from openai import OpenAI
> 
> client = OpenAI(
> base_url="https://router.huggingface.co/v1",
> api_key="<HF_TOKEN>",
> )
> 
> completion = client.chat.completions.create(
> model="some/model:featherless-ai",
> messages=[{"role": "user", "content": "Hello"}],
> )
> 
> ```
> 
> The Featherless provider docs show this suffix style in examples:
> 
> [Featherless AI provider docs](https://huggingface.co/docs/inference-providers/en/providers/featherless-ai)
> 
> For debugging, I would compare:
> 
> ```plaintext
> model="meta-llama/Llama-3.1-70B-Instruct"
> provider="auto"
> 
> ```
> 
> versus:
> 
> ```plaintext
> model="meta-llama/Llama-3.1-70B-Instruct"
> provider="featherless-ai"
> 
> ```
> 
> or:
> 
> ```plaintext
> model="meta-llama/Llama-3.1-70B-Instruct"
> 
> ```
> 
> versus:
> 
> ```plaintext
> model="meta-llama/Llama-3.1-70B-Instruct:featherless-ai"
> 
> ```
> 
> If `auto` works but `featherless-ai` fails, that points toward Featherless-specific availability, mapping, or task support.

> **Client version can change the symptom**
>
> There was also some version-dependent confusion around the rollout.
> 
> For example, this `huggingface_hub` issue shows `huggingface_hub==0.31.1` failing with:
> 
> ```plaintext
> ValueError: Provider 'featherless-ai' not supported.
> 
> ```
> 
> even though the model’s `inferenceProviderMapping` contained `featherless-ai` for `meta-llama/Llama-3.1-70B-Instruct`:
> 
> [ValueError: Provider ‘featherless-ai’ not supported. · huggingface\_hub #3064](https://github.com/huggingface/huggingface_hub/issues/3064)
> 
> The Featherless integration blog says:
> 
> ```plaintext
> Install or upgrade huggingface_hub to ensure you have version v0.33.0 or better
> 
> ```
> 
> Link:
> 
> [Featherless AI on Hugging Face Inference Providers](https://huggingface.co/blog/inference-providers-featherless)
> 
> So if you are using Python, I would at least check:
> 
> ```bash
> python -c "import huggingface_hub; print(huggingface_hub. __version__ )"
> 
> ```
> 
> and upgrade if it is old:
> 
> ```bash
> pip install -U "huggingface_hub>=0.33.0"
> 
> ```
> 
> But upgrading is not a guaranteed fix. It may simply move you from a “client does not know this provider” error to a more specific “this model/task/provider combination is not supported” error.
> 
> Related example:
> 
> [Inference providers seems to not be compatible with text\_generation · huggingface\_hub #3196](https://github.com/huggingface/huggingface_hub/issues/3196)

> **Task mismatch examples**
>
> Another common pattern is task mismatch.
> 
> For example, a model may be mapped as `conversational` / chat-completion style, while the app or wrapper tries to call `text-generation`.
> 
> Related forum example:
> 
> [ValueError: Model not supported for task text-generation - Llama-3.1-8B-Instruct with featherless-ai](https://discuss.huggingface.co/t/valueerror-model-not-supported-for-task-text-generation-llama-3-1-8b-instruct-with-featherless-ai/159970)
> 
> Related GitHub example:
> 
> [Inference providers seems to not be compatible with text\_generation · huggingface\_hub #3196](https://github.com/huggingface/huggingface_hub/issues/3196)
> 
> So if you are using a third-party app or LangChain-style wrapper, it is worth checking whether it is making a chat-completion call or a text-generation call.
> 
> Rough distinction:
> 
> | App/API behavior | More likely endpoint/task |
> | --- | --- |
> | `messages=[{"role": "user", ...}]` | chat completion / conversational |
> | `prompt="Once upon a time"` | text generation / completion |
> | old fixed URL like `api-inference.huggingface.co/models/...` | legacy Inference API pattern |

> **Legacy endpoint check**
>
> If your curl or third-party app is based on older examples, also check the endpoint.
> 
> Some older examples use:
> 
> ```plaintext
> https://api-inference.huggingface.co/models/<MODEL_ID>
> 
> ```
> 
> But current Inference Providers examples use the router, for example:
> 
> ```plaintext
> https://router.huggingface.co/v1/chat/completions
> 
> ```
> 
> or provider-specific router paths depending on the task/provider.
> 
> There are forum reports of the old `api-inference.huggingface.co` path returning a message like:
> 
> ```plaintext
> https://api-inference.huggingface.co is no longer supported.
> Please use https://router.huggingface.co/hf-inference instead.
> 
> ```
> 
> Related thread:
> 
> [{ error: ‘https://api-inference.huggingface.co is no longer supported…’ }](https://discuss.huggingface.co/t/error-https-api-inference-huggingface-co-is-no-longer-supported-please-use-https-router-huggingface-co-hf-inference-instead/169870)
> 
> This may not be your exact error, but it is another reason why copying an older curl example can lead to confusing results.

> **Minimal curl shape to compare**
>
> For an OpenAI-compatible chat-completions path, the general shape is:
> 
> ```bash
> curl https://router.huggingface.co/v1/chat/completions \
> -H "Authorization: Bearer <HF_TOKEN>" \
> -H "Content-Type: application/json" \
> -d '{
> "model": "meta-llama/Llama-3.1-70B-Instruct",
> "messages": [
> {
> "role": "user",
> "content": "Say hello in one sentence."
> }
> ],
> "max_tokens": 64
> }'
> 
> ```
> 
> Then compare with a provider-forced version only if the model/provider mapping says it is available:
> 
> ```bash
> curl https://router.huggingface.co/v1/chat/completions \
> -H "Authorization: Bearer <HF_TOKEN>" \
> -H "Content-Type: application/json" \
> -d '{
> "model": "meta-llama/Llama-3.1-70B-Instruct:featherless-ai",
> "messages": [
> {
> "role": "user",
> "content": "Say hello in one sentence."
> }
> ],
> "max_tokens": 64
> }'
> 
> ```
> 
> If the first works and the second fails, that is useful evidence that the issue is specific to the forced provider path.
> 
> If both fail, then I would check:
> 
> - token permissions / credits
> - gated model access for the exact model
> - exact model id
> - whether the model is listed under Inference Providers
> - whether the model is base vs Instruct
> - whether the app is using the correct endpoint

To summarize my guess: this is probably not “you do not have access to Llama” in the simple gated-repo sense. It is more likely one of these:

1. the exact base model id is not exposed by the selected provider,
2. the third-party app is forcing `featherless-ai`,
3. the app is calling the wrong task,
4. the local SDK is old,
5. or the provider mapping/catalog and the runtime availability are temporarily out of sync.

The first thing I would rule out is the non-fixable case: **is the exact model id currently available through the provider you are forcing?**