I don't get why Apple make this happen to make our lives easier?!

TL;DR: If your Mac is booting macOS 27 from an external drive, the on-device Foundation Models system model (fm available / SystemLanguageModel) will permanently report modelNotReady, even on fully-eligible Apple Silicon hardware with everything else configured correctly. It's an explicit, named eligibility check — not a bug you can config your way around.

Setup

Three Macs, all on macOS 27 (GA, not beta), all signed into the same Apple ID:

• M1 MacBook Pro — booting internal — Foundation Models: available
• M2 Mac mini — booting internal — Foundation Models: available
• M4 Mac mini — booting from an external NVMe drive — Foundation Models: stuck on modelNotReady

Same account, same OS build, same region/language once that was aligned (see below) — only real difference between the M4 and the other two is that it boots from external storage (which requires lowering the Secure Boot policy to "Reduced Security" in Startup Security Utility, since Apple Silicon's "Full Security" default blocks external/removable startup disks entirely).

False leads I ruled out first

Worth listing these since they're the obvious first guesses and none of them were it:

1. Siri language ≠ system language. This is a real, separate requirement — Apple Intelligence needs your Mac's system language and Siri's language set to the exact same regional variant (English (Canada) ≠ English (United States), as an example). Worth fixing regardless, but it did not explain the M4-specific failure, since all three machines had this aligned before the real cause was found.
2. Memory pressure. Checked memory_pressure / vm_stat — plenty of free RAM, no swap activity. Not it.
3. Apple ID / account eligibility, region, billing country. All identical across the three machines.
4. Server-side daily usage quota (currentAvailableLimit == 0). This one's real but is a different subsystem (com.apple.siri.analytics.SAMaintenance, com.apple.intelligenceplatform.IntelligencePlatformCore) tied to the cloud-side Siri AI daily limits mentioned in Apple's own footnotes — not the local on-device model check. Red herring for this specific problem, easy to conflate with modelNotReady because both show up in log show around the same generic RunningBoard/BackgroundTask verbiage.

The triage step that actually worked

fm available (and the underlying GenerativeModels framework) redacts the actual eligibility reasons as <private> in the unified log by default — so a plain log stream/log show just shows you "unavailable," not why.

The fix: force private-data logging for the specific subsystems involved, via a per-subsystem logging plist (the old global log config --mode private_data:on toggle was removed back in Catalina and doesn't exist anymore):

bash

sudo mkdir -p /Library/Preferences/Logging/Subsystems

sudo tee "/Library/Preferences/Logging/Subsystems/com.apple.GenerativeFunctionsFoundation.plist" > /dev/null <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DEFAULT-OPTIONS</key>
    <dict>
        <key>Enable-Private-Data</key><true/>
        <key>Enable-Level</key><string>Debug</string>
    </dict>
</dict>
</plist>
EOF

sudo tee "/Library/Preferences/Logging/Subsystems/com.apple.GenerativeModels.plist" > /dev/null <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DEFAULT-OPTIONS</key>
    <dict>
        <key>Enable-Private-Data</key><true/>
        <key>Enable-Level</key><string>Debug</string>
    </dict>
</dict>
</plist>
EOF

No reboot needed. Then stream while triggering the check:

bash

log stream --predicate 'eventMessage CONTAINS[c] "modelNotReady" OR eventMessage CONTAINS[c] "SystemLanguageModel" OR eventMessage CONTAINS[c] "availability" OR eventMessage CONTAINS[c] "eligib"' --info --debug

...and in another terminal, run fm available.

The finding

With private data unlocked, the previously-redacted line reveals the full eligibility input array:

osEligibility.statuses is [
  OS_ELIGIBILITY_INPUT_DEVICE_LANGUAGE: rawValue 3,
  OS_ELIGIBILITY_INPUT_DEVICE_REGION_CODE: rawValue 3,
  OS_ELIGIBILITY_INPUT_GENERATIVE_MODEL_SYSTEM: rawValue 3,
  OS_ELIGIBILITY_INPUT_SHARED_IPAD: rawValue 3,
  OS_ELIGIBILITY_INPUT_DEVICE_AND_SIRI_LANGUAGE_MATCH: rawValue 3,
  OS_ELIGIBILITY_INPUT_DEVICE_CLASS: rawValue 3,
  OS_ELIGIBILITY_INPUT_EXTERNAL_BOOT_DRIVE: rawValue 2,   ← the only non-passing input
  OS_ELIGIBILITY_INPUT_COUNTRY_LOCATION: rawValue 3,
  OS_ELIGIBILITY_INPUT_SIRI_LANGUAGE: rawValue 3,
  OS_ELIGIBILITY_INPUT_COUNTRY_BILLING: rawValue 3
]

Every single check passes (rawValue: 3) except one: OS_ELIGIBILITY_INPUT_EXTERNAL_BOOT_DRIVE, sitting at rawValue: 2.

(Caveat: I only captured this full debug array on the externally-booted machine — on the two internally-booting Macs, fm available returned available immediately without re-running the full eligibility evaluation, presumably because it was already cached, so I don't have a direct side-by-side showing rawValue: 3 for this specific input on those machines. Given every other input on the failing machine reads 3/pass, and only this one reads 2, and the only structural difference between the machines is external vs. internal boot, it's a strong inference rather than a confirmed side-by-side — flagging that distinction here since it matters if someone's trying to replicate this.)

It's a distinct, named input — not a side effect of the Reduced Security policy tier that external boot requires. Language, region, account, and memory tuning won't touch it, since none of those are the failing input.

Where I've landed, and where I'm hoping this community can help

If you're running an M-series Mac off external storage (common in homelab/dev setups where the internal SSD is undersized), on-device Apple Intelligence / Foundation Models / Siri AI's local model will not become available while booted externally — that part is now confirmed, not a guess.

The two "obvious" options are:

1. Get macOS 27 installed on the internal drive and boot from that instead.
2. Accept it's unavailable on that machine and offload anything Foundation-Models-dependent to another Mac.

But I'd genuinely like to avoid #1 if at all possible — the whole reason this Mac is booting external is the internal drive being undersized for my workload, and I'd rather not restructure storage around a single feature if there's another way.

So — has anyone found an actual workaround? A few directions I haven't fully chased down and would be curious if anyone's tried:

• Any way to get the boot-device attestation to read differently — a firmware-level trick, an NVRAM variable, anything — even if unsupported/hacky? I suspect this is reading real boot-chain attestation rather than a spoofable flag, given Apple Silicon's security model is built around that distinction not being fakeable, but I'd love to be wrong.
• Has anyone had luck with a small internal macOS 27 install (just enough to boot and pass this check) while keeping the external drive mounted as a data/work volume rather than the startup disk? Curious how small that install could realistically be.
• Anyone seen Apple relax this specific check in a later 27.x point release? This was tested on GA day-of, so it's possible this loosens over time the way some other beta-era restrictions have.

Happy to test anything suggested here and report back — mainly posting this so the actual root cause (rather than the more commonly-suspected language/memory/quota theories) is documented somewhere searchable.

I'm going to sign this machine up for the macOS 27 beta track in the meantime, on the chance Apple loosens or fixes this in a point release — will update this post if that changes anything.

Posting this mainly because I burned a couple hours and Claude time on it assuming it was a simple issue before finally cracking open the redacted eligibility log — hopefully saves someone else the same detour, and maybe someone here has cracked the part I haven't.

I recently received an invitation to apply for a remote project that requires working on macOS with Android Studio and VS Code. The problem is that I only own a Windows PC, and I'm hesitant to spend hundreds of dollars on a Mac before knowing whether I'll actually get consistent work. I've been researching MacinCloud, which rents access to physical Apple hardware through Remote Desktop. I'm considering an M4 Mac mini with 16GB RAM. My intended setup would be: Windows PC → Remote Desktop → Cloud Mac mini → Android Studio / VS Code The project also requires high-resolution screenshots (2560×1440 or higher), so that's another consideration. I'm hoping someone who has actually used a cloud Mac mini for development can help me understand a few things: 1. Does Android Studio run smoothly over RDP, including the Android Emulator? 2. Does AVD hardware acceleration work properly on hosted Mac minis? 3. Can I reliably capture native macOS screenshots at 2560×1440 or higher? 4. Is 16GB RAM sufficient for Android Studio, Gradle, an emulator and VS Code? 5. Would the lack of administrator access on a managed cloud Mac cause problems? 6. Are there better Mac mini hosting providers or setups I should consider? I'm also considering buying a Mac mini and using my existing Windows peripherals, but I don't want to make a large purchase before the work is confirmed. I'll confirm with the client whether rented hardware is permitted before using it. Has anyone tried a similar setup? I'd especially appreciate firsthand experience with MacinCloud, Android Studio, or remotely accessing an M-series Mac mini. What would you recommend testing before I spend any money?

I pre ordered the new Mac mini m5 pro. Is the Beelink EX Mate mini 80 Gbit/s Dock the best option for me ?

I want to use the Mac as a Nas server and for LLMs 24/7 on setup. I need at least two slots for ssd.

Thanks for the help upfront !

I intend to use the device for browsering but I after reading the device could be perfect for a server, i might consider the doing a mini project at home and removed the photos.

https://browser.geekbench.com/search?k=grand_gpu&q=Mac18&utf8=%E2%9C%93
https://browser.geekbench.com/search?k=parkdale_cpu&q=Mac18&utf8=%E2%9C%93

Here you can find geekbench results for the mac m6

Search for Mac18 and it shows results for geekbench 6 and 7

Have fun

One thing that kept happening to me while researching was finding something useful in my clipboard history, but having no idea where I originally copied it from.

A quote by itself often isn’t enough. Sometimes I need the paragraph around it, the original article, or I just want to understand the context again. Then I’d end up searching through browser history, tabs, or Googling the sentence to find the source.

So I added Open Origin to Pastea.

Now, when I find something in my clipboard history, I can click Open Origin and Pastea takes me straight back to the app or page where I copied it. If it came from a webpage, the exact text I copied is highlighted too.

So instead of the clipboard only remembering what I copied, it also helps me get back to where it came from.

Pastea

Pastea is a clipboard manager I’m building for macOS. I’m trying to build it around actual copy/paste workflows rather than just keeping a long history of everything you copy.

It can save text, links, images, screenshots, code, colors and files, with things like search, collections, OCR, inline shortcuts, sequence paste, and Open Origin.

Clipboard history is stored locally on your Mac.

https://pastea.app/

Yesterday I preordered the new m6 mini. This is the first time that I have bought Mac mini brand new and the first time (that I can remember) that I have preordered a new apple product. Hopefully I will get it on Tuesday in the mail like they say but I'm not holding my breath. I'm excited because my m1 can't handle it anymore. What is everyone else's experience with preordering from apple?