Alexey Ryabov it has been fixed by Vercel team.

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. https://vercel.com/docs/domains/troubleshooting

disabled-acc @system i don't have access

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. https://vercel.com/docs/domains/troubleshooting

Grumpyice **Hi Vercel team, just following up on this issue.** I’m still unable to verify **ijedelcda.lg.gov.ng**, and Vercel continues to show **“This domain is linked to another Vercel account.”** The requested TXT verification record has already been added to the domain’s DNS through Go54, but the status remains **Verification Required**. Could someone please advise whether the domain association needs to be released or verified on Vercel’s side? I’d appreciate any guidance. Thank you

Flowfeed Same issue here

Flowfeed For anyone else experiencing this issue: submit a support case. I submitted a support case, and the issue has been resolved. Below is the response from the Vercel support team: ``` We apologize for any inconvenience. Access to Claude Opus 5 and Claude Fable 5 may be temporarily limited for some accounts as part of safeguards that protect service reliability. When this happens, requests return a 429 response. Your account has been verified, and the rate limit should be lifted. Please try again and feel free to let us know if you have any questions! ```

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. https://vercel.com/docs/domains/troubleshooting

David same here on team aib-ois, been like this since the 26th. maybe 1 in 15 calls gets thru, the rest come back 429 high demand with providerAttemptCount 0 so it never even touches the provider. our rate is tiny, about 1 call a minute. bought credits today thinking the free tier was the issue, nope, paid tier does the exact same thing. the support bot said the gateway health check has typesafe marked unhealthy so it just fast fails everything, but the endpoints api shows 100 percent uptime so somthing doesnt add up. hobby plan cant open a case so posting here instead. one of todays rejected ids if it helps, gen_01M3JF68E219411054WMFD52GH. is this per team or is everyone cooked rn

Pulec Same here. Team on Hobby with paid AI Gateway credits (bought 28 Sep 2026), typesafe-ai/jev via /typesafe/v1/systemone. I measured exactly one accepted call roughly every 300 s; every call in between returns 429 "upstream provider is currently experiencing high demand", regardless of payload size. It has been consistent all day (Sydney time). It would be great to hear from Vercel whether this is per-team throttling, what the limit is, and whether Pro changes it.

Borysuslik 4009 We are seeing the same issue on a Hobby team with purchased AI Gateway credits. Other models work with the same key, but a minimal typesafe-ai/jev request returns HTTP 429 with totalProviderAttemptCount: 0. Pinning providerOptions.gateway.only to ["typesafe-ai"] also returned 429. Minimal reproduction: POST https://ai-gateway.vercel.sh/v1/evaluate {"model":"typesafe-ai/jev","state":"The circle is red.","questions":{"red":{"type":"boolean","instructions":"Is the circle red?"}}} Error: "The upstream provider is currently experiencing high demand. Please retry shortly." Vercel's support assistant prepared a case, but the case form says Hobby accounts must use the community for AI Gateway support, so we are adding this report here. Could Vercel staff clarify whether this is a known Jev routing or provider-health issue, a paid-tier activation issue, or a documented per-team restriction? What action is needed to restore access? We can provide a generation ID privately to staff for investigation.

system While a member of our team prepares to jump in, you might find your answer even faster in our community resources. - Official Documentation: https://v0.app/docs - The v0 expert walkthrough: https://community.vercel.com/t/become-a-v0-expert/5981 - Watch v0 in Action: https://community.vercel.com/live#v0

Andre 1912 Bump! this is currently blocking my testing to choose a way forward for production

Jplay Confirming the same issue in ChatGPT Web with the connected Vercel plugin (0.21.4), in addition to Codex. On Sep 28, 2026, I reconnected my Vercel account via OAuth and started a fresh ChatGPT chat. I requested a minimal production deployment and provided an inline index.html. The exposed tool signature was `deploy_to_vercel(): any` (no target/name/files inputs), while the current Vercel MCP docs describe those inputs: https://vercel.com/docs/agent-resources/vercel-mcp/tools ChatGPT called `Vercel.deploy_to_vercel({})` and received: `{"type":"json_rpc_error","code":-32602,"message":"Tool deploy_to_vercel not found","is_error":true}` A read-only Vercel operation (`list_teams`) returned normally. Reconnecting and starting a new chat did not change the deployment error. No deployment ID or URL was created. Public reproduction chat: https://chatgpt.com/share/6ab9ce4f-8248-83ea-a8fe-1632a37dd6ca Could the Vercel MCP / ChatGPT connector owners check the tool registration and exposed input schema, or confirm whether this deployment action is currently disabled?

Steven Noxious Same issue here on a Hobby team. I reproduced it independently and isolated the failure to Jev / Evaluation API. Working on the same team and API key: - GET /v1/models → HTTP 200 - GET /v1/credits → balance $5 - POST /v1/chat/completions with openai/gpt-4.1-nano → HTTP 200 and billed successfully - typesafe-ai/jev is present in the model catalog Failing: - POST /v1/evaluate, model typesafe-ai/jev → HTTP 403 - POST /typesafe/v1/systemone, model jev-latest → HTTP 403 I also verified: - Provider Allowlist is disabled - Zero Data Retention is disabled - vercel ai-gateway rules ls returns No routing rules found Both failures reproduce with direct PowerShell HTTP requests, without SDK/application code. This therefore appears to be a Jev / Evaluation API entitlement or provisioning issue on Hobby teams rather than an authentication, billing, routing-rule, or application problem. Could Vercel staff check the Jev/Evaluation entitlement for affected Hobby teams?

Stickmedia007 8373 Hi, I'm experiencing the same issue and have carried out some additional troubleshooting that may help narrow it down. My setup is Windows PowerShell with Vercel CLI 60.1.3. I've confirmed the following: - Jev (`typesafe-ai/jev`) appears in the Gateway model catalogue. - My API key successfully authenticates against `/v1/credits`. - My account has $5 available credit and an active payment method. - A standard request using `openai/gpt-4o-mini` succeeds with the same API key. - Requests to `/v1/evaluate` using Jev consistently return HTTP 403, with no additional error details. - One subsequent retry returned HTTP 429. Given that standard AI Gateway requests work correctly, and another user has reproduced the same Jev issue with a freshly generated API key, this appears potentially related to Jev-specific access, Evaluation API provisioning, or a service-side issue. Could Vercel confirm whether this is a known issue or whether additional permissions are required for the Evaluation API? Thanks!

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Killupdate Update: the issue still reproduces on 27 September 2026, approximately 15:50–15:52 UTC. Asset: /images/1.webp, expected 179098 bytes. - www.optmebelug.ru: HTTP/2 200, 10137 bytes then timeout at 25s. x-vercel-id: arn1::fxcv6-1790524246812-4e133cf818fb - Same custom domain with HTTP/1.1: HTTP 200, 20821 bytes then timeout at 25s. x-vercel-id: arn1::k9gfp-1790524246825-a146d12dadd5 - optmebelug-new.vercel.app: HTTP/2 200, all 179098 bytes in 1.37s. x-vercel-id: fra1::2d26r-1790524246706-67287d31a5d9 Pinning BOTH names to 64.29.17.65 with curl --resolve and matching URL/SNI/Host: - www: HTTP 200, 16067 bytes then timeout at 20s; cache HIT. x-vercel-id: arn1::wpfrj-1790524305935-b56dafe99aa5 - vercel.app: HTTP 200, full 179098 bytes in 1.09s; cache HIT. x-vercel-id: fra1::wnvhb-1790524306321-852e4a4af579 Both responses have the same ETag: 2363172b1b0e734a531508d0f6be27bc. TLS certificate verification passed for the above HTTP responses. An 8192-byte Range request on www completed with HTTP 206 in 0.17s. We noticed staff has already escalated a related report to the network team: https://community.vercel.com/t/48756 Could you correlate our case and request IDs with that investigation, and check why the hostnames report arn1 versus fra1 even with the same pinned destination IP? We have not established whether the cause is at Vercel's edge or along the downstream network path. Please advise the most useful next measurement. No DNS or Vercel configuration was changed during these tests.