mfabric.

Peers

Download the signed Windows installer or the manual zip on each helper device, verify the SHA-256 hash, run the installer or peer launcher, choose Helper / peer, paste the join link, and approve the peer on the host.

Windows PowerShell

Get-FileHash -Algorithm SHA256 .\mfabric_peer_setup_*.exe
Get-FileHash -Algorithm SHA256 .\mfabric_public_beta_peer_current.zip

Good manual-zip extract locations

~/mfabric_public_beta
~/Downloads/mfabric_public_beta
%USERPROFILE%\Downloads\mfabric_public_beta

Avoid

If you use the manual zip, do not run from inside a compressed-zip viewer. Do not extract into system folders such as /usr, /System, C:\Windows, or C:\Program Files.

macOS / Linux

python3 -m pip install -r requirements-agent.txt
python3 mfabric_peer_bootstrap.py --join-url PASTE_HOST_JOIN_LINK --detach

Cellular

Put the host gateway behind a private mesh tunnel or authenticated HTTPS endpoint. Start the gateway with exact-origin CORS and bearer-token auth, then enter that URL in the phone client.

Verified adapter row

The host package may show a model-specific verified row when that adapter has passed its own validation. Treat each model family separately.

Advanced host controls

If a private host build exposes an experimental path, it should document that path separately from this public manual.

Revoke

Use the host control panel when a device should no longer be trusted. Open the credentials table, find the peer, and choose Revoke.

Memory-sharing availability

Memory-sharing keeps your older context alive instead of silently dropping it. When local memory fills up, stale context you are not actively using moves into pooled memory on approved helpers, so your context is maintained without losing the old one. Because the pool holds stale context, this is a continuity feature, not a speed feature. It is an opt-in preview in this build.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the memory-sharing option.
3. The console returns a status message. If it says “not available in this build”, the serving path for this experiment is not active yet.
4. Alongside the boundary, Check availability prints a capacity readout — this machine’s GPU memory, how many approved helpers you have, and the estimated pool — so you still get a real answer about your setup.
5. This capability is being hardened; check the release notes for when it becomes a default option.

2Big2Fit (split model) availability

2Big2Fit lets you run a model too big for one machine by splitting it across your devices: the host distributes the model across multiple trusted machines for capacity experiments when no single machine has enough memory.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the 2Big2Fit (split model) option.
3. The console returns a status message. If it says “not available in this build”, the serving path is still a preview and not active by default.
4. Alongside that boundary, Check availability prints a capacity readout for your actual setup: the model size vs this machine’s GPU memory, approved helpers, the estimated pool, and a fits / too-big verdict with a recommendation.
5. This capability requires approved helpers with compatible hardware and is being hardened; treat it as an experiment, not a production path.

Peer does not show up

• An approved peer is counted immediately (the approved-helpers count goes up); its own card appears once its runtime reports presence. A missing card right after approval is normal.
• Confirm the peer window is still open.
• Confirm the join request was approved on the host.
• Check local firewall prompts for Python.
• Re-copy the join link and run the peer launcher again.

Peer shows up but does not work

• Some peers are storage-only.
• A peer may be low battery, active, offline, or not eligible for compute.
• The workload may require a specific host-side adapter.
• If fallback events appear, the host is recovering from a peer miss or unavailable worker/path.
• Keep the workload on the standard safe default unless the host operator explicitly enables an experimental path.

Transfer rate is zero

That is normal when no workload is moving data. Run a workload or block-transfer test to see activity.

Pooled memory looks small

MFabric displays the storage budget allocated to the fabric, not every byte of physical RAM on every peer. The context estimate is a planning tier, not a promise that every model can use that much context.

Connecting another computer

Adding a second machine takes three steps. The join link is the only path that adds a machine in this beta — there is no add-by-address box.

1. On this computer’s console, open + connect another computer (near the bottom of the page). It shows this machine’s join link and a ready-to-copy join command.
2. On the OTHER machine, from its extracted mfabric_public_beta folder, run the copied command: python3 mfabric_peer_bootstrap.py --join-url <this computer's join link> --detach
3. Back on this console, the machine appears under Waiting for approval — press Approve. The approved-helpers count updates immediately; the machine’s own card appears once its helper runtime starts reporting in.

Using the native runtime route for dense models

The native runtime route is a faster local execution path for dense Qwen2 and Qwen3 models with a hidden size up to 2048 (roughly 3B parameters and below). Models above that size use the standard path automatically.

This route is validated in the closed release tree but is not included in the currently published helper zip or Windows installer. Those downloads use the standard path (you will see runtime_route: hf_generate) until the trusted-signed closed binary refresh is published.

1. Scan your local models using the Load a local model panel. Entries that cannot load are greyed out with the reason: not a chat model (speech/embedding), config only — weights not downloaded, or won't fit — needs ~X GB, GPU has Y GB.
2. Select a dense Qwen2 or Qwen3 model and press Load.
3. Send a chat prompt. When the model answers, the response details line shows a runtime_route field such as qwen2 or qwen3 for the native path, or hf_generate for the standard path.
4. You do not need to configure anything. The console picks the native path automatically when the model qualifies, unless you set MFABRIC_PUBLIC_DISABLE_NATIVE_RUNTIME=1 to force the standard path.
5. Larger models (hidden size above 2048, such as 7B+ dense Qwen) use the standard path automatically; the response details will show hf_generate for those.

Checking memory-sharing availability

Memory-sharing keeps your older context alive instead of silently dropping it: stale context moves into pooled memory on approved helpers, so your context is maintained without losing the old one. Continuity, not speed. It is an opt-in preview in this build. Full steps are in the Experiments section above.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the memory-sharing option.
3. The console will return a status message. If it says “not available in this build”, the serving path for this experiment is not active yet.
4. Alongside the boundary, Check availability prints a capacity readout — this machine’s GPU memory, how many approved helpers you have, and the estimated pool — so you still get a real answer about your setup.
5. This capability is being hardened; check the release notes for when it becomes a default option.

Checking 2Big2Fit (split model) availability

2Big2Fit (split model) experiments run a model too big for one machine by splitting it across trusted devices when no single machine has enough memory. Full steps are in the Experiments section above.

1. Open the host console and go to the Experiments section.
2. Click Check availability next to the 2Big2Fit (split model) option.
3. The console returns a status message. If it says “not available in this build”, the serving path is still a preview and not active by default.
4. Alongside that boundary, Check availability prints a capacity readout for your actual setup: the model size vs this machine’s GPU memory, approved helpers, the estimated pool, and a fits / too-big verdict with a recommendation.
5. This capability requires approved helpers with compatible hardware; treat it as an experiment, not a production path.

Understanding the streaming indicator and TTFT

The chat panel can stream tokens as they arrive rather than waiting for the whole answer. This makes responses feel faster even when total generation time is the same.

1. Send a prompt in the chat panel.
2. A streaming badge appears next to the response header only when tokens are arriving in real time. An answer that arrives all at once (buffered) shows no badge — that is the normal delivery in this build, not an error or a downgrade.
3. When an answer streams, a TTFT readout (time to first token, in milliseconds) shows how long the console waited before the first token appeared. A lower number means a faster response start.
4. Buffered delivery happens when the model or peer does not stream token-by-token, or when the whole answer arrives before the first render cycle. Nothing is wrong; only the on-screen typing effect differs.
5. Both modes produce the same answer. Streaming only changes when characters appear on screen.

Checking live device telemetry

The telemetry panel shows real-time GPU memory, CPU load, and health for every approved device in your fabric.

1. Open the host console in your browser.
2. Scroll to the Telemetry section (or click its link in the capabilities panel).
3. Each device card shows GPU memory used, CPU percent, and whether the device is currently online.
4. The small sparkline graph shows recent GPU memory use over time.
5. If no telemetry appears, the device may be offline or not yet approved.

Running a batch of prompts

The batch panel runs several prompts at once and returns one result list.

1. Open the host console and go to the Agent swarm or batch panel.
2. Type or paste your tasks, one per line, into the task input box.
3. Press Run. Each task is sent in parallel and tracked as a separate row.
4. When all tasks finish, each row shows the answer, the tier it used, and how long it took.
5. Press Clear to reset the list before the next batch.

Checking for a newer version

MFabric does not check for updates automatically. Use this step to check manually whenever you want.

1. Open the host console.
2. Click Check for updates in the header bar, or open the Check for a newer version capability panel and press Check for update.
3. The console fetches the public update manifest. No device info, model list, or local paths are sent.
4. If a newer build is available, the status line shows the version number and where to download it.
5. If you are already on the latest build, the status line confirms that.

Five steps to your first chat

1. Check the environment: mfab doctor
2. Start the host: mfab host start --detach
3. List local models: mfab models list
4. Load a model: mfab models load <model-ref>
5. Send a prompt: mfab chat "What does MFabric do?"

Quick start (from --help)

python mfab_cli.py doctor        check this machine is ready
python mfab_cli.py host start    start the console
                                 (Ctrl+C stops it; --detach = background)
python mfab_cli.py host open     open the console in your browser
python mfab_cli.py chat "hello"  talk to the loaded model

on another computer:
python mfab_cli.py helper join <join-url from the host console>

Available commands: doctor · host · helper · peers · models · chat · gateway · update · logs · config · experimental.

Stream tokens

mfab chat --stream "Summarize what a private fabric does"

Tokens appear as they arrive instead of waiting for the full answer.

Check for updates

mfab update

Fetches the public release manifest. No device info, model list, or local paths are sent.