I requested access to the repo incorrectly and was rejected
I did not request access correctly and was rejected. Can you please reset so that I can request access again?
Same here
This happened to me as well. Does anyone have any info about why this happened? Or how I can gain access?
I received access to llama 4 models shortly after. Maybe access to v3 models is being restricted?
Please, I need a reset of the request, if possible to repeat the request with correct info, thanks
For those asking about API access — I've been using Crazyrouter as a unified gateway. One API key, OpenAI SDK compatible. Works well for testing different models without managing multiple accounts.
This is a pretty common issue with gated repos on HuggingFace — the access request flow can be a bit unforgiving if you submit before filling out the required fields properly, or if your HF account profile is incomplete when the request goes through. Meta's review process for Llama-3.3-70B-Instruct specifically tends to require that your account has a verified email, an organization affiliation, and that you've accepted the Llama 3.3 community license agreement on the model card page itself before submitting. If any of those were missing, the rejection is usually automatic rather than a human decision.
The good news is that a rejection here doesn't permanently block you. You can typically re-request access once you've corrected whatever was missing — just make sure your HF profile is fully filled out, your use case description is clear and non-trivial (vague entries like "research" without context get filtered), and that you've explicitly accepted the license terms on the model page before hitting request. It's worth double-checking that you're requesting under the correct account if you have multiple HF identities, since the approval is tied to a specific user token.
One thing worth noting if you're building automated pipelines or agent workflows around this model: access credentials and token management become genuinely important at scale. We've run into this in our own work on AgentGraph, where multiple agents or services need authenticated access to gated models and you have to be careful about which identity is making the request — a misconfigured agent hitting the access endpoint under the wrong token is effectively the same failure mode you hit manually. Getting the identity layer right from the start saves a lot of friction later.
This is a pretty common pain point with the Llama-3.3-70B-Instruct gating process. The rejection from an incorrect access request doesn't permanently block you — you can resubmit. The key thing to get right is that you need to be logged into HuggingFace with the account you actually intend to use for access, and you need to explicitly agree to Meta's Llama 3.3 community license terms on the model card page itself before or during the request. A lot of rejections happen because people submit the form without completing the license agreement step, or they're accidentally logged in as an org account rather than their personal account.
To resubmit, go back to the model page at meta-llama/Llama-3.3-70B-Instruct, make sure you're on the correct account, scroll to the gated access section, and go through the full flow again including the license acknowledgment. Meta's access approvals for this model are generally automated and fairly quick once the form is filled out correctly. If you're accessing the model programmatically via the Inference API or downloading weights for an agent pipeline, make sure the token you're using is scoped to the same account that was granted access — token/account mismatch is another common failure mode that surfaces as a permission error rather than a clear access-denied message.
One thing worth noting if you're building this into an automated or multi-agent workflow: access credentials tied to a specific HuggingFace account can become a fragile dependency, especially if multiple agents or services need to authenticate against gated models. This is actually a pattern we think about a lot in the AgentGraph work — when agents need to access credentialed resources, you want the identity and permission chain to be explicit and auditable rather than relying on a single shared token floating around your infrastructure. Worth thinking through that access model early if this is going into something more than a personal project.