Morpheus Consumer Node on Mac: Private AI Inference on Apple Silicon
Set up the Morpheus desktop app on Apple Silicon. The first consumer AI tool where the provider's machine has to prove your prompt wasn't read or logged before the session opens. v7.0.0 walkthrough.
What you are building
Every prompt you send to ChatGPT or Gemini is read by the platform, logged, and (depending on your account settings) used to train the next model. Even with the privacy-friendly options like Claude or Venice, you still have to take the company’s word that they aren’t peeking. There is no way to actually check.
Morpheus v7.0.0 (released 23 April 2026) is the first consumer-grade AI tool where you can. When you send a prompt, your computer demands a fresh hardware certificate from the machine on the other end before the session opens. The certificate proves that the AI is running inside a sealed environment the operator can’t see into, and that nothing is being logged. If the certificate fails to verify, the session never opens.
This walkthrough covers setting up the consumer desktop app on an Apple Silicon Mac, sending your first prompt, and turning on the hardware-attested mode now that v7.0 has made it usable. I have been a Morpheus capital provider since launch, but the consumer side is what most people will interact with.
A consumer node runs three pieces of software locally: the proxy-router (the same Go binary providers run, with different environment variables), the MorpheusUI (an Electron desktop app with a chat interface and built-in walletWalletSoftware that stores the private keys needed to control tokens on a blockchain. A wallet does not actually hold any tokens. The tokens live on the chain. The wallet holds the keys that prove you own them.Like the key to a safe deposit box. The key doesn't contain your valuables. The valuables sit in the bank's vault. The key is what proves you're allowed to open the box and take them.Read more →), and optionally a local llama.cpp instance for free testing. No GPU. No model server. No on-chain registration as a provider. The whole privacy story below is built on the TEETEETrusted Execution Environment. A hardware-secured region of a CPU or GPU where code runs in isolation, so even the machine's operator can't read what's happening inside. TEEs give decentralised AI inference privacy guarantees.Like a bank vault inside a bank. The bank owns the building, staffs the lobby, and runs the security cameras. But what's inside the vault is invisible to everyone, including the bank staff, unless the customer opens it.Read more → stack, which is jargon for “a sealed compartment inside modern Intel and NVIDIA chips that can prove what code is running inside it without revealing the data.”
Consumer vs provider node
| Consumer | Provider | |
|---|---|---|
| Hardware | Any modern Mac | GPU + sustained power |
| What it runs | proxy-router + UI | proxy-router + model server |
| On-chain registration | None | Provider + bid + model |
| MOR flow | Spends MOR on sessions | Earns MOR from compute pool |
| TEE-tagged role | Receives Phase 2 guarantees | Must deploy to SecretVM |
| Setup time | ~30 minutes | ~half a day plus hardware build |
The setup we already published covers the provider walkthrough in full. This article is for the other side of the marketplace: the people sending prompts.
Why v7.0 matters
Think of the provider’s machine as having two parts: the routing software that takes your prompt off the network, and the AI model that actually answers it. Morpheus v6.0.0 (March 2026) let you verify the first part. The second part, the bit that reads your prompt and generates the response, was still a black box. You had to trust the operator.
v7.0.0 closes that gap. When you send a prompt to a v7.0-tagged provider, three things happen behind the scenes before you get a reply.
- Your prompt is sealed before it reaches the AI. The receiving end is a hardware-protected vault inside the provider’s CPU and GPU. Even the operator running the server can’t peek inside it.
- The vault has to prove it’s the real thing. The CPU produces a cryptographic certificate saying “I am a real sealed environment, and I am running this exact code.” The GPU does the same for the AI model itself. A fresh random number, generated by your computer for that one session, ties the two certificates together. That stops the operator reusing an old certificate from a previously honest setup to fake a new one.
- The logs are physically nailed shut. When the provider deploys in production mode, the ability to log your prompts is sealed off at the hardware level. The operator can’t switch logging back on without breaking the certificate that proves they’re a real provider, and your computer would refuse the next session.
If any link in that chain fails, the session does not open. A misconfigured or compromised provider cannot accept your prompt without you knowing.
Under the hood
For readers who want the implementation specifics: the chain combines an Intel TDX CPU quote (the sealed environment is called a TDX enclaveEnclaveAn isolated region of CPU or GPU memory protected by hardware. Code and data inside the enclave are inaccessible to the operating system, the hypervisor, or even the machine's physical owner.Like a secure room inside a much larger office building. The building's caretakers have keys to every other room but not this one. What happens inside is invisible to them by design.Read more →), NVIDIA NRAS GPU attestationAttestationA cryptographic proof that a piece of code is running on a specific hardware enclave in an unmodified state. Attestation lets remote users verify that a service is genuinely running what it claims to be running.Like a tamper-evident seal on a medicine bottle. The seal itself doesn't make the medicine safe, but it gives you a way to verify that nobody opened the bottle and swapped the contents before you bought it.Read more → for the model itself, an anti-replay nonce binding the CPU and GPU evidence together, TLS certificate pinning between consumer and provider, and a workload measurement (RTMR3) that proves the loaded model weights match what the operator declared on chain. Logging is locked off at deploy time inside the SecretVM image and cannot be re-enabled at runtime without invalidating the attestation. Per-prompt fast-verify lands at roughly 50ms.
The forward-compatibility design is the other half of the story. Any v6.0.0+ consumer routing to a v7.0.0+ TEE-tagged provider gets full Phase 2 guarantees automatically. No client upgrade required. The on-chain tee model tag is the single switch that turns the whole chain on.
For comparison, here is roughly where the major consumer AI options sit on a privacy spectrum.
Consumer AI privacy spectrum
What you need before you start
This is a beginner walkthrough but you do need a small amount of capital. Plan for the equivalent of about $20 to $30 in MOR plus a few dollars in ETH for gas on BASE. That covers your first few sessions and leaves headroom.
The hardware list is short:
- Apple Silicon Mac (M1, M2, M3, or M4). Any modern config works since the consumer doesn’t run inference locally. I run a Mac Studio M4 Max with 64GB RAM, but anything with 8GB+ is fine.
- macOS recent enough to run Electron 27+ (Sonoma 14 or newer is comfortable).
- A wallet you control. MetaMask is fine. If you bring an existing wallet, use the tier 1 address (the first one derived from your mnemonic), not a secondary derived address. Recovery from mnemonic doesn’t work properly for derived addresses.
- ETH on BASE for gasGasThe fee paid to a blockchain to process a transaction. Gas is denominated in the chain's native token and varies with network demand. Sending a transaction without enough gas means the transaction fails and the gas is still consumed.Like the petrol that powers a car. You need to put petrol in to make the engine run. The amount of petrol you need depends on how far you're driving and how much you're carrying. If you run out, the car stops.Read more →. A few dollars worth.
- MOR on BASE for sessions. The minimum to open a session is 5 MOR.
If you don’t already hold MOR or ETH on BASE, get those before you launch the desktop app. It is much smoother than trying to bridge mid-install.
Acquiring MOR and ETH on BASE
Two fragments you need on the same chain. ETH on BASE is easy: Coinbase will withdraw directly to a BASE address with no bridging cost, or you can bridge from Ethereum mainnet via the official BASE bridge. Aim for at least $5 of ETH on BASE in your wallet before doing anything else.
MOR is DEXDEXDecentralised Exchange. A trading venue where token swaps happen entirely through smart contracts, with no central operator holding user funds. The largest DEXes are Uniswap, Aerodrome, Raydium, PancakeSwap, and Curve.Like a self-service vending machine that lets you swap one type of coin for another. The machine sets the exchange rate based on its current stock, anyone can deposit coins to refill it, and there's no clerk behind the counter.Read more →-traded on BASE. The two main venues are Uniswap V3 and Aerodrome. Liquidity is thin so size your buy with that in mind. A purchase of $30 to $50 will move the price slightly. A purchase of $5,000 will move it a lot. Use the Uniswap or Aerodrome UI directly with slippage set to 1-2% for small buys.
Confirm the contract address before you trade. The MOR token on BASE is 0x7431aDa8a591C955a994a21710752EF9b882b8e3. Token-name spoofs are common on every chain; copying the address from a project’s official page (mor.org) is the only reliable check.
Installing the desktop app
Go to the v7.0.0 release page and download the Apple Silicon build:
mac-arm64-morpheus-app-7.0.0.dmg
There is also a separate full bundle (zip with mor-launch, mor-cli, proxy-router, MorpheusUI.app) for users who want CLI access. The DMG is the simpler path. Mainnet builds have no version suffix; testnet builds end in -test. You want mainnet.
Open the DMG. The first time you launch the app, macOS will quarantine it because the developer signature is from an open-source project, not the Apple Developer Program. Open Terminal, navigate to where you installed it, and clear the quarantine flag:
xattr -c MorpheusUI.app
If you used the zip bundle instead of the DMG, you’ll need to run the same command against mor-launch, mor-cli, and proxy-router as well.
Launch the app. You will see three startup steps in order: the proxy-router process binds to localhost:8082 for the management API and localhost:3333 for the routing layer, the UI window opens, and the wallet flow begins.
First-run wallet flow
The UI walks you through:
- Read and accept the terms.
- Set a strong password. This is local to MorpheusUI only, not your wallet password. It encrypts your local session state.
- Either create a new wallet (the UI generates a fresh mnemonic) or recover an existing wallet from a mnemonic. Save the mnemonic somewhere durable. The wallet lives on BASE; you can move funds in and out using any compatible wallet by importing the same mnemonic.
A few minutes after the wallet is set up, the UI should show your ETH and MOR balances. If you funded the wallet ahead of install, the balances appear immediately. If you funded it after, refresh and they will update on the next block.
Opening your first session
In the chat window, click Change Model. You’ll see a list of available models from remote providers, identified by their on-chain contract address.
This is where the tee tag matters. Look for models tagged tee on chain. Those are the ones that activate the full Phase 1 + Phase 2 attestation chain when you open a session against a v7.0.0+ provider. If a model isn’t tee-tagged, you still get the encrypted P2P session that’s been there since v5.x, but you don’t get hardware attestation.
Consumer flow, end to end
Pick a model, click Change, then Open Session. The UI will prompt you for the amount of MOR to commit. The minimum is 5 MOR. The provider draws this down at their advertised price per second as the session runs. When you close the session, unused MOR returns to your wallet.
If the provider you chose is on v7.0.0 and TEE-tagged, the session opens only after Phase 1 attestation succeeds. If attestation fails, the session won’t open at all. That’s the safety property: a misconfigured or compromised provider can’t accept your prompt without you knowing.
What to verify
Three things tell you the install is working:
- Swagger API responds. Visit
http://localhost:8082/swagger/index.htmlin a browser. You should see the proxy-router’s API documentation. If the page loads, the router is alive and listening for blockchain events. - Chat round-trips work. Send a prompt to the model. You should see the response stream back in the chat window. Latency depends on the provider you chose.
- The session is visible. In the chat window, click the time icon next to the model line. You should see your active session with the amount of MOR committed and the time remaining.
For TEE-tagged sessions, the v7.0 release also exposes a per-model attestation endpoint at GET /v1/models/attestation. Hitting that endpoint shows the verification state for each TEE-tagged model the provider you connected to is serving. verified means Phase 2 fast-verify is active; pending means initial attestation is in progress; failed means something is wrong and prompts will be refused.
Limits and gotchas
A few things you’ll trip over.
TEE provider supply is the real constraint. v7.0 doesn’t auto-upgrade existing providers. Each provider has to opt in by deploying the v7.0 TEE Docker compose into a SecretVM (Intel TDX hardware via the Secret Labs partnership). The Phase 2 plumbing is shipped, but how many TEE-tagged providers actually exist on a given day is a real variable. Check the on-chain marketplace before assuming a TEE-tagged session is available for the model you want.
The api.mor.org gateway is a separate path. If you don’t want to run the desktop app and just want OpenAI-compatible API access, the api.mor.org gateway is an option. Whether the gateway routes to TEE-tagged providers and inherits Phase 2 guarantees is undocumented at the time of writing. If hardware attestation matters to you, run the desktop app and verify the attestation endpoint yourself.
Closing sessions matters. When you close the UI, the proxy-router process keeps running in the background terminal window. That’s by design. Hit Ctrl+C in the terminal to fully stop it. If you don’t, your active sessions stay open and continue drawing down committed MOR.
Tier 1 wallet only when recovering from a mnemonic. If you have an existing MetaMask wallet with multiple derived addresses, recover the tier 1 (first) address only. Recovery doesn’t reliably work for derived addresses.
Resetting cleanly on Mac. If you need to start fresh, after closing the UI run:
rm -rf ~/Library/Logs/morpheus-ui
rm -rf ~/Library/Application\ Support/morpheus-ui
Save your mnemonic first. Without it, you can’t recover the wallet you set up.
My take
Fact: v7.0.0 closes the GPU attestation gap that the Morpheus project review explicitly flagged. Phase 2 is real, the release notes hold up against the source code, and the SecretVM partnership is documented.
Take: This is the cleanest consumer path to hardware-attested private AI inference I’ve seen on a Mac. Not because the install is friction-free (it isn’t, the wallet bootstrap and the small MOR purchase are real steps) but because no other mainstream-accessible AI tool gives you a verifiable cryptographic answer to “did this provider actually keep my prompt private”. Venice is close on policy, but Morpheus TEE is the only one with hardware attestation you can verify yourself.
The honest constraint is provider supply. Phase 2 attestation only protects you against providers who actually deployed the v7.0 TEE image. Until enough providers opt in, the menu of TEE-tagged models will be smaller than the menu of plain-tagged models. That gap closes as providers upgrade. It doesn’t close on day one.
I’m running the install on my Mac Studio next. I’ll annotate this article with anything that diverged from the docs once I have first-hand notes.
For the project context behind this guide, see the Morpheus review and the tokenomics breakdown.