Five Things That Stall Week One: Mac and Windows Learners Hit Different Walls ​

We · November 2026

This is the second article in the "AI Learning Environment" series. The series answers four things only: whether it runs, how it installs, how versions line up, and how a lab is managed. What to look at before enrolling is in Check This Table Before Enrollment; this article assumes you have already enrolled and the machine is next to you, and covers what actually stalls in week one.

The numbers here come from the system requirements carried on each app's detail page, the hardware requirements written on our own workflow pages, and upstream projects' public documentation, compiled in November 2026. These are a reference for judgment, not a promise — software changes monthly, so go by what the page says on the day you install. This article evaluates no institution, recommends no course, and is not purchasing advice.

1. Why week one is where it all piles up ​

Before enrollment the question is "is my machine enough". In week one it becomes "I clearly installed it, so why can't I still use it". Those are not the same question.

The moment the install finishes, three things have changed on the student's machine at once: an unfamiliar program, a set of model files counted in gigabytes, and an assignment rhythm that advances by the day. The third is the easiest to overlook — a course does not pause to wait for your environment. So most of what surfaces in week one isn't inside any one of those three on its own; it lives where they mesh.

Putting together the applications we've compiled, what their detail pages state, and what our installation service is asked over and over, the week-one obstacles come down to five places:

Only the second of these five is really about how expensive the machine is. The other four are information problems: location, version, terms, division of labor. That is why this article is written for non-technical students — every item below asks you to check one sentence, not to understand the technology.

One more thing up front: Windows and Mac hit different walls. A Windows wall is usually something misaligned — align it and it's fixed. A Mac wall is usually a path upstream never built — it can't be fixed, only routed around. Each section below covers the two sides separately.

2. The first thing: where it installs ​

Location problems for local AI apps have two layers, and the first is the path itself.

Our own Data File Migration Guide lists four problems with the default location, and the first is the easiest to walk into: on Windows, a username containing Chinese characters or spaces causes compatibility problems when some apps read and write their data. The default data directory sits under "Documents" on the system drive (C:\Users\<username>\Documents\ on Windows, /Users/<username>/Documents/ on macOS), which means your username ends up inside the path of every model file. Plenty of people stare at a first error with no explanation, and this is where it starts.

The second is more subtle: "Documents" and "Desktop" may already have been taken over by a cloud drive. On a Windows machine that has run OneDrive with folder syncing switched on, the real location of "Documents" has moved into the sync directory; the same happens on macOS when "Desktop & Documents Folders" iCloud sync is on. Model files in a directory like that cause three kinds of trouble: a sync process reading and writing them repeatedly slows everything down, a large weight may exist only as a placeholder (the software believes the file is there; it was never downloaded), and sync conflicts generate copies that clutter the folder.

The third layer is external drives and their filesystem format. The classic trap is FAT32's 4GB single-file limit: a weight file of tens of gigabytes can't be written at all, yet the error usually reads "path not found". Most portable drives bought today aren't FAT32 but exFAT, and its trouble is subtler: on macOS, exFAT is not only slow and wasteful of space — a git repository cannot be created on it correctly. These apps rely on git to pull code from upstream repositories during installation (that prerequisite is exactly what our Git Installation Guide: The First Step to Installing AI Apps covers), so an install onto an exFAT drive fails at the first step, and the message is rarely anything as legible as "unsupported format".

The wasted-space claim has a measured case behind it. Our SSD Formatting Guide describes an exFAT portable SSD where the drive plainly had room left, yet the install script reported No space left on device. The reason: on drives above 32GB, exFAT defaults to a 128KB cluster size, and Python dependencies are almost entirely tiny files, each of which costs at least one whole cluster. The conclusion isn't "don't use an external drive" — models run to tens of gigabytes, a built-in disk fills up quickly, and installing to an external drive is standard practice. What you choose is the format: exFAT is fine for shuttling assets between Windows and Mac, but if apps and weights live and run on that drive long-term, use NTFS on Windows and APFS on Mac — the same advice that guide gives for the "AI software and model storage" case.

The second layer causes more trouble than the path does: two copies of the same-named app on one machine. The course material ships one bundled package, and the student also pulled a copy from source following an online tutorial, or installed once last month and didn't clean it up. The result is that the software opens, the interface looks normal, and it can't find any model — because the copy you launched and the copy holding the models aren't the same directory.

The test is one sentence: don't recognize an app by its icon, recognize it by the address it opens on. Most of these apps open a local port in a browser once launched, in a form like 127.0.0.1:7860, and 7860 happens to be the most common default port. So when two of them are open at once, the second usually appears to have "opened" while what you're looking at is still the first one's interface. Close the other instances first, read the port number in the address bar, then confirm which copy loaded.

One conclusion you can act on directly:

Decide on a location on day one — English only, no spaces, outside any cloud-sync directory, not on the system drive — and put all app data, model weights, course material and assignment output into it. Most location problems disappear from then on.

3. The second thing: how much space is left ​

This is the only one of the five that is a genuine hardware problem, and it presents in a misleading way: fitting isn't the same as running, and enough today isn't enough next week.

Some numbers from our own pages:

The 85GB between the first row and the third isn't software size, it's models. An app body is tens of megabytes to a few gigabytes; one weight file is a dozen or more. Students who estimate disk from the installer progress bar almost always come out under.

So don't read total capacity; read how much the target drive has free right now, and leave a margin beyond what the work itself consumes. AI apps also write output files, temp files and caches, and the intermediate files of video and training steps are often an order of magnitude larger than the deliverable. Once free space falls into single-digit gigabytes, the errors stop looking like a space problem — "out of video memory", "write failed", "it crashed for no reason".

There is a second layer to this one that few people treat as a disk problem: writing fast. Video jobs make it obvious. On our workflow page for one video tier we write "tested on an RTX 5060 Ti with 16GB of VRAM", but the upstream author's own troubleshooting list carries two conditions beyond the card: it must be an SSD, and it needs over a hundred gigabytes free. On the same class of graphics card one person gets a frame every few seconds and another every minute or more, and the difference is usually whether memory is sufficient, whether the job spilled onto the disk, and whether that disk is a spinning one. We worked through that arithmetic in more detail in Why Is Your Locally Deployed AI App So Slow?.

To close this one: the right question isn't "is 512GB enough for this PC", it's a different question — how many tracks' models do I plan to install, and how much will this drive have left after the first month.

4. The third thing: a version isn't one number, it's four layers ​

This is where week one burns the most time, because "the version" looks like it should be a single thing.

Take ComfyUI. The "why you need one-click install" section of our detail page is exactly that list: the Python environment, the CUDA environment, the PyTorch version, model dependencies, third-party nodes — five layers a manual install has to handle. A student finishes the install remembering only "I installed ComfyUI", while the error comes from one layer sitting out of place.

Misalignment one: GPU architecture versus PyTorch build. Our page Deploying ComfyUI with One Click: Choosing the Right Runtime Environment gives a clear rule: cards older than the 40 and 50 series are most stable on the default environment (Torch 2.7.1, for example), while 50-series and newer architectures should move to 2.8.0, 2.9.1 or even 2.10.0 to get the performance. The same passage carries a more important warning: every time you switch runtime environment, the system re-checks its dependencies, which takes a long time; for everyday use, stay on one environment. Switching environments is not a free experiment — switching back and forth scrambles the dependencies.

Misalignment two: hard requirements at workflow level. This layer is finer than app level, and it really does refuse you. Verbatim from our workflow pages:

• One video workflow "uses an fp8 quantized model and can only run on NVIDIA cards, such as the 30, 40 or 50 series, with at least 16GB of VRAM";
• Another tier in the same series reads "fp4 quantized model... Blackwell or newer architecture, such as the 50 series, at least 16GB of VRAM, and ComfyUI must use torch 2.8.0 or above" (LTX-2 image-to-video fp8 page);
• The accelerated build of an omni-modal model reads "supports NVIDIA RTX 40- and 50-series cards only (or newer architectures), and PyTorch 2.10 or higher is required" (MiniMax-H3 four-step acceleration page).

For a student this means: in the same course with the same software, the week-3 workflow and the week-6 workflow may need two different environments. So "my ComfyUI is installed" stops being a complete answer after week one — you have to read the hardware requirements on that specific workflow page. We are filling in this copy workflow by workflow, but for the ones not yet covered, look the model name up against upstream requirements yourself during week one.

Misalignment three is Mac-only, and different in kind. On Mac it is rarely "the version is old"; usually upstream never built this path. Three kinds of wording, all quotable from our own pages:

• One class of upscale-and-restore workflow runs directly on Windows, while on Apple silicon you need to change the device parameter of two custom nodes to mps (SeedVR2 simple image upscale) — this one is fixable;
• One image-editing LoRA reads "this LoRA is currently tested only on Windows and doesn't work well on macOS" (Qwen Image Edit 2509 GGUF) — this one isn't fixable, only reroutable;
• One speech-driven video workflow reads "our support for macOS is still under testing" (Wan2.2 S2V speech-driven video) — this one has no answer yet, so don't plan an assignment around it running.

Those three mixed together are what makes week one hardest on Mac: the errors all look the same (missing dependency, missing operator, a red node), yet one is fixable by changing a parameter, one needs a different model, and one means waiting or going to the cloud. There is only one way to tell them apart: read the hardware-requirements paragraph on that app page and that workflow page and see whether macOS is mentioned at all. Detail pages state macOS support in two forms only — "M-series chips only" and "supports Intel and M-series chips" — and if macOS isn't written, treat the app as Windows-only.

There is one more layer that isn't misalignment but costs just as long: training and inference aren't the same threshold. A voice-cloning course using an existing model is a low bar for inference. Once the assignment says "train a voice from three recordings of your own", the community's agreed workable floor is the 8GB VRAM tier, and on Apple silicon we can't promise training will succeed. LoRA training is the same. Ask in week one whether the course contains a training step; if you don't, the question arrives mid-term as "the whole class is handing in work and I'm waiting on a machine".

5. The fourth thing: accounts and authorization ​

This is the place most easily dismissed as minor, because it needs no technical skill — and yet it's the likeliest reason a student loses a whole day in week one, because how long it takes depends on somebody else.

Redemption codes. If the course or institution issued a code for the installation service, read the Redemption Code Notice for Installation Services first: each code can be redeemed once only, must be used on the detail page of the named app, and has an expiry date. Those three rules produce three field failures: the code is entered correctly but reports already used (someone claimed it for you), the code is valid but you're redeeming it on another app's page, or the code has expired. People who redeem for the first time on the first class day hit the third one. Redeem the code the day you receive it is the only thing to take from this section.

Some models require accepting terms before download. A meaningful share of generative models sit on hosting sites that require a login and acceptance of that model's license terms before they let you pull the file. In class this shows up as "the teacher finished installing in a minute and I sat on the download page for twenty". How to check: write down the model names the course uses and check each one's download page the day before, to see whether it requires a login. This isn't a difficulty problem, it's a time problem — review and queues aren't under your control.

Some "local software" uses a cloud service by default. This is the most counterintuitive item. For example, in one-click video tools the official main path calls a cloud model to write the script, an online interface to synthesize the voice, and an online asset library for the footage — the graphics card isn't the point, and to actually use it offline you have to apply for and paste in your own API key. The same catalog also carries apps that state plainly that no third-party API is needed and every function runs locally (Video Subtitle Remover detail page). So: whether something runs locally has to be asked app by app; you can't infer it from the software's name. That's exactly why we insist each app detail page states its system requirements and how it runs.

System version and chip are a threshold too. Many apps state their macOS requirement as "macOS 15 or later plus an M-series chip". For a student this belongs with accounts: it isn't that you did something wrong, it's that this machine isn't inside this support range. That information is all in the same few lines of the detail page, and it should be read before enrollment.

The service-window clause. This one applies to us as well, and it's here as a reference for students. Our After-Sales Notice for Installation Services allows an installation service to be requested for after-sales within a 3-day no-reason window, after which it enters the maintenance period; cases such as "the device doesn't meet the published minimum system requirements" or "you overwrote the install with another version yourself" fall outside free after-sales; and when a major iteration or an upstream architecture change requires redoing the work, a separate fee may apply. This is here to make one point rather than to advertise a service: environment problems almost all surface in week one, so get one full run through in week one instead of saving it up for the day the assignment is due.

One closing note on licensing, because it's the other half of the word "authorization": installing and running something doesn't mean what you make from it can be used commercially. License tiers differ even within one model family — some are permissive, some explicitly forbid commercial use. A student learning in order to take client work should read Do Schools and Research Labs Need to Worry About Licenses?, and for how the chain is counted once a model has been modified, see Do Quantized, LoRA, or Fine-Tuned Models Still Fall Under the Original License?.

6. The fifth thing: how cloud and local split ​

Of the five, this is the least like a "technical problem", yet it decides what happens after the other four strike.

Being forced onto the cloud in week one usually has three reasons: the spec isn't enough, this step has limited support on Mac, it has to be handed in today. The three call for different responses, but students tend to make them all one thing — move the entire course to a cloud desktop. That's where the trouble starts.

Switching the whole course carries four costs:

1. Every file becomes two. Weights, assets, intermediates and output end up split between the local machine and the cloud; shuttling them costs more than you expect, and the transfer is where things break most.
2. The cloud environment isn't the version taught in class. The cloud machine carries whatever snapshot the provider prepared; class runs on the teacher's build. The four-layer version problem from section four returns here unchanged, and you can't fix it yourself.
3. The experience is uneven. Public complaint platforms carry consumer reports of cloud machines that don't match the advertised spec and restart mid-use. Nothing you do operationally solves that class of problem.
4. Renewal and supply risk. Cloud is a continuing subscription: expiry, a platform change, or a datacenter move all make "what I was running last week" fail to run today.

So the right question isn't "local or cloud" but a shift in framing: which steps have to be on my machine and which can borrow one. Splitting by step beats splitting by course:

Article three of this series runs this table along a full comic-drama pipeline. For now one sentence is enough: moving to the cloud isn't a failed downgrade; picking the wrong granularity is.

Our own position, briefly: local and cloud have different cost shapes, and Why Training Institutions Choose Open Source Over Token-Billed Platforms works that ledger through, so it won't be repeated here. The most practical line is this: run locally where local runs, and when it can't, state exactly which tier you drop to and which step moves to the cloud — rather than "spec isn't enough, so hand out a cloud desktop", which replays all five problems on different hardware with nothing missing.

7. The five-step order when nothing installs ​

This is the only section to follow literally. The order matters more than the tricks: working in this order rules out a whole class of cause at each step, while working out of order bounces between two or three causes and ends with a reinstalled system and no fix.

Step 1: separate "environment problem" from "course content problem". The test is whether the default example runs. Create a minimal text-to-image or ten-second voice task and run it once on the small model shipped with the software. If it runs, the environment is sound and what you're stuck on is a workflow in the course missing a node, a model or a parameter — that's a content problem, take it to the course, and reinstalling the software won't fix it. If it doesn't, continue.

Step 2: check the system layer. On Windows, look at the OS version and whether the graphics driver is current (the line "please install a newer driver" appears on many detail pages, because it really is common). On Mac, check the system version and the chip, then compare against those two macOS lines on the detail page. The signature of this layer is an error at launch, or an app that quits the instant it opens.

Step 3: check the space layer. Whether the target drive still has room (per section three: read free space, not capacity); whether the path contains Chinese characters or spaces; whether it sits inside a cloud-sync directory; whether two apps of the same kind are open at once. The signature is "file not found", "write failed", "it died halfway through".

Step 4: check the version layer. Which runtime environment this app selected; what the hardware-requirements paragraph of this model or workflow states (GPU architecture, PyTorch version, VRAM); whether nodes from two different bundled packages got installed together. The signature is missing dependencies, missing operators, red nodes.

Step 5: confirm it reproduces consistently, then ask for help. One successful request for help carries six items; miss one and you add a round trip:

1. Operating system and version (Windows 10/11, or the macOS version number);
2. Chip or graphics card model, plus VRAM or unified memory size;
3. The app name, and the version written on its detail page;
4. Which workflow or which model file you used (write the name, not "the one from class");
5. The full error sentence, not half a screenshot;
6. The result of that minimal example from step 1: did it run or not.

Two things in this order are explicitly not to be done: don't reinstall the operating system first — if five steps haven't located the cause, a reinstall only destroys the reproducible scene; don't install a few dozen custom nodes in one go — you think you're patching dependencies and you're actually creating the misalignment from section four.

8. Our view ​

First, what week one should teach isn't the software; it's the edges of your own machine. Concretely that's three small things: pick a location, clear the space once, get one minimal example to run. Do those and you know which tier you're in, and which tier a downgrade would take you to. Conversely, the person who spends week one "following the video until the interface opens" arrives at week seven stranded on a machine they don't understand at all.

Second, Windows and Mac problems shouldn't share one answer sheet. The Windows blockers cluster around version alignment, and the answer is usually "switch to this environment"; the Mac cluster around ecosystem coverage, and the answer is usually "this path isn't open yet — use a different method or a different machine". Answering both sides from one document guarantees one side is busy for nothing. It's also why we require every app detail page to state macOS in one of two explicit forms, "M-series only" or "Intel and M-series": the difference isn't in the wording, it's in whether a conclusion can be given.

Third, most environment problems aren't capability problems; they're information problems. Location, space, version, terms, division of labor — none of the five requires a student to write code. What they require is somebody spelling them out before the first class. Flip it around: any one left unspoken becomes, mid-term, a round of "maybe I'm not cut out for this". A student who can't install the software doesn't blame the software; they blame themselves. We put that sentence in our institutional material, and it belongs here too.

What a machine decides in week one is the pace of your classes, not whether you can learn the material. This article gives no verdict of "can" or "can't"; it gives sentences you can check: what the page states, what your machine has, and where those two don't line up. Where they don't line up is what the rest of this series goes through one article at a time.

The next article takes one complete AI comic-drama pipeline and threads these steps in order — from script to final cut, how much a single machine actually has to install, and which tier each step drops to.

Disclaimer: The configuration statements in this article come from the system requirements carried on each app's detail page, the hardware-requirement copy on our workflow pages, and upstream projects' public documentation, compiled by us in November 2026. Software and model versions update monthly and requirements may change; the figures and statements here are a reference for judgment, not a guarantee that any app will run or deliver on your device. The parts describing industry phenomena are drawn from consumer reports on public complaint platforms and illustrate categories of problem only; they do not refer to or evaluate any specific institution or course.