{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifz5p5spisp56p5nmfjauanrw6bz64nv3ehrcbxuxbixgi6qobiru",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mj33zqx56o52"
  },
  "path": "/t/how-do-i-resolve-this-issue-in-lmstudio/175120#post_2",
  "publishedAt": "2026-04-09T13:36:44.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "LM Studio",
    "Hugging Face",
    "GitHub"
  ],
  "textContent": "If you access the HF server too frequently within a short period of time, you’re likely to encounter a 429 error right away.\n\nTo avoid this, when using LM Studio, it seems best to specify the exact location of the target model repository (e.g. `lmstudio-community/Qwen3-Coder-Next-GGUF`) rather than using vague model family names.\n\n* * *\n\nThis is usually resolved by treating it as a **download-source resolution problem** , not a model-runtime problem. In your case, LM Studio is trying to resolve the `qwen/qwen3-coder-next` catalog entry, and that catalog entry expands into **four underlying repos** : one GGUF repo and three MLX repos. Hugging Face’s docs say **429** means rate limiting, and that rate limiting applies to **Resolvers** , which is the bucket used for file-download and related lookup traffic. (LM Studio)\n\n## What the error means\n\nA beginner-safe translation is:\n\n  * LM Studio is **not failing to run the model yet**.\n  * LM Studio is failing earlier, while asking “what files are in this repo and what are the download options?”\n  * The server answering that question replied **429 Too Many Requests**. Hugging Face documents that 429 is the standard rate-limit response, and that their tooling can even read the reset time from the `RateLimit` header before retrying. (Hugging Face)\n\n\n\nThat is why the message names several repos at once. The `qwen3-coder-next` entry is a wrapper over these sources:\n\n  * `lmstudio-community/Qwen3-Coder-Next-GGUF`\n  * `lmstudio-community/Qwen3-Coder-Next-MLX-4bit`\n  * `lmstudio-community/Qwen3-Coder-Next-MLX-6bit`\n  * `lmstudio-community/Qwen3-Coder-Next-MLX-8bit` (LM Studio)\n\n\n\n## The most likely cause\n\nThe most likely chain is:\n\n  1. You selected the bundled `qwen/qwen3-coder-next` entry.\n  2. LM Studio started resolving the underlying repos.\n  3. One of those resolver lookups got throttled.\n  4. LM Studio aborted the whole resolution step and surfaced the bundle as failed. (LM Studio)\n\n\n\nThat interpretation also matches other LM Studio bug reports where the failing component is `ArtifactResolutionProvider`, and the failing endpoint is the same kind of `.../tree/main?recursive=true&expand=false` repo-tree lookup. (GitHub)\n\n## What to do, in order\n\n### 1. Update LM Studio first\n\nLM Studio’s current changelog shows **0.4.10 Build 1** on April 9, 2026. If you are on an older build, update first, then fully quit and reopen the app. Resolver and downloader behavior has changed a lot across releases, so troubleshooting on an old build wastes time. (LM Studio)\n\n### 2. Stop retrying the bundled model for a few minutes\n\nDo not keep pressing retry over and over. Hugging Face rate limits apply in fixed windows, and their docs explicitly describe 429 retry handling around reset timing. Repeated retries inside the same limit window often just extend the pain. (Hugging Face)\n\n### 3. Bypass the bundle and target **one exact repo**\n\nThis is the highest-leverage fix.\n\nLM Studio’s official docs say you can search using an exact `user/model` string or even paste a full Hugging Face URL directly into the search bar. That lets you bypass the catalog wrapper and go straight to the one source you want. (LM Studio)\n\nUse one of these exact targets:\n\n**If you are on Windows or Linux, or you just want the safest general path, use GGUF**\n\n\n    lmstudio-community/Qwen3-Coder-Next-GGUF\n\n\n**If you are on an Apple Silicon Mac and specifically want MLX**\n\n\n    lmstudio-community/Qwen3-Coder-Next-MLX-4bit\n    lmstudio-community/Qwen3-Coder-Next-MLX-6bit\n    lmstudio-community/Qwen3-Coder-Next-MLX-8bit\n\n\nLM Studio supports GGUF on Mac, Windows, and Linux through `llama.cpp`, and supports MLX on Apple Silicon Macs. (LM Studio)\n\n### 4. Start with the smallest practical variant\n\nFor the GGUF repo, the current Hugging Face page lists:\n\n  * `Q4_K_M` at **48.5 GB**\n  * `Q6_K` at **65.5 GB**\n  * `Q8_0` at **84.8 GB** (Hugging Face)\n\n\n\nFor a first successful download, start with the smallest one you can tolerate. In practice, that usually means the **4-bit GGUF** first. That last sentence is advice, but it follows from the file sizes above and LM Studio’s own beginner-facing note that 4-bit or higher is the usual starting range when your machine can handle it. (Hugging Face)\n\n### 5. Toggle LM Studio’s Hugging Face proxy setting once\n\nLM Studio added an option to use **LM Studio’s Hugging Face proxy**. Their 0.3.9 release notes say it exists specifically to help users who have trouble reaching Hugging Face directly. There is also a recent issue where missing **Download Options** were reportedly resolved by turning that proxy on. (LM Studio)\n\nFor your case, the practical rule is simple:\n\n  * if the proxy is **on** , try it **off**\n  * if it is **off** , try it **on**\n\n\n\nThat recommendation is an inference from the documented proxy feature plus the fact that your error path already includes LM Studio’s proxy route. The point is to test a different network path, not to assume one setting is always better. (LM Studio)\n\n### 6. If you are on VPN, company Wi-Fi, campus Wi-Fi, or a managed proxy, test another network\n\nLM Studio has an open issue showing that users behind a **corporate HTTP proxy** can fail to download models or even fetch updates. Shared or managed network paths can make resolver failures much more likely. (GitHub)\n\nA very clean test is:\n\n  * turn off VPN\n  * or switch from work/school network to a phone hotspot or home network\n  * then retry the **exact repo** , not the bundled catalog entry (GitHub)\n\n\n\n### 7. Use the CLI as a fallback\n\nLM Studio’s CLI supports `lms get`, and LM Studio’s docs say full Hugging Face URLs are supported. That gives you a cleaner path than clicking through the bundled Discover entry. (LM Studio)\n\nExamples:\n\n**GGUF**\n\n\n    lms get https://huggingface.co/lmstudio-community/Qwen3-Coder-Next-GGUF\n\n\n**MLX 4-bit**\n\n\n    lms get https://huggingface.co/lmstudio-community/Qwen3-Coder-Next-MLX-4bit\n\n\nThose commands are supported because LM Studio documents `lms get <hugging face url>` explicitly. (LM Studio)\n\n### 8. If LM Studio’s downloader still fails, sideload the model and import it\n\nLM Studio documents `lms import` for bringing a local model file into LM Studio’s model directory, and their import docs show the expected local model structure. (LM Studio)\n\nExample:\n\n\n    lms import /path/to/model-file.gguf\n\n\nThis is the “I already have the file, stop using the downloader” path. It is especially useful if the issue is only in the resolver/downloader layer. (LM Studio)\n\n## Where Hugging Face authentication fits\n\nHugging Face documents **User Access Tokens** as the preferred way to authenticate applications to the Hub, and documents `HF_TOKEN` as the environment variable that overrides the local stored token. (Hugging Face)\n\nThat matters, but with one important caveat: LM Studio’s public app docs do not clearly document a dedicated “sign in to Hugging Face here to fix download resolution” flow for this exact app path. So I would treat token/authentication as **secondary** for your specific error, not the first fix. It is more useful if you are using Hugging Face tools directly or downloading outside LM Studio. (Hugging Face)\n\n## What I would do on a real machine\n\nI would do exactly this:\n\n  1. Update LM Studio to the newest version. (LM Studio)\n  2. Wait a few minutes before retrying. (Hugging Face)\n  3. In Discover, search for **`lmstudio-community/Qwen3-Coder-Next-GGUF`** directly instead of `qwen/qwen3-coder-next`. (LM Studio)\n  4. Try the smallest GGUF option first. (Hugging Face)\n  5. If that still fails, flip the Hugging Face proxy setting and retry the exact repo. (LM Studio)\n  6. If you are on VPN or a company/school network, retry from another network. (GitHub)\n  7. If the GUI still fails, run `lms get` with the full Hugging Face URL. (LM Studio)\n  8. If that still fails, download the GGUF file another way and `lms import` it. (LM Studio)\n\n\n\n## How to tell which cause you have\n\nIf **the exact repo works but the bundled`qwen/qwen3-coder-next` entry fails**, the problem was probably the multi-source resolver step. That conclusion follows from the model page showing the four-source bundle and LM Studio’s support for direct repo search/URL input. (LM Studio)\n\nIf **changing the proxy setting fixes it** , the problem was likely the network path between LM Studio and Hugging Face. LM Studio’s proxy feature and recent proxy-related issue reports support that interpretation. (LM Studio)\n\nIf **all model searches and downloads fail** , not just this one, suspect broader connectivity or proxy issues first. LM Studio’s issue tracker has reports of that exact pattern. (GitHub)\n\nIf **download succeeds but loading fails later** , that is a different problem. LM Studio’s model page lists **42 GB minimum system memory** for `qwen3-coder-next`, and the GGUF files themselves are very large. (LM Studio)\n\n## The main takeaway\n\nYour error is most likely **not** “Qwen3-Coder-Next is broken.” It is much more likely “LM Studio hit a **rate-limited file-resolution step** while expanding a multi-source model entry.” The simplest fix is to **stop hitting the wrapper entry** , wait for the rate limit window to clear, and then target the **one concrete repo you actually want**. (Hugging Face)",
  "title": "How do i resolve this issue in LMStudio?"
}