A little preparation. A lot more room.

Your first connection. Your next idea.

A practical overview of the current workflow. Prepare compatible Macs, review what runs, and keep every result tied to the saved files it checked.

01. Start with compatible Macs

Use the native app on Apple silicon with macOS 26 or later. The service and command line also support Linux. Build each worker group with the same operating system and architecture as its coordinator. For a Mac setup, start with the Mac you edit on and one compatible spare Mac.

Install matching copies of the app and service and the tools your reviewed checks need. The editing service resolves the executable first; the worker needs it at that same absolute path. Stackintosh transfers saved source, not your toolchain or an automatic dependency installation.

02. Choose what each Mac shares

Configure capacity in the service’s macbridge.toml file. Keep heavy_slots at zero on the editing Mac; offer the slots and memory budget you choose on each worker. Power, thermal, memory and fresh-reading requirements decide when work begins. For Linux workers, set pause_new_jobs_on_serious_thermal_state to false because this service does not supply Linux thermal readings.

Define named task profiles outside the project being checked. Review each executable, argument, environment value and memory estimate. A project’s source never chooses the command. Validate the file with macbridge config validate before starting the service.

03. Make a trusted connection

Enable Remote Login for the intended worker account. Configure a dedicated SSH identity and verified known-hosts file on the editing Mac. Verify the worker’s host-key fingerprint directly on that worker before trusting it. Authentication must work without a password or passphrase prompt; the service does not use an SSH agent.

Add each worker under its own durable remote_worker identity in macbridge.toml. Use the actual verified host name or address and absolute identity and known-hosts paths without spaces. Bonjour finds nearby candidates; it does not verify, trust or pair them. SSH configuration aliases are not read by this transport.

04. Bring the service online

In the app’s Settings, enable Background operation on each Mac. If macOS requests approval, allow the background item in System Settings, return to the app, and choose Check again. Allow Local Network access when needed for nearby discovery.

Connected means the app can reach its local service. Ready in Workers separately describes a configured worker. For later configuration changes, validate the file, let accepted work finish, and deliberately restart background operation on the affected Mac. Closing and reopening the app does not reload service configuration.

05. Review. Save. Run.

Add the top-level folder of a supported Git worktree. Save your edits, choose New Check, select the project and a reviewed profile, then run it. You do not need to commit first: saved staged and unstaged changes and untracked files Git does not ignore are captured. Unsaved editor buffers are excluded.

A check runs in its own materialised workspace on one worker. Follow its output in the app or terminal; the result identifies the exact saved files it checked. Later edits do not change that record. A queued check waits for the resources it requires. If contact with a worker is lost, its attempt stays Unknown until reconciled.

06. Know what GPU support means

Stackintosh reports detected Apple, NVIDIA, AMD and Intel GPUs and installed and serving drivers. A reviewed profile can require a GPU kind and optionally name a serving driver. Every GPU request needs a device with a serving driver; an installed but inactive driver is not enough.

After all admission rules pass, the matching GPU is reserved exclusively for one check. The check’s own runtime determines how it uses that GPU. Detection does not install a driver, verify a compute backend or make an incompatible worker eligible. Apple silicon/macOS coordinators cannot use an arbitrary NVIDIA/Linux worker.

07. The inference roadmap

Distributed model inference is a proposed future feature. No distributed inference engine is integrated in the current build, and no engine or Rust compute library has been selected. Today, Stackintosh distributes independent development checks, with each check running on one worker.

The documented first target is one fixed decoder model, a specified weight and quantization format, and consecutive layer groups on two compatible Apple silicon Macs. Correct execution on one worker comes first. NVIDIA and AMD backends require their own implementation and physical verification before support can be claimed.

A future distributed session would need explicit trusted participants, verified model identities, whole-session memory reservations, authenticated tensor transport and honest interruption handling. More machines would not by itself promise greater speed. These are acceptance requirements for future work, not features available today.

08. A useful support request

Include your app and macOS versions, whether the local service is Connected, the worker’s status and the specific error or waiting reason. Remove private source code, passwords, SSH keys and tokens before sharing logs. Use the email link below for help or questions about development access.

Email Brandon