Feed it a prompt.
A familiar API. Developer access is coming.
iMunch
Your Mac is
hungry for more.
AI inference on participating Apple devices.
Market rates. A little spare compute. A lot of appetite.
We’re building an API for developers and a way for Mac owners to put spare capacity to work.
Still in the kitchen. Public access and provider payouts aren’t available yet.
You bring
the Apple.
We bring the appetite.
Your Mac can already run AI models. We’re exploring how developers could tap into that compute through one API.
Bring your Mac.
Spare Mac compute. Rates and access to come.
Pass the plate.
Route requests. Bring the answers back.
Born to munch.
Currently pre-launch.
Good compute.
Clear costs.
Developers would pay for AI requests. Device owners would get paid for completed work.
What you’d pay
AI requests would be priced at market rates, based on the model and work involved. We haven’t published prices yet.
How you’d get paid
We’re designing payments for completed tasks. Payouts aren’t built yet, and there’s no earnings estimate.
And yes, there’s a token idea.
We’re proposing an iMunch token for the network. Its role in payments, rewards and settlement is still being worked out.
What about token value?
A token’s market price is separate from the cost of an AI request. No token value, investment return or level of income is promised.
A few more detailsSmall bites.
Real code.
A bigger appetite ahead. We’ve got a prototype to build on; now we’re testing the pieces together.
ALREADY IN THE KITCHEN
The first ingredients.
- An app for participating Apple devices
- Apple’s on-device text models connected
- A relay to route AI requests
- Signed device requests and task records
Prototype code, still being tested. Recorded earnings haven’t been paid out.
NEXT ON THE MENU
One request.
One Mac.
First, a repeatable demo with a checked result. Then more work on speed, answer quality, device impact and payments.
We plan to start with a small Mac pilot. There’s no public launch date yet; iPhone and iPad support need more testing.
UNDER THE HOOD
From prompt
to munch.
An API, a relay and an Apple device. Here’s how the prototype connects them.
The request-to-response path has been verified in a local test with one Mac and one relay. This is an architecture walkthrough; public access and a distributed network are still ahead.
- 01
Send a request.
The Go relay exposes an OpenAI-style chat-completions route. It checks a bearer API key, converts the messages into a text job and puts that job in a queue.
- 02
Find a worker.
An Apple device registers with the relay and polls for work. The relay assigns a job and a claim token; the device claims it before running the task.
- 03
Munch locally.
The Swift app checks whether Apple’s system model is available, then uses LanguageModelSession to generate text on the device. It submits the answer and timing information to the relay.
- 04
Return the answer.
The relay checks the assigned node and claim token, stores the result in SQLite and returns a chat-completion response. Calculated earnings are recorded as pending; no payment happens yet.
Developers, device owners and relays
For developers: AI requests through a familiar API, at market rates. Access is still in development.
For device owners: we plan to pay for completed compute tasks. Rates and access are still being worked out.
For relay operators: help requests find a device and bring the answers back. The relay prototype needs more testing.
A familiar request.
An on-device model.
The prototype includes /v1/chat/completions, /v1/models and an unfinished embeddings route. The text worker uses Apple Foundation Models on compatible hardware.
The request format is OpenAI-style; full API compatibility is not ready. Model selection and parameter handling need validation, streaming is not implemented, and the embedding worker does not yet produce vectors. A supported-model list will follow testing.
The first target is a small Mac pilot. Mobile background execution, model availability and device impact need separate testing before broader device support.
POST /v1/chat/completions
Authorization: Bearer <api-key>
Content-Type: application/json
{
"model": "<pilot-model-id>",
"messages": [
{
"role": "user",
"content": "Summarize this note."
}
]
}The key and model ID above are placeholders. No public API endpoint, SDK release or credentials are available yet.
iMunch
Pilot in development
- Model
- Apple Foundation Models
- Workload
- Text requests
- Public access & payouts
- Not enabled
Concept preview, not a screenshot of a live service.
SECURITY & TRUST
Security,
layer by layer.
Some checks are already in the code. Others need to be built before public access. Here’s the distinction.
IN THE PROTOTYPE
A key for each node.
The app uses CryptoKit’s Ed25519 signing keys and stores the private key in Apple Keychain. The relay verifies signed request headers to identify the node key.
This authenticates a key. It does not prove that a device runs an untampered app or returns a correct answer.
IN THE PROTOTYPE
Checks at the API.
Developer routes check bearer API keys against SHA-256 hashes stored in the relay database. Node requests include a timestamp and nonce, with a time window and an in-memory replay check.
Stronger replay handling, rate limits and signatures that cover the request body still need work.
STILL TO BUILD
Private from end to end.
The current relay can read prompts and responses. End-to-end encryption that hides that content from the relay is a design goal, not a feature in this prototype.
HTTPS protects a network connection; it does not hide content from the relay. Production TLS and data-retention controls also need to be configured and tested.
STILL TO BUILD
Know what’s running.
App and device attestation would help establish which software is doing the work. The current node signature alone does not provide that assurance.
Authentic-app verification and protections against untrusted workers remain part of the security roadmap.
PARTLY IMPLEMENTED
Check the result.
The relay checks job ownership and a claim token. Separate result signatures are recorded, but the result handler does not validate those signatures or verify answer quality.
Payload verification, reliable job assignment and duplicate-safe completion accounting are needed before accepting paid work.
PROPOSED
Settle real work.
Today’s earnings records are local accounting entries. Customer billing, token transfers and provider payouts are not implemented.
The proposed iMunch token’s settlement rules and any smart contracts still need to be designed, tested and reviewed. There is no on-chain payment guarantee.
Before public access: verify the end-to-end flow, test untrusted and duplicate submissions, strengthen privacy and operational limits, and review the payment design. These are engineering tasks still ahead, not security certifications or completed audits.
A network
in the making.
Macs, relays and developers, working together. Follow a request through the prototype, then see the network we’re proposing.
Verified local prototype path Proposed network expansion
Your appOpenAI-style request
Request down · response back
RelayQueue · route · store
Claim a job · return a result
Mac workerApple Foundation Models
PROPOSED EXPANSION
More independently operated relays and provider-owned devices. Discovery, coordination and broader device support still need work.
Your app sends a text request to the relay’s OpenAI-style API. The relay checks the API key and queues a job.
The solid path has been tested with one Mac and one local relay. The dashed network is a proposal, not a deployed multi-relay system. This illustration does not measure locations, capacity or live activity.
Devices
Run a supported model.
Relays
Route jobs and return results.
Developers
Send requests through an API.
A small Mac pilot comes first. Broader participation still needs testing.
Hungry
for details?
Can I use iMunch today?
Not yet. The API and device app aren’t open to the public. We’re building and testing the prototype first.
Will it work on my device?
We plan to start with a small Mac pilot using Apple Foundation Models on compatible hardware. We haven’t published a supported-device list yet. iPhone and iPad support need more testing, especially in the background.
What will it cost, and could my Mac earn?
We’re aiming for market-rate AI requests and payments to device owners for completed work. Prices, fees and payout rules are still being worked out. We can’t give you an earnings estimate or promise a minimum income.
What is the proposed iMunch token for?
We’re proposing our own token as part of payments and rewards. Its exact role, chain and settlement rules are undecided. The prototype has no token payments, and no tokens are offered for sale here. A token’s market price is separate from the price of compute; no token value or investment return is promised.
How does privacy work in the prototype?
The current relay processes request and response content. Encryption that hides content from the relay is not implemented. Privacy controls, result checks and security still need work before public access.
What is iMunch building?
A network that connects developers with inference on participating Apple devices. We’re starting with a prototype and a small Mac pilot, with public access still ahead.
STILL COOKING. STAY HUNGRY.
One more bite.
Then we build.
We’ll share more when there’s something ready to try.
No signup just yet.