macOS 26 user unable to download models with error "offline mode: Repository not available locally"

[ronaldmannak]

I received a bug report from a macOS 26 user. They are unable to download any model. They consistently get an offline mode: Repository not available locally error. The user is not using a firewall.

I haven't updated to macOS 26 yet and I'm unable to reproduce the issue on macOS 15 Sequoia. I tried to compile the again on Xcode 26 but that didn't solve their issue.

Has anyone seen this issue?

This is the code I'm using to download models:

  let modelId = "mlx-community/SmolLM-135M-8bit"
  let hub = RepoStore.load().hubAPI(downloadBase: "https://huggingface.co")  
  try await hub.snapshot(from: modelId) { progress in
    ...
  }

[jkrukowski]

Yes, I experience that as well after updating to macOS 26, will try to dig deeper into it

[pcuenca]

Interesting, I'm on macOS 26 and haven't seen that. Will try to reproduce with that snippet.

[mattt]

@ronaldmannak Could you check how you're calling that API?

let hub = RepoStore.load().hubAPI(downloadBase: "https://huggingface.co")  

The downloadBase parameter is the base directory for where to download (defaults to ~/Documents/huggingface); "https://huggingface.co" is the default value for the endpoint parameter when HF_ENDPOINT isn't defined. There's at least one code path that throws an error if files aren't found in that directory, so that could be the cause.

[pcuenca]

Indeed, I didn't notice you seem to want to use endpoint rather than downloadBae (unless RepoStore uses different semantics).

This works for me:

        let modelId = "mlx-community/SmolLM-135M-8bit"
        let hub = HubApi()
        let downloadedTo = try await hub.snapshot(from: modelId) { progress in
            print("Total Progress: \(progress.fractionCompleted)")
        }

[ronaldmannak]

Sorry, my bad. I manually edited the code to shorten it and make it more readable, but accidentally mixed up the URLs. Here's the unedited code from the project.
The weird globalActor is there so users can save the models on an external drive. This works fine on macOS Sequoia.

    private func downloadFromHuggingFace(model: SDLanguageModel) async throws {
        let downloadBase = await FileController.shared.baseDirectory
        let hub = RepoStore.load().hubAPI(downloadBase: downloadBase)
        let modelId = model.modelId
        let persistentId = model.persistentModelID
        let container = self.modelContainer
        try await hub.snapshot(from: modelId) { progress in
            Task.detached {
                do {
                    let modelActor = LanguageModelActor(modelContainer: container)
                    try await modelActor.updateDownloadProgress(for: modelId, progress: progress.fractionCompleted)
                } catch {
                    PicoLanguageModelConfiguration.shared?.logger.error("Error updating download progress: \(error.localizedDescription)")
                }
            }
        }
    }

@globalActor
public actor FileController {
    
    /// Base directory for Hugging Face hub
    public private(set) var baseDirectory = URL.documentsDirectory
...

[mattt]

@ronaldmannak Thanks for clarifying!

My best guess is that macOS 26 is being more aggressive in its determination about when network conditions are considered "constrained" or "expensive", and that's what's causing the issue. (It could also be unrelated to macOS 26, but specific to the network conditions of affected users who happened to have upgraded)

As a workaround, you can try setting useOfflineMode to false like so (and plumbing that through to your hub client as well):

  private func downloadFromHuggingFace(model: SDLanguageModel) async throws {
      let downloadBase = await FileController.shared.baseDirectory
-     let hub = RepoStore.load().hubAPI(downloadBase: downloadBase)
+     let hub = RepoStore.load().hubAPI(downloadBase: downloadBase, useOfflineMode: false)
      let modelId = model.modelId

[ronaldmannak]

Thanks @mattt I've updated the code and sent out a new TestFlight. I'll let you know if it works

[ronaldmannak]

@mattt unfortunately it didn't make a difference and the build is still broken under macOS 26. I did notice PR #281 and even though this issue isn't mentioned, I'll try and use it in the next TestFlight release to see it solves the offline issue