Inference on the Mac Studios Disney already owns, without touching production.

Taken together, your Mac Studios hold more memory than most dedicated inference clusters, and that memory is already paid for, already inside your network and already under your management. It is also idle for most of the hours in a week. The only reason not to use it is the risk of getting in someone’s way. This proposal is about removing that risk, and proving it is removed, before anything else.

From what we know today. Tell us where we are wrong; the pilot is scoped around the constraints that actually bind.

• Thousands of Mac Studios across studios and offices worldwide, bought over several generations, so memory ranges from 32GB to 512GB per machine, with 10Gb Ethernet as standard on every model.
• Used for rendering, grading, compositing, audio and everyday work, and idle for most of the hours in a week. Because the sites span time zones, the idle hours follow the sun.
• Interrupting a render, a grade, a mix or an artist in crunch is not acceptable at any rate. One bad night ends the programme.
• Content ranges from public to unreleased, so where a prompt is processed matters as much as whether it is processed at all.
• IT already manages these machines, and the render wranglers already decide who gets which machine when. A second management agent, or a second scheduler that argues with theirs, is unwelcome.

This is an old idea with two new problems

Scavenging idle workstations is how HTCondor has run at universities since the late 1980s: jobs start when the owner is away, and are suspended or evicted the moment the keyboard is touched. Apple built its own version, Xgrid, into Mac OS X for several years and no longer ships it. What is new here is unified memory, where the model and the artist’s scene share one pool rather than separate graphics memory, and an owner whose screen may show an unreleased film. The first is an engineering problem and the second is a policy one. This proposal treats them separately.

Everything else in this document sits on four commitments. Each has a test in section 7, and the pilot fails if any one of them fails.

• Reclaim is automatic. The moment a machine shows signs of its owner (keyboard, mouse, a production application starting, or the render queue claiming it), inference pauses within a token and memory is released within seconds. No dialog, no click, no waiting. The person at the desk never has to do anything to get their machine back.
• We take only what is free. A machine is eligible only when it has enough free memory to hold the model without displacing anything. A Houdini scene left open overnight makes that machine ineligible, or eligible only for a small model. We never swap anyone’s work out to make room for ours.
• Nothing listens on a workstation. The client on each machine dials out to its site node and nothing connects in. The site node never initiates a connection to a desk. A port scan of an enrolled workstation shows nothing new.
• The owner has the last word. A menu bar item, never a modal, lets anyone hold their machine for an hour, four hours or the rest of the day, for the case where it looks idle but is not, such as a long local render. Departments opt in. A production can declare crunch and exclude a whole show. You hold a kill switch for a site, a production or the whole fleet.

1. 1Enrolment through your MDM. A signed installer and a configuration profile, pushed by your existing device management in stages you control. The client reports free memory, GPU load, whether someone is present and which model, if any, is loaded. In the first version only wired Mac Studios and Mac Pros are enrolled; laptops wander, sleep and throttle.
2. 2One operated node per site. An Apple silicon node we run, in your server room, that receives requests, grants leases, caches model files and writes the audit log. It holds the only view of the fleet at that site, and it never connects out to a workstation. Workstations only ever dial in to it.
3. 3A request is classified by what the caller declares. Which model, whether the session is a single question, an agent loop or a batch job, how long the prompt is and how much output is allowed. From that the site node knows which machines are eligible by memory, how long the lease should last, and whether the session should stay on one machine to keep its cache warm. We infer nothing we could have asked for.
4. 4A lease is granted. One slot on one machine, for a bounded time, renewed by heartbeat. A machine that stops answering loses its lease and its work is re-queued elsewhere. A machine never holds a lease it has not renewed.
5. 5Long sessions go to the machines least likely to be reclaimed. Each machine’s own history, by hour of the week, gives the probability it will be claimed back during a lease. The site node picks the machine with the lowest one. This is a histogram per machine, not a model of a person, and it is explainable: when a wrangler asks why we chose a particular machine, there is an answer.
6. 6When the owner returns, we get out of the way in stages. Pause between tokens. Drop the working cache. Free the model weights. If any of that is slow, the watchdog kills the worker process outright and the operating system takes the memory back. The watchdog and the worker are separate processes precisely so that a worker stuck in a GPU call can always be killed. Work in flight is re-queued to another machine.
7. 7Models are placed ahead of demand. Getting a model onto a machine is slow (seconds from local disk, tens of seconds from the site cache over 10Gb Ethernet); routing a request to a machine that already has it is instant. So the site node keeps a warm set of each model across the fleet ahead of predicted demand, and routes into it. One model per machine, never split across machines, within a disk quota you set.
8. 8It learns from the fleet, not from people. Reclaim events are recorded per machine and aggregated by hour of the week, on your storage, with a retention period you set. That is what improves placement over time. It is never joined to a person or a directory.

A machine that can be claimed back at any moment is a batch computer, not a serving cluster. The work that suits it comes in small pieces, each safe to run twice, and there is a great deal of that in a studio. Interactive use comes later and only for short questions; anything latency-critical belongs on dedicated nodes.

Design commitments, not preferences. Each is testable.

• Never run alongside someone working. An idle GPU is not enough. On Apple silicon the CPU and GPU share one memory bus, so inference slows down an artist scrubbing 8K footage or a live audio session even when their own GPU use is near zero, and fans are audible in a mix stage. We run only when the machine is genuinely idle.
• Never displace an owner’s memory. If it is not free, we do not take it.
• Never split one model across workstations. Office Ethernet plus machines that come and go is the wrong place for it. One model, one machine.
• Never cross a site boundary. A prompt raised at one site is processed at that site, by machines enrolled with that site’s node. Batch work can follow the night around the world only where you say the data may travel.
• Never a dialog on a working screen. Nothing we do puts a window in front of a colourist’s reference monitor. A menu bar item and, at most, a notification.
• Never join usage data to a person. Machine-level histograms with a retention limit you set. No identifiers, no timelines, no link to your directory.
• Never update itself. Models and software change only when you activate a signed bundle. The previous version is kept.
• Never laptops, in the first version. Mac Studios and Mac Pros on wired Ethernet only.

Each control is a pilot deliverable, not a claim. You, your security team or anyone your content security programme nominates can run the test. The pilot fails if any test fails.

A shared workstation is not a sealed server

We would rather say this than have your security team say it for us. Anyone with administrator rights or physical access to a workstation can, in principle, read what it is processing while it processes it. macOS offers no isolated enclave in which third-party GPU work can run. So we do not pretend a workstation is a vault. Instead, where a prompt may run is decided by two things: how the content is classified, and what the machine can prove about itself.

The machine’s side comes from your MDM: whether the user has local administrator rights, whether FileVault and System Integrity Protection are on, the OS version, and which room and site the machine is in. A class of content maps to a set of machines that meet its posture. Unreleased material may map to a very small set, or to none, and that is a decision for your content security programme, not for us. The Trusted Partner Network assesses your vendors rather than your own systems, and we would be one of those vendors: we expect to be assessed like any other, and we document our controls against the MPA’s Content Security Best Practices from the start.

Usage data is monitoring data

A record of when each machine was idle is, in most of the countries you operate in, information about the person who sits at it. In Germany, technical systems that can monitor employee behaviour or performance are subject to works council co-determination, whether or not monitoring is the intent. The UK Information Commissioner publishes guidance on monitoring workers that expects a lawful basis and, for higher-risk monitoring, a data protection impact assessment. In California, employee personal information has been within the CCPA since 2023. We design for this rather than around it: histograms per machine, no timelines, no identifiers, a retention period you set, and no join to your directory. We would expect to sit with your works councils and your privacy office before enrolling any machine at a site where they have a say, and to bring the data schema with us.

Stated early, so you hear them from us first.

• We do not know the yield yet. How many machine-nights the fleet actually gives up, and how much work fits in them, depends on your idle patterns and your generation mix. The pilot measures it; this document does not estimate it.
• We do not know the reclaim time yet. How fast a Mac can hand back the memory a model occupies is the question the first two weeks answer. If it cannot be done inside the target you set, we tell you and stop.
• It is not a dedicated cluster. A machine that can be reclaimed at any moment has poor worst-case latency. Long interactive sessions and anything latency-critical belong on dedicated nodes; the shared fleet is for work that can wait a minute and run twice.
• Open models are not frontier models. The models that run on this hardware reason less well than the hosted frontier models. That is why the first workloads are exhaustive and checkable rather than judgement-heavy.
• It does not replace your render queue. Whether we run as a job type inside your queue or as a scheduler that yields to it is a decision for the pilot. Either way, the wranglers keep their authority over the machines.
• Older machines yield less. A 32GB machine holds small models only, and the fleet’s yield is uneven by generation. We report yield by machine class so you can see where it comes from.
• Some machines will never be eligible. Mix stages, screening rooms, machines with a scene left open, machines that sleep or sit at the FileVault unlock screen after an overnight update. Refusing them is correct behaviour, not a fault.
• The hardware has gaps, and we carry them. Apple silicon does not report memory errors, so model files are checksummed at load and re-verified on a schedule. The operated site node is our responsibility, including its spare.

Each phase ends with a measurement you can read, and the next phase starts only if you are satisfied with it. The first phase is small enough to stop without embarrassment on either side.

1. 1Measure, on one machine, in two weeks. One Mac Studio, yours or ours. Load a model of the size we intend to run, simulate the owner’s return under a real Houdini, Resolve or Blender load, and measure the time from presence signal to memory returned, both for releasing the model in place and for killing the worker outright. We also establish whether macOS gives a foreground application priority over background GPU work, or whether yielding is entirely our job. The gate: reclaim inside a target you agree before we start. If it fails, we tell you why and stop.
2. 2Pilot, on about twenty machines, in six to eight weeks. One site, one department that has opted in, one batch workload; we propose transcription of a slice of the archive. Enrolled through your MDM, run at night and at weekends, every lease and every reclaim logged. The owners of the machines know it is happening and know how to hold their machine. Every control in section 7 is tested during this phase.
3. 3Read the numbers together. Interruptions, reclaim times, machine-nights used, work done, yield by machine class. The results are yours whether or not you continue.
4. 4Then widen, one step at a time. A full site. Then short assistant questions on the same fleet. Then further sites, each with a site node of its own and the same measurements. Restricted content, if it is ever in scope, comes last and only with your content security programme’s sign-off on placement policy.

How we would be measured

• Site node: $2,100 a month per site, including one operated node, updates, monitoring, a spare, and workflow development.
• Enrolled workstations: a per-machine monthly rate, agreed after the pilot has measured yield by machine class. We would rather price against measured capacity than against a guess, and you would rather not pay for machines that yield nothing.
• Measurement and pilot scope and fees to be agreed in writing before either starts.

Your existing hosted AI arrangements are separate and unaffected. The workstations remain yours; we never take custody of them or of anything on them.

The answers change the scope, so we would rather ask than assume.

• Is the goal to get value from machines already paid for, or to get on-premise capacity? If it is capacity, a dedicated pool built from the Mac Studios each refresh retires may be simpler than sharing live desks, and we would say so.
• Which workloads first: the archive and other batch work, an assistant for employees, or both?
• Which fleet: one studio’s machines or the whole company’s? Which business units, and do they share an MDM and an IT team?
• Which MDM do you run, and do you use an overlay network (Tailscale, Zscaler, Cloudflare WARP, Netskope or similar) as part of device management? That decides what ‘local network’ means and how we keep sites apart.
• Which render queues are in use, and who decides which machines are available when? Should we be a job type inside the queue, or a scheduler that yields to it?
• Does unreleased content need to go through this at all? The answer decides whether placement by device posture is a feature or a reason to keep the shared fleet away from that work entirely.
• Which sites have works councils, and who speaks for your privacy office?
• What are the energy-saver and overnight update policies on the fleet? Machines that sleep, or that wait at the FileVault unlock screen after a reboot, yield nothing until someone logs in.
• Roughly how many machines are there at each memory size?

All sources checked on 23 September 2026.

• Apple, Mac Studio technical specifications
• Apple Newsroom, new Mac Studio with M5 Max and M5 Ultra
• Apple, Mac Studio (2022) technical specifications
• HTCondor, publications (Condor: A Hunter of Idle Workstations, 1988)
• HTCondor manual, HTCondor’s power (owner returns, job migrates)
• Apple Newsroom, Apple previews Xgrid technology (2004)
• Germany, Betriebsverfassungsgesetz §87
• Bundesarbeitsgericht, 1 ABR 20/21 (systems objectively capable of monitoring)
• UK Information Commissioner’s Office, employment practices: monitoring workers
• California Privacy Protection Agency, CCPA FAQ (employment exemption expiry)
• Trusted Partner Network, FAQs
• Motion Picture Association, content security best practices