Hello, I made two top-ups of $10 each today, October 29th, but I’m unable to use them for my projects. The chat feature works for two of my projects, but for the other two, the following message appears: "Sorry, something went wrong. Please try again."
Hmm… if you’re referring to HuggingChat Omni, I wonder if the October 30 fix might be relevant
:
There was a temporary fix for a live HuggingChat production problem on October 30, 2026. A maintainer reported that some DeepSeek Flash requests were routed to a provider that rejected the configured output-token limit. The temporary configuration change was merged that day, with successful tests reported for the adjusted setting.
It might be related, but it doesn’t establish what happened to your two failing projects. We don’t yet know whether you’re using HuggingChat Omni, which models are involved, or whether the error is still happening. That same message can appear for different reasons, including a failed inference request, an issue with a particular conversation, or a problem in another application.
The lowest-effort route I’d suggest:
- See whether it has recovered. If you’ve already tried since October 30, there’s no need to repeat the test. Otherwise, if you’re comfortable with a potentially billable request, one short, non-sensitive message in one affected chat is enough for a first check.
- If it works now, you can carry on without changing or deleting anything. The timing might fit a temporary service issue, but it wouldn’t prove which fix helped.
- If it still fails, the most useful distinction is what you mean by the four projects: conversations in HuggingChat, separate Hugging Face Spaces, or chat features in another application. Each points to a different, fairly simple comparison, outlined below.
- If you see a specific credit, spending-limit, or permission error, that’s a separate clue. The Inference Providers settings and billing documentation may help, but the generic popup alone does not say that your two $10 top-ups were insufficient or lost.
I wouldn’t top up again, delete the original work, reset a Space, or change a spending limit just to see whether the message goes away. The fact that two work and two don’t is already a useful starting point.
The optional sections below give the possible branches and sources in more detail; none requires you to carry out every check.
A small, safe comparison if the problem continues
The first split matters more than the popup
The message Sorry, something went wrong. Please try again. does not identify the component that failed. Two working projects show that some requests are succeeding; they cannot establish that all models, providers, conversations, or billing paths are healthy. A completed top-up also does not guarantee that every subsequent inference request will succeed.
Comparing one working and one failing project is usually enough. Reuse any results you’ve already seen, keep their contents intact, and change only one variable if another test is worthwhile. The goal is to understand the difference, not generate a long list of new checks.
A practical decision tree is:
Does the previously failing chat now work?
Yes:
Continue your work; keep the date of recovery as context.
Do not assume a specific PR caused the recovery.
No:
Are these HuggingChat conversations?
Fresh chat works; existing chat fails:
Check saved conversation state, history length, and options.
Model A works; model B fails:
Compare model/provider path and request limits.
Both fresh and existing chats fail:
Check mode, model, service state, and any safe error details.
Are they separate Spaces?
Compare the working and failing deployments, their runtime
status, application logs, and required configuration.
Are they in another application?
Identify that application's chat backend and billing identity.
Is there a specific billing/limit/permission response?
Investigate that response under the account actually billed.
If these are HuggingChat conversations and a test is appropriate, Please reply with one sentence is enough to check a basic text-only request. There is no need to copy private project material or credentials into a new chat. If a fresh chat works with the same selected model while an existing one fails, its history, state, or options deserve attention. The two chats may still differ in context size, tools, or routing; this is a clue, not proof that the old conversation is damaged.
If model selection is available, compare the same short prompt with a working and a failing model. Differences can implicate model, provider, request parameters, or feature routing, not universal model unavailability. An automatic mode’s visible model label may not identify its complete upstream route.
Also distinguish when it fails. An immediate error before any tokens arrive is different from a response that starts streaming and then stops, or a conversation that remains indefinitely in a generating state. Attachments, images, tools, and a very long history can use different paths or constraints from plain text. If the failing examples have those features, that fact is more useful than repeatedly refreshing the page.
How to read a small result
| Observation | Useful next branch | What it does not establish |
|---|---|---|
| The old project now works | Temporary outage or recent configuration/deployment change | That PR #2742 was the precise cause |
| Fresh chat works, old chat fails | History, stored turn state, or per-chat options | That the old data is permanently lost |
| One model works, another fails | Model/provider/route-specific acceptance or availability | A general outage for all users of that model |
| Text works, but an image or tool request fails | Feature-specific request path and capabilities | A problem with all plain conversations |
| A Space loads but sending a message fails | Application-to-inference request boundary | That the Space build itself failed |
A clear 403 says a spending limit was exceeded |
Effective usage cap and billing identity | That no purchased credit remains |
| Only a reload appears to change the result | Transient state, connection, or request timing | That browser cache was the root cause |
A single comparison or even just the project type and approximate failure time is sufficient for a useful first follow-up. You don’t need an SDK, a network capture, repeated paid requests, or a rebuild. Changing many settings at once would make the result harder to interpret.
What the October 30 fix does, and does not, explain
A documented production issue, not just an error-message match
The strongest time-specific clue is Hugging Face’s merged PR #2742, titled Temp fix: cap DeepSeek Flash max_tokens at 32768 in prod. The maintainer described it explicitly as a temporary fix for a live production outage. This is stronger evidence than an older report containing the same generic error message: it documents a specific production failure and a specific change.
In the reported incident, the router’s default provider selection began sending certain DeepSeek Flash requests to Scaleway. That provider rejected a max_tokens setting above 32768 with HTTP 400 and a validation message saying the completion-token limit was 32768. The production configuration had specified 49152 for those models. The PR reduced the value to 32768 for:
deepseek-ai/DeepSeek-V4.1-Flash-1017deepseek-ai/DeepSeek-V4-Flash-0731
The maintainer reported HTTP 200 tests with the adjusted setting on default routing, Scaleway, Novita, and Baseten. The PR was merged on October 30, 2026. The repository at the commit inspected during this investigation records the production configuration change in chart/env/prod.yaml.
The PR also specifically discusses Omni’s use of the affected DeepSeek route for tools and multimodal requests, and explains that even an apparently ordinary chat message could fail. So a user did not necessarily need to enter a huge prompt or manually request a very long answer to encounter the issue. This is why the fix is worth mentioning in a reply about chat failures reported at almost the same time.
The missing link is your actual request: the post doesn’t give a model/provider route, an HTTP 400, or the validation text. The PR neither shows a problem with your purchased credit nor proves that either failed project used the affected route. A merge and a successful test are also not the same thing as your own instance recovering.
Why the token limit can reject a very short message
An output-token setting is typically an upper bound requested by the client, not the number of tokens the server will certainly generate. A user might send Hi, while the application asks an upstream provider to permit a much larger possible completion. The provider can validate that requested upper bound before generating anything. If the configured number exceeds the limit accepted by that route, the request may be refused immediately, even though the eventual answer would have fit in one sentence.
A simplified path is:
Chat message submitted
Chat UI builds a request, including model and output settings
Router chooses an inference provider
Provider validates the request
Supported parameters: the reply can begin
Unsupported upper limit: the request is rejected before generation
User may see a generic failure message instead of the provider detail
This is a request-contract mismatch. It is different from running out of purchased credits, a conversation having too many input tokens, a provider taking too long to answer, or the user intentionally asking for more than 32,768 generated tokens. Those different problems can share the same outer symptom, but the useful fix and the evidence needed are different.
If some projects use one model/provider/parameter combination and others use a different one, a partial failure could result even under the same account. That is one possible explanation for the two-versus-two pattern, not a finding about your specific projects.
Model, provider, and mode are separate decisions
The HuggingChat Omni announcement introduced automatic routing across models. The Inference Providers documentation describes how model access can be routed through different providers. Consequently, a visible model name is not always the whole execution path; the upstream provider and effective options can matter just as much as the label in the interface.
The Omni announcement describes the product in 2025, not your 2026 request trace. The router documentation and code at the inspected October 30 commit show possible routes, not the route your account actually took.
The code also does not imply universal fallback: some paths try other candidates, while direct feature paths and errors during streaming can behave differently. A suitable alternative must exist in the first place.
A small model/mode comparison is therefore more informative than an outage banner alone. Plain text working while image or tool calls fail is useful evidence, but an alternative model need not be equivalent for your task.
What would strengthen or weaken this particular lead?
A closer match would involve confirmed HuggingChat Omni usage and a redacted 400 mentioning completion-token limits, a relevant DeepSeek route, or recovery after the change without altering the project or billing. Timing alone still cannot prove causation.
A failed Space build, missing payment, or explicit spending-limit 403 points elsewhere. A general 400 without its explanatory text could also have another cause. Product, request stage, timing, and a safe error summary matter together.
The maintainer called the adjustment temporary: a provider-aware limit or routing rule could preserve higher limits where supported. This is background about the fix, not a reason to change your project settings.
Merge, rollout, and your recovery are distinct milestones. The PR documents a merge and tests, not account-level recovery. The status page provides broad context but may not reflect a narrow model/provider issue. Your before/after result would be more directly relevant.
If the four projects are separate Spaces or third-party apps
First check which system actually owns each chat
If your four projects are separate Hugging Face Spaces, or four deployed applications with their own chat windows, the diagnosis changes substantially. A Space can run its own app and call HF Inference Providers, a dedicated endpoint, a model hosted within the Space, or an external API. A familiar-looking chat interface is not enough to establish that it uses the hosted HuggingChat Omni deployment.
PR #2742 changed the hosted app’s configuration, not your independent Space. A separate app could have a similar kind of provider parameter error without sharing that fix.
The official Spaces overview describes Spaces as separately configured repositories and applications with their own runtime environment. If the projects live in another company’s product, identify that service’s backend and billing arrangement before applying HF-specific troubleshooting. Two apps may use the same public model while paying different providers or sending requests under different credentials.
Compare one working deployment with one failing one
For separately deployed apps, compare the smallest relevant difference, preferably from existing logs rather than by repeatedly provoking failures:
- Runtime and build state. Does the failing app load? Is the Space running, building, sleeping, or showing a startup error? A build failure occurs before chat inference can be evaluated.
- Failure stage. Does the page fail to render, does clicking Send fail immediately, or does an answer begin and stop midway? A running interface can still have a broken inference call.
- One relevant log entry. Look around a known failure time for a backend exception, an upstream HTTP status, a missing configuration key, or a timeout. Redact sensitive data. A line that distinguishes request validation from authorization is usually more useful than pages of unrelated build output.
- Configuration categories. Are required variable and Secret names configured in both environments? Are the model, endpoint, application revision, and billing identity equivalent? Do not publish Secret values, tokens, request authorization headers, or private environment dumps.
- Only if indicated by logs, inspect runtime resources, dependency versions, or a deployment-specific permission. Hardware upgrades and rebuilds do not fix a provider rejecting unsupported API parameters.
A private comparison note might be:
Working project:
page loads: yes
chat request begins: yes
selected model/backend: [public label if visible]
last known success: [time and timezone]
Failing project:
page loads: yes/no
chat request begins: yes/no/unknown
first relevant error: [redacted status and message]
last failure: [time and timezone]
Difference worth checking:
[runtime, request route, Secret presence, app revision, or billing]
This is not a request to publish private deployments. A public reply can simply say whether both Spaces run and which one reaches its model; private URLs and logs should remain private.
A specific issue with duplicated Spaces
There is a useful distinction in the Spaces documentation on Variables, Secrets, and duplication: public Variables may be carried over, but Secrets are not copied into the duplicated Space automatically. This can create two projects with similar code and very different behavior if an authentication key or private backend setting is needed only in one of them.
That is worth checking if two of the projects were created by duplication or use a shared template. Check the presence of the required Secret by name in each Space’s settings, without revealing its value. If a required credential is genuinely missing, configure it through the private settings using the proper permissions. Do not paste it into a forum message, a public repository, a screenshot, or application logs.
The same caution applies to other differences: distinct app revisions, a backend URL, selected provider, optional image/tool support, or an organization billing identity could produce a partial failure pattern. Those are possibilities conditional on the app setup, not evidence that any of your four projects has been misconfigured.
Keep the working examples intact
A Space page can load while its inference request fails; the last successful step is more useful than calling the whole deployment broken. For now, I would leave the two working projects as a comparison and avoid resets, hardware upgrades, forced dependency updates, or bulk rebuilds. If logs eventually justify a reversible change, record the old setting and test one deployment at a time.
For an external app, the same principle applies: establish which service sends the request and whose account is billed. Credits on a personal HF account do not necessarily pay for calls made under another organization or a provider’s own API key. Only the service or account owner can verify private request traces.
If the two top-ups, credits, or spending limits are involved
Payment, available credit, and successful inference are different checks
You mentioned two $10 top-ups, so it is important not to dismiss the possibility of a billing problem. But the observation that chat works in two projects and fails in two does not, by itself, show that either payment was lost, that the account balance is zero, or that more money is required. A request may be admitted or rejected for reasons separate from payment, and two projects might even use different billing identities or providers.
It helps to separate four questions:
- Payment record: were both transactions completed and recorded under the intended HF account?
- Applicable credit: does that account show credit available for the service making the failed request?
- Admission and limits: does the effective spending cap, authorization, or rate policy permit the request under its actual billing identity?
- Inference execution: once admitted, can the model/provider accept the parameters and produce an answer?
A visible balance, a spending-limit 403, and a provider-validation 400 are different observations. The specific error matters more than the generic popup.
The current Inference Providers pricing and billing guide explains both purchased credits and different billing methods. In particular, requests routed and billed through Hugging Face differ from requests using a custom provider key and billed directly by that provider. For supported organization-based billing, the organization being charged also matters. This is mainly relevant if the four projects are independent apps or use different accounts; someone simply chatting through a personal HuggingChat session need not investigate API-level billing headers first.
Only follow the billing branch when there is a clue
If the failing request gives an explicit payment, credit, 402, spending-limit 403, or related authorization message, the relevant Inference Providers settings page is a sensible next stop. Check which account is signed in, whether the expected purchased credit is visible, and whether an applicable usage limit is configured. If an organization or custom provider key is involved, identify that billing path before drawing conclusions from the personal balance.
The wording matters. Not every 403 is a billing error, and not every 429 is a purchased-credit issue. Access restrictions, provider policy, and quotas can cause superficially similar rejections. If the message mentions an effective spending limit specifically, that is much stronger evidence for this branch than the generic chat popup.
There is a relevant but separate August 2026 HF Forum example: a user reported remaining credits while HuggingChat returned an explicit 403 indicating the monthly Inference Providers spending limit had been exceeded. After HF staff suggested adjusting the limit, the user reported that chat worked again. That case demonstrates that a displayed positive balance and an effective spending restriction can coexist. It does not establish the same situation here, because your post does not include that specific error or account history.
Changing a spending limit can authorize additional paid usage. It is a billing decision, not a harmless troubleshooting reset. I wouldn’t raise it or purchase more credits without first confirming the relevant account and understanding the charge implications.
When official billing support is the appropriate route
If one or both payments are missing from the intended account, the posted balance does not match the transactions, or the account shows contradictory usage and billing states, the official billing documentation lists billing@huggingface.co for billing-related support. A forum participant cannot inspect private payment records or guarantee a credit correction. Those questions are better handled through the official channel without exposing financial details in this public topic.
A private billing request can include the account, service, date and displayed status of each $10 top-up, approximate failure time with timezone, and any specific limit error. Mention that two projects still work. Keep receipts, card data, transaction IDs, account identifiers, tokens, and authenticated request traces out of the public thread.
If the purchased balance is correct and the observed failure follows a particular model or conversation rather than a spending-limit response, use the chat/provider branch instead. Payment and inference problems can coexist, but they should not be collapsed into one assumed cause. The goal is to resume the project without paying again for a problem that added credits would not resolve.
Error details, older reports, and ways to preserve the work
What a small error detail can tell us
A generic chat notification is not a unique error code. If you already have a safe, redacted HTTP status or application errorId, it may be more informative than another retry. These are directions for investigation, not automatic root-cause labels:
| Response | Possible next check |
|---|---|
400 |
Invalid request or model/provider parameters; read the actual validation text |
401 / 403 |
Authentication, permissions, spending limits, or provider restrictions |
402 / explicit credit error |
Payment or available-credit policy for the billed service |
404 |
Model, endpoint, resource, or route, depending on which service responded |
429 |
Rate/quota enforcement or congestion; not necessarily a zero balance |
500–504 |
App, gateway, provider, timeout, or upstream service failure |
| No code visible | Start with the product, model/mode, and working-versus-failing comparison |
The actual error text and the stage of failure matter more than the numeric category alone. For example, the October 30 PR describes a parameter-validation 400, while the separate August credit case included an explicit spending-limit 403. Those are different mechanisms even though a user might describe either as “the chat isn’t working.”
A simple follow-up could be only:
Service: HuggingChat Omni / Space / other
Projects: four conversations / four deployed apps / other
Now: two still fail / all work / intermittent
Model or mode (if known): ...
Error occurs: immediately / mid-response / stuck generating
Optional: approximate time + timezone, redacted status or error ID
The fields are optional; developer tools aren’t required. Do not publish full HAR captures, conversation content, request bodies, cookies, authorization headers, or secret-bearing URLs. Share a safe error ID only when appropriate; private account evidence belongs with support.
Similar reports worth separating, not combining
These are examples of different failure modes, not evidence that one of them caused this incident:
- HuggingChat discussion #671 (January 2025) contains the same generic message during an API-side outage acknowledged by a developer. Same words, not necessarily the same backend failure.
- Discussion #718 (May 2025) shows some models working while others returned fetch or connection errors. It demonstrates partial availability, but the old model list and infrastructure are not current outage evidence.
- Discussion #731 (June 2025) concerns old conversations returning
500after a model switch. It becomes more relevant only if the failing projects are existing conversations and new ones work. - Chat UI issue #2564 and PR #2584 describe interrupted-generation finalization that can leave a message stuck. The PR was still open when checked on October 31, 2026. That is a different observed symptom and should not be called a deployed remedy for this generic popup.
These sources are most useful to future readers as examples of why the same visible symptom does not establish the same root cause. The contemporaneous October 30 production fix is the best time-specific lead; the older cases support only conditional alternatives.
Ways to continue without losing anything
If a fresh chat or suitable alternative model already works, it may offer a temporary way to continue. A new chat won’t automatically carry over the original context, uploads, or settings, and a different model may have different capabilities and costs. Preserve the original project and move only material you’re comfortable transferring. A public demo app isn’t a safe workaround for confidential work.
For a Space, keep a record of its working revision and configuration before any targeted change. For a billing discrepancy, preserve the private payment record and contact the official billing channel; do not keep topping up. For a transient provider fault, note one failure time and the affected route if visible. If it has recovered, no further reproduction effort is required.
The two most helpful details would be whether the error still occurs and what you mean by the four “projects.” If a model name or safely redacted error code is already available, that may narrow it further, but there’s no need for another payment or a lengthy debugging session just to reply.
I Guess it doesnt Work for Everybody!
Which is Okay …i rather find it Hard to Say “THANK YOU” for what the Creators of HuggingFace are Doing in Those Intense Times of Innovations and Groundbreaking Break Thrus!
THOSE ARE GREAT TIMES! I AM IN A AI FRENZY! THANK YOU HUGGING FACE, THANK YOU ALL DEVELOPERS, THANK YOU THANK YOU AND…THANK YOU!
You Are LEGENDS like the KNOLL Brothers f.e.!