Lithi: Crowdsourced AI compute, powered by people

What Lithi Compute does

How can ordinary Macs help finish your AI work without exposing your whole project? Your agent delegates repeatable bulk work to Macs people and businesses already own. The local Lithi Compute Kit removes unused permitted fields, replaces selected identifiers with aliases, and encrypts approved input before transfer.

The network divides a batch into bounded pieces called shards and limits what each owner can receive across all their Macs. Related records or pages form a source group, the unit used to track disclosure. With a 5% exposure allowance, one owner receives at most 50 of a 1,000-document batch's source groups. Twenty executing owners and twenty different checking owners provide one valid 40-owner allocation. Owners can execute one source group and check another within the same allowance; each group’s checker has a different owner from its executor.

Customers choose Local Community Matching near their chosen area or Global Mixed Matching across eligible worldwide regions. Local matching starts within 500 miles and widens its search with task size and deadline. Like a smart grid for computing, the network matches suitable work to available capacity and returns checked results. Current readings of waiting work and available Macs guide placement and capacity decisions within the approved permissions, budget, and checking rules.

For example, a team gives its preferred AI agent the goal of translating 1,000 support documents into French. The customer sets permitted sources, a deadline and a spending limit. The parent organizes the work and supervises any helper agents. The Kit prepares approved input locally and keeps the private alias map local. Lithi returns checked results and accounting records for the parent to reconcile. Section 13 follows timing, charges and electricity.

The Kit prepares and submits the approved handoff from the environment holding the permitted files. The path has four steps:

• Step 1, Define. State the outcome, permitted sources, required context, acceptance checks, deadline, and spending limit. Then assess whether delegation is useful.
• Step 2, Prepare and approve. Prepare the input locally, replace selected identifiers with aliases, and encrypt approved content. Approve file transfer and spending separately.
• Step 3, Run and check. Lithi assigns bounded shards to eligible Macs in parallel and runs the required checks.
• Step 4, Review and assemble. Your agent receives checked files or structured data and joins them by stable source ID. It reviews coverage, exceptions, and charges before use.

Mac owners and business fleet operators use Lithi Connect to choose working hours, including overnight and off-peak windows. They can pause participation at any time. Security answers two questions: what can customer work reach on the Mac, and what customer content can its owner see? Apple’s macOS App Sandbox restricts the worker’s access to system resources. Lithi’s worker policy excludes personal files, accounts, and general network access; tasks supply data for registered operations. On the customer side, local preparation removes unused fields and replaces selected identifiers before encryption. Owner-wide disclosure limits bound the assigned slice, which becomes readable during execution. Process isolation separates applications, while confidentiality from a hostile operating system requires a stronger boundary. Returned results stay untrusted data until the customer’s agent validates and reviews them. Receiving a file never runs it automatically.

Figure 1 shows the exchange.

The paper brings together bounded agent handoffs, per-owner disclosure limits, home-cell acceptance and recovery, and reconciled work, payment, and electricity records.

This architecture brings together 18 months of development, from March 2025 to September 2026. Owner-approved hours give existing personal and business Macs another productive use, connecting customer demand with income for contributors. When regional preferences and local availability align, provider allocations support people and businesses contributing in that region.

Clear responsibilities make that exchange possible.

Who does what

Every workflow is a partnership with separate responsibilities. Your agent sets the goal, selects permitted files, and reviews the final output. The local Kit prepares the handoff. Global services check account access and credit and choose a coordinating home cell. That cell manages shard assignments, independent checks, and acceptance. Mac owners choose when their computers participate. Customer work, provider administration, and billing keep separate permissions. Your agent cannot pick a specific Mac or change an owner’s policy. Assigned Macs receive approved input rather than access to your workspace or account keys. Appendix A gives the detailed permission tables.

The workflow begins with local preparation.

Local preparation and bounded disclosure

What actually leaves your machine? Your workspace stays local. The Kit runs alongside your files to prepare a stripped-down, permitted working copy. It removes unused permitted fields and replaces selected personal identifiers, such as names or account numbers, with consistent aliases. This is called pseudonymization: aliases preserve relationships while their private lookup map stays local. It then encrypts approved blocks before upload. Original files and the private alias lookup table remain in your source environment. Assigned Macs read only the prepared portions authorized for their work.

Keep the meaning

The Kit pins the source version and validates qualified input profiles. Apache Parquet and Apache Arrow organize structured data by column; other profiles cover JSONL, CSV, PDF, media, and archives. The Kit preserves required IDs, types, order, and relationships. Where appropriate, it uses deterministic readers, rule-based parsers that reproduce the same result for the same input and profile. Appendix B gives the format and merge rules.

Preparation can remove unused permitted fields and repeated instructions while retaining required evidence. Oversized context receives a fit decision rather than silent truncation. The Kit prepares and pseudonymizes input locally without a Lithi usage charge. Per-owner sharding limits each assigned Mac to its prepared portion; original files and the private lookup table stay local.

Remove or replace identifiers

Separate secret and personal-information checks cover the composed request, including instructions, schemas and examples. The Kit returns eligible, review-required or blocked; unresolved review stays local and approval cannot override prohibited disclosure.

Where permitted, the Kit removes unused fields and replaces selected identifiers with consistent aliases. In this example, the customer’s name becomes a bracketed alias while the case identifier stays unchanged:

Local source

Example customer requests a refund for {case_id}.

Prepared input

[customer alias] requests a refund for {case_id}.

[customer alias] is an explanatory placeholder rather than a production token format. The private lookup map stays local. Restoration follows the output policy, and uncertain matches require review, as Appendix F.1 explains. Surrounding free text can still identify a person, so this is pseudonymization rather than full anonymization.

Tool responses contain counts and references by default. Plaintext previews need separate permission because printed content may enter a hosted agent's context. Remote plaintext conversion requires an approved processing stage.

Approve what leaves

Transfer approval permits uploading the exact encrypted artifact, a sealed file identified by its content fingerprint, to its destination. A changed file requires a new identity and approval. Quote approval separately permits spending on the quoted work.

The prepared input now needs a supported processing path.

Choose an outcome and a supported path

Start with the required result, permitted data, checks, and deadline. A workflow connects processing stages; each stage’s capability and approved profile fix its inputs, processing method, limits, and checks.

Keep full-project context and local tools with your agent. Compare its current path with the Lithi quote and retained planning, tools, and review. The Kit summarizes supported usage locally; raw account readings remain local [31, 32]. Section 15 compares full cost and outcomes.

Four workflow patterns

Your agent supplies the outcome, sources, relationships, and policy. The Kit and network compile and adopt the plan using four combinable patterns:

• Parallel batch: Apply the same supported operation to independent items, such as ticket labeling or document translation.
• Staged pipeline: Pass checked output into the next operation: extract document text, analyze or translate it, then assemble the result.
• Parallel branches and join: Process different aspects of a source concurrently, then join results locally by stable source ID or timestamp.
• Parallel work with a declared merge: Combine partial counts, sums, or scores while preserving their meaning. This map-and-reduce pattern uses declared reducers, explained in Section 8.3.

Ready windows pace work as eligible execution and checking slots become available. For a product video, one branch uses video.scenes; another uses speech.transcribe, then text.translate. The agent joins checked results locally by timestamp. The separate speech.subtitle operation produces subtitles directly from qualified speech audio.

Capability domains and bulk work

Seven domains organize the 46 capabilities: agent and batch work, documents and PDFs, text and language, speech and audio, images and vision, video, and model verification. Appendix B follows this order for exact identifiers, inputs, outputs, and checks.

Batch work beyond code. Fix the question, evidence, result format, and rubric. The agent.bulk_work capability organizes bounded items under that recipe; agent.candidate_set evaluates declared alternatives against references and the frozen rubric. Generation, evaluation, and acceptance remain separate stages.

For ticket review, supply permitted text and a fixed label set. Supported stages return source-linked findings and exceptions for parent review. The parent controls account updates. Table 1 shows other combinations.

Healthcare and routing. A quality analyst asks for themes in approved de-identified feedback. After the organization’s required privacy assessment, the parent selects an admitted profile and Global Mixed Matching within permitted jurisdictions. The data must also satisfy the profile’s category restrictions. Routing disperses the prepared pieces; de-identification is assessed separately [49, 50]. Returned findings receive professional review.

For code review, supply a pinned revision, its diff—the changed lines—and permitted context. Macs process it as static text and syntax, never compiling or running customer code. The host retains credentials, edits, builds, tests, and acceptance; findings inform review rather than establishing a test pass.

Worked language-model profile. Section 13 illustrates 9,600 input tokens, 1,200 output tokens, and 10,800 combined per call. These budgets cover the complete prompt and returned items; the chosen operation’s profile supplies actual admission limits.

Four local execution paths

A qualified reader prepares input; the profile fixes the operation and runtime, and checks verify its returned result. Placement selects an eligible Mac. Figure 2 and Table 2 show these paths.

Core ML is Apple’s on-device model framework [29]. Lithi’s ml.coreml operation verifies a qualified model specification on CPU. MLX is Apple’s open framework for Apple silicon [30], using unified memory shared by the CPU and graphics processor. MLX processes decrypted input as readable text, tokens, and model values in that memory [37]. The approved Gemma 4 12B model has about 12 billion parameters, the learned values shaping its responses. Its 4-bit weights use reduced storage precision to lower memory use. Appendix B pins the model, tokenizer, and template.

A customer selects a registered operation and supplies typed data. Loading a dynamic library adds executable code inside the same process; it creates no new isolation boundary [38]. Workers therefore exclude customer-supplied plugins, shell commands, and native libraries. Required symbols establish adapter compatibility, not trust in its code.

Macs differ in chip, unified memory, and available headroom. Table 12 spans 16 GB to 512 GB configurations. The complete runtime and working set must fit one Mac; Section 8 explains call budgets.

Discovery supplies supported profiles and codecs. Planning checks the reader, release, and limits; quote and admission recheck metering, required checks, and capacity. Unsupported requests receive a reason and next action.

Results carry source IDs, coverage, uncertainty, and abstentions—checks that decline an answer when evidence is insufficient. Speaker turns and face observations describe structure within the catalog’s identity limits. The completion policy governs partial delivery, waiting, or stopping.

With the processing path selected, the agent connects through the scoped Work interface.

The agent economy: goals, helpers and budgets

How can your agent complete a goal through bounded paid work? Here, an agent economy means software agents arranging and accounting for work under authority supplied by their customers. Lithi connects that demand with eligible computing capacity contributed by Mac owners.

Connect your agent and follow the work cycle

The Kit runs where permitted sources live. Choose a supported connection; host and account controls govern its tools and delegation [1, 2, 3, 4, 6, 34, 35].

Copy prompt guides assessment; the customer approves connection changes. After access approval, Get my API key opens the protected credential step. The client loads the secret from its approved store, outside prompts and conversations. Connection, transfer, work approval and admission retain separate permissions. The setup guide and Appendix A explain the handoff [5].

Python offers selected helpers and .NET a wire client; preparation and delivery use qualified paths. Caller-side pandas, Polars or PyArrow can produce qualified Parquet or Arrow files, or admitted records. Offline preparation and later approved transfer are separate; network APIs require approved connectivity.

Five Work tools cover the execution cycle:

• lithi.quote — returns a signed price ceiling and qualified capacity information, without reserving credit or admitting work.
• lithi.run — submits a bounded job.
• lithi.batch — submits independent requests that can run in parallel.
• lithi.status — reports progress across stages.
• lithi.result — retrieves checked outputs or their references, coverage and exceptions.

The agent checks the profile, prepares permitted input and requests a quote. An authorized person or existing policy approves its bounds. The agent submits through lithi.run or lithi.batch, monitors progress and retrieves results. The Kit validates delivery and restores permitted aliases; the parent reconciles coverage, exceptions and cost.

Fixed metered counts give reproducible tariff calculations. Quotes also reflect current release, capacity and expiry. Required artifact transfers retain separate approval; quoting admits nothing and reserves no credit.

Give helpers scoped access and budgets

The parent plans workstreams and dependencies, spawning helper agents where its host supports them. Four responsibilities keep that delegation bounded:

• Customer and account management: approve the goal, permitted data, limits and policy; provision credentials and funding through their authorized management and billing access.
• Parent and host: assign jobs and spending allocations; control context, concurrency, checkpoints and stopping rules.
• Helper: use its assigned connection and Work key within applicable limits.
• Lithi: enforce funding and admission, coordinate bounded execution and checking, and record accepted usage.

An authorized issuer provisions each independently managed helper’s Work key and protected connection where the host supports separate bindings. The key grants API permissions and expiry; spend policy and shared task limits govern spending. More helpers or credentials create no credit.

For a $10 Lithi task ceiling, the parent might allocate up to $4 to each of two helpers and leave $2 unallocated. These are planning allocations within configured limits. Lithi holds the quoted maximum when it admits the work. Accepted usage and unresolved holds reduce the remaining allowance. The parent tracks its own model and tool costs separately.

Requests retain their approved funded task identity under account, project, key and period limits. Separate tasks still share applicable account/project limits. Work permissions grant no key-issuance, billing or limit-management authority. Provider Macs receive execution permits. Figure 3 shows the division.

Complete and reconcile approved work

Within approved policy, the parent and helpers can quote, submit, monitor and evaluate unattended. The host governs their context, dependencies and stopping rules; Lithi handles bounded network execution.

For a new workflow, the parent can use a permitted qualification batch under the same privacy and checking rules. It reviews returned evidence before committing the larger batch. Trial costs enter the full-cost comparison.

Quotes provide commercial terms and forecasts; accepted outputs, coverage and checking records provide completion evidence. The parent reconciles every required outcome, unresolved item and cost before closing the goal. After restart, it resumes the saved plan and original request identities. Section 11 covers recovery; Appendix A.4 keeps occurrence and destination rules.

Section 15 compares full-task cost. Eligible settled Lithi revenue supports the provider pool, linking agent-directed work with contributed hours on existing Macs. The next section follows the price and approval boundary.

Quote, fund and approve

What does the work cost, and when is credit used? A quote states the maximum charge. Approval permits the work; admission reserves credit. Accepted usage consumes that credit.

For language-model work, tokens are the text pieces a model reads or writes. Customer Compute costs $0.05 per million admitted input tokens and $0.10 per million accepted output tokens. A signed metering recipe fixes each representation’s count; an executing Mac cannot replace it with its own count. For the dollar charge, multiply the input count by 0.05 and the output count by 0.10. Add the products, then divide by one million, as Equation 1 shows. Host-agent calls, other tools, and review enter the full-task comparison in Section 15.

C_USD = (0.05 × I + 0.10 × O) / 1,000,000

Here I and O are the signed recipe’s admitted input and accepted output counts, defined in Appendix D. Language-model input includes the complete rendered prompt: instructions, context, and chat-template control tokens counted with the pinned tokenizer [20]. That pin fixes the text-splitting algorithm and vocabulary, so the same canonical input receives the same count on every Mac.

Other recipes count canonical records, image or frame patches, decoded audio duration and tensor shapes under released profiles. Billing tokens count commercial usage, not all physical work; pages, images, audio minutes and Mac-hours carry no separate fees. Normal retries, default checks, delivery and repair do not charge twice for the same logical work. Included independent checks are funded from the task’s provider pool under the signed role-allocation policy in Section 14.3. They add physical work and electricity while the customer’s logical work is recognized once. A separately requested review stage follows its own quoted scope. Quotes use planned counts and recognition uses accepted work; Appendix D distinguishes the records.

Four decisions remain distinct:

• Estimate: a planning calculation that reserves nothing, uploads nothing, and starts nothing.
• Signed quote: the account-bound work, maximum price, and expiry Lithi will accept.
• Execution approval: permission from an authorized person or existing policy for that work.
• Admission: confirmation that the approved work can start within its requirements.

An expired quote needs a fresh quote and approval; adding credit does not revive it.

Table 4 separates collection, admission, acceptance, and recognition.

Account, project, key and period limits continue to govern funded work. Lithi reserves the quoted maximum, recognizes exact accepted usage and releases the proven unused remainder; unresolved obligations retain their holds. Stages and subagents share that maximum, and display rounding preserves the exact charge and limit. Appendix D gives metering and reconciliation rules; the billing guide explains account procedures.

Once funded and approved, the workflow needs eligible capacity.

Home cells, regional placement and growth

How does the network respond when demand rises or Macs become unavailable? One home cell coordinates each workflow and accepts checked results. Placement uses current eligible capacity; changes to capacity need separate authority.

Follow a bounded feedback loop

Capacity policy requires six steps, shown in Figure 4:

1. Measure. Track waiting shards, eligible execution slots, and independent checking capacity.
2. Compare with a target. A target is the operating level allowed by policy, such as a maximum queue wait or concurrency ceiling.
3. Recommend a bounded change. Calculate a limited step from current readings and recent history.
4. Check authority and safety. Check permissions, jurisdiction, owner exposure, checking capacity, and downstream resource limits.
5. Apply through an actuator. An actuator is the separate component authorized to change a live setting. It applies only an approved step.
6. Confirm by read-back. Read-back checks live records for confirmed capacity before another adjustment.

The recommendation, request, and confirmed result need separate records. An unresolved change must reconcile before another adjustment. The calculator's recommendation carries no authority to change a queue ceiling or provision a cell.

Table 5 connects readings to their decisions.

Mac capacity, cell coordination capacity, and independent checking capacity are separate limits. A higher worker ceiling or another cell helps only with enough eligible Macs and independent checking owners.

Respond to sustained load. Five safeguards limit repeated reactions to brief spikes:

• Smooth readings. An exponentially weighted moving average, or EWMA, blends recent arrival and completion counts with history.
• Use different increase and decrease rules. This is hysteresis: increases need sustained pressure; decreases need a longer healthy period.
• Wait between changes. A cooldown gives a confirmed adjustment time to take effect.
• Hold at a full boundary. Backpressure paces releases when downstream capacity is full.
• Check spare capacity. Headroom is the capacity remaining in checking, storage, or coordination. Recommendations preserve policy reserve requirements.

Stale or incomplete readings hold a capacity change. These safeguards constrain reactions; stability for a workload needs its own evidence.

Match and grow within approved limits

Before ranking Macs, the home cell checks jurisdiction, runtime release, memory, bandwidth, owner exposure, and independent checking capacity. The complete runtime must fit one Mac's shared CPU and graphics memory. Placement follows the customer's choice:

• Local Community Matching: Prioritize eligible Macs within 500 miles of the chosen area. Task size, independent-owner requirements, or the deadline can require a wider search within approved jurisdictions and transfer rules.
• Global Mixed Matching: Distribute shards across eligible regions and independent owners. Each Mac contributes work that fits its released profile.

Both modes preserve the approved data, jurisdiction, execution, disclosure and checking boundaries. Global Mixed Matching disperses work among eligible owners within those boundaries. More independent local owners provide more regional options. Section 8 defines the disclosure bound; Section 9 connects eligible slots to deadlines.

Growth first uses qualified capacity within a cell's limits, then can prepare another cell for incoming workflows. Existing workflows retain their home. Running jobs keep their approved model, metering, privacy, and checking rules; placement can change within those rules. New defaults apply to new jobs.

A restart recovers in the same cell. An approved move advances the home-assignment version, called an epoch; authority checks reject the old epoch. Before retirement, unfinished work, reserved credit, and retained files must reconcile. Appendix A defines replay and transaction rules.

Capacity, checking, or permission shortfalls pause new admission with status and next actions. Status reports keep customer content and device locations private. Suspected compromise follows Section 12.

Placement begins with bounded pieces of work.

Split work without losing meaning or privacy

What is a shard? A shard is a bounded piece of work containing whole input blocks, required context, an operation and limits. Lithi assigns it to an eligible Mac. Your agent supplies the source, outcome and policy limits; the network adopts the execution plan.

Related input stays together

The Kit keeps related input in source groups and encrypts it into blocks on your machine. Lithi packs whole blocks and required context into shards. The planner uses sizes and dependencies without opening the content.

Independent shards may run in parallel across eligible Macs. Dependent stages wait for their required inputs and checks.

Each assigned Mac runs the complete required local algorithm, native framework or model. Sharding divides data and task work, not model weights. One Mac may process many shards over time; a retry keeps the same shard identity.

Each call must fit

Each model-based shard fits one Mac's available unified memory: weights, the key-value or KV cache, input, reserved output, and runtime buffers. The cache stores earlier tokens’ attention state for reuse during generation.

Count the complete rendered prompt against the input ceiling, including instructions, context, and template control tokens. Reserve output within its own and combined ceilings; do not deduct it again from the input allowance. The illustrative profile permits 9,600 input, 1,200 output, and 10,800 combined tokens per call. Discovery supplies actual limits.

Pack short items together only when their evidence and combined answers fit, preserving related source groups and required context. Resource and owner-disclosure limits also apply.

Illustrative packing. Sixteen records at 200 tokens each contribute 3,200 record tokens. Adding 1,600 tokens for shared instructions gives 4,800 input tokens. Sixty output tokens per record require 960 tokens; another 240 for structure brings the output reservation to 1,200. The call therefore uses 6,000 combined tokens. Output space binds first in this example; actual packing uses the pinned tokenizer and complete rendered call.

Items, calls, shards, workflows, and Macs are different units. A shard can carry several items; a Mac can process several shards. Items sharing a prompt share its context. The compiler fits complete required evidence or returns a permitted partition or no-fit decision. Native and deterministic stages follow their own format, resource, and metering profiles.

Join without losing meaning

Stable source IDs let your agent assemble results and identify gaps. Before adopting a plan, Lithi checks its dependencies and exact source coverage. It rejects cycles, omitted items and duplicated IDs; a simple total could miss an omission and a duplicate that cancel numerically.

Reducers are merge steps that combine partial shard results under declared rules. They obey the same fit and disclosure limits, using several bounded stages when needed. Counts, sums, ranking, deduplication and joins must preserve their meaning across shards. Appendix B gives the merge rules.

Limit what one owner receives

Privacy limits follow the owner across all their Macs. One person or business may control several devices, so Lithi enforces the exposure allowance A across the verified owner. Under a 5% allowance on a 1,000-document job, an owner may receive keys for at most 50 source groups. Full-source execution and checking require at least 40 known owners overall. Twenty executing owners and twenty different checking owners form one valid allocation. A source group’s checker belongs to a different owner from its executor. An owner may execute one group and check another; both count toward the same owner-wide allowance. Freeze the source-group population G and allowance A at admission. Let E contain groups already made readable to that owner and R its unresolved release reservations. Their combined distinct-group count must stay within the owner’s allowance. Count a group appearing in both sets only once. Equation 2 gives this bound.

|E ∪ R| ≤ A

Derivatives, overlap, checking, and reducer input refer to the same source population. Repacking, key changes, and migration cannot reset that history. Reservations precede key release. Execution alone needs the source-group count divided by the allowance, rounded up: ⌈|G|/A⌉ owners. Independent full-source checking doubles the source-group count before division and rounding: ⌈2|G|/A⌉ owners. Retries and resource limits can require more. Exposure follows the recorded owner across enrolled Macs. Device-bound admission, server-controlled placement and independent checking support that boundary. Its assurance still depends on establishing owner identity; payout verification alone does not establish independent owners. Section 18 retains the collusion and false-identity limits.

With the work divided, we can estimate its finish time.

Planning and completion forecasts

A whole-job forecast estimates acceptance or requested delivery from the plan, eligible capacity and comparable timing evidence. It includes waiting, processing, checking, retries and delivery, with dependencies and resource limits governing overlap.

The forecast estimates what the current plan can finish. Operational controls govern how much work may proceed within its permissions. Figure 5 shows the forecasting inputs. A generative step first reads its prompt, a phase called prefill. It then writes the response one token at a time, called decoding. Its duration combines both phases and occupied overhead. Overhead includes parsing, transfer, startup, and validation; native operations use their own units. The step starts when its input is ready, a Mac slot is free, and every prerequisite has finished. Adding duration to that start gives the finish time. Equation 3 expresses these dependencies.

For a generative step: duration(v) ≈ rendered input tokens / input-processing rate + generated tokens / generation rate + occupied overhead. For nonempty P(v), predecessor_finish(v) = max(finish(u) for u in P(v)). start(v) >= max(ready(v), slot(v), predecessor_finish(v)); omit predecessor_finish(v) when P(v) is empty. finish(v) = start(v) + duration(v).

Here d is duration, s and f are start and finish, r is input-ready time, and a is the next slot. P(v) lists prerequisites; f_pred,v is their latest finish and is omitted when there are none.

For Local Community Matching, the home cell widens the eligible search beyond 500 miles when local slot availability would push the forecast past the deadline. The wider search preserves the approved jurisdiction, disclosure and checking requirements.

Timing records distinguish waiting, transfer, execution, checking and delivery. The 95th-percentile duration, called p95, is the time within which 95% of comparable runs finish. Adding stage p95 values does not establish a job p95 [15]; insufficient comparable evidence can mean no justified estimate. A forecast states its method, coverage and freshness and cannot relax the deadline, budget or checks. With the illustrative 20-Mac schedule in Table 9, 105 minutes of work and a ten-minute reserve give a latest planned start of 07:05 for a 09:00 deadline.

Recorded waits, transfers, execution, checking, and delivery times can inform later forecasts for the same operation and comparable Mac profiles. Their scope, coverage, and freshness must qualify first. Physical-attempt timing records remain distinct from accepted-outcome labels.

That forecast guides the authorized execution path.

Run on shared Macs and accept results

The home cell offers work only after the eligibility, jurisdiction, capacity and exposure checks in Section 7. It reserves the owner’s allowance, and the Mac checks its local policy, resources, and lease before claiming during approved hours. A lease is time-bounded permission for that attempt; an expired lease cannot authorize more work. The customer approves the task, the owner permits participation and the cell authorizes the attempt. A returned result remains a candidate until checked.

Separate storage links from key custody

Encrypted input, intermediate and final objects live in cell-scoped storage and are fetched through short-lived links. Anyone holding a link can fetch its ciphertext, the encrypted data, until expiry. Links carry no decryption keys.

The execution boundary requires the isolated task worker to generate its task private key within the active executor session. The Sidebar interface and transport broker carry ciphertext, public-key metadata, and restricted status, rather than task plaintext or usable private keys. This is a process-isolation requirement, not hardware protection against the Mac’s administrator. Candidate output is encrypted for its authorized recipients before leaving the worker, including separately authorized checking and customer delivery.

Before releasing keys, the custodian checks the customer account, executing device, worker session, software release, pinned model, task, attempt, lease, fence, expiry, and result recipient together. Current home-cell identity and epoch also bind that authority. Owner exposure is reserved before placement commits, dispatch, and key release. A valid transport signature cannot authorize a substituted recipient key, different worker session, or replayed permit.

Customers choose who releases those keys:

• Managed custody: Lithi's key service holds and releases keys for authorized attempts, so it could technically open the input.
• Customer-held custody: the Kit on your machine holds and releases keys to authorized Macs. Lithi's service has no input-decryption authority through that release path, and the Kit stays online while work runs.

The assigned executor reads its permitted plaintext, the input unlocked for that assignment, in either mode. The following access map separates required process handling from the host-memory limit. Appendix C explains the cryptographic methods.

Protect the provider’s Mac and isolate execution state

Lithi Connect checks permission, schedule, power state, foreground activity, thermal headroom, memory, storage, and active work before claiming a shard. The attempt fixes its operation, model, tokenizer, instructions, and limits. Apple’s macOS App Sandbox restricts process access [11]; Lithi’s execution boundary requires narrower privileges than the personal desktop application:

• Keep personal state outside the worker. Permit verified, read-only model assets and narrowly scoped task storage. Exclude the owner’s documents, keychain, mail, browser sessions, and payment credentials. A broad shared app-group container must not expose personal application state to task workers.
• Separate inference from network transfers. The inference worker has no general network access. A restricted broker performs approved encrypted transfers. Interprocess communication, or IPC, uses typed commands with size limits. Signed peer checks authenticate the calling process.
• Treat inputs as data. Signed readers parse documents, media, and code diffs for registered operations. Customer content grants no authority to run a shell, load an executable plugin, or select an arbitrary native library. Public model reuse preserves those permissions.
• Dispose of private run state. Task keys, private key-value caches, token arrays, and intermediate buffers belong to the active task. Cleanup waits for native and GPU work to finish, clears owned buffers, and recycles workers where justified. Application logs and caches exclude plaintext. Clearing one variable or ending a process does not prove erasure of all copies, GPU allocations, swap, or host-captured data.

Check hardware evidence separately. A signature proves possession of a key. A software key holder can also sign a claim that the key is hardware-backed. Independent evidence must establish that provenance before the claim affects admission.

Apple’s Managed Device Attestation supplies hardware-backed identity and selected device-posture evidence on supported Apple-silicon Macs [39]. Verification requires the expected Apple certificate chain, freshness checks, and binding to the connecting device [40]. Its supported enrollment and refresh rules do not supply an unlimited per-request boot oracle or attest the complete MLX execution state.

Apple also documents Secure Enclave ML-KEM-768 key operations on macOS 26 [41]. Hardware key custody and protection of ordinary MLX memory are different properties. A qualified key mechanism must preserve the selected protocol and recipient binding; it is not a drop-in replacement for X-Wing.

Require new authority after restart. The session boundary requires retiring task keys when the executor ends and retaining only ciphertext and content-free recovery metadata. Resuming work requires a fresh assignment and key exchange, checked against server records outside the provider’s snapshot control. FileVault protects locked storage from parties without its unlocking credentials; it does not exclude the Mac’s own authorized administrator [42].

The lifecycle comparison keeps each guarantee beside its condition.

Check and accept once

A returned result is a candidate until its identity, input, release, and permission are checked. Structural checks assess fields, types and IDs under the operation’s declared rules, including canonical comparisons where required. For generative work, valid answers need not use identical wording. The checking policy evaluates the candidate against the permitted source, protected placeholders, glossary and rubric, returning structured findings, uncertainty and any abstentions. Different-owner checking uses another owner's Mac with separately authorized input. Sampled checks report their coverage, while disagreements, abstentions, and missing coverage remain visible.

A candidate that meets the configured checks can be accepted.

The home cell records at most one accepted result per shard and links its usage to that result. Cancellation and acceptance resolve against the same work record: cancellation recorded first prevents later acceptance and charging; acceptance recorded first remains in the accounting history.

Just as customer inputs stay data on provider Macs, returned results remain untrusted data on the customer’s machine. Before restoring permitted local aliases, the Kit validates cryptographic integrity, the authorized result recipient, source IDs, exact schema types, and representation. A valid signature establishes the claimed signer, not the truth or safety of the returned content. It blocks path traversal, tricks that try to write outside the approved folder, along with unexpected file types and unapproved overwrites. Returned patches, scripts, macros, and spreadsheet formulas gain no execution authority. Receiving or accepting a result never runs it automatically. Your agent validates and reviews delivered files before applying or using them.

Where the workflow permits, the Kit validates and writes accepted files or structured data in the approved workspace. Your agent can inspect the manifest, coverage and bounded exceptions without replaying the whole batch through its conversation. Required semantic review remains part of the task and its cost.

The same rules continue through attempt failure and recovery.

Recover the step that failed

Recovery repeats only the failed step under the original limits. A replacement attempt receives a higher version number, called a fence. That fence blocks delayed effects from an older attempt from replacing the current result; physical work can still repeat. Normal retries and authorized redelivery add no customer charge. Uncertain actions keep their holds until reconciliation, and speculative copies require explicit policy. Zero credit still permits authorized retained-result access and safe cancellation. Table 8 identifies the recovery for each failure.

Suspected compromise calls for a different kind of recovery.

Contain a breach

Controls outside a suspect cell pause affected assignments and key releases. Unaffected cells can continue only while shared controls remain trusted; a compromised shared dependency can require a wider stop.

Figure 7 shows breach recovery. Independent trusted evidence supports accepted results, and the old cell stays fenced. Reconciliation carries financial obligations, each owner’s exposure history E, and unresolved release reservations R into authorized recovery. In the illustration, trusted records retain 700 translations without charging again and leave 300 for a clean cell. A compromised Mac stays excluded until separately repaired and qualified. An executor restart requires fresh session authority and key exchange; restoring local files cannot restore server-side permission. Revocation stops future authorized releases and assignments, while previously disclosed plaintext remains outside recall. Appendix F explains the remaining risks.

These rules come together in the next 1,000-document translation example.

The 1,000-document task, end to end

How do quoting, sharding, checking and accounting fit together? This section applies the rules from Sections 6, 8 and 9 to the hypothetical translation batch introduced in Section 1 (Figure 8). It reconciles the whole task and each role under stated timing, wall-power and allocation assumptions.

Assumptions

• Workload and packing: 1,000 support documents of about 600 words each, one whole document per shard, preserving IDs, placeholders, glossary terms and structure.
• Metered tokens: 6,000 input tokens including instructions and context, and 1,000 output tokens per shard. The assumed profile permits 9,600 input, 1,200 output and 10,800 combined; actual limits come from discovery. The planned totals are 6 million input and 1 million output tokens: a $0.40 quote.
• Occupied time: Assume 100 seconds of translation and 20 seconds of independent checking per document, totaling 2,000 Mac-minutes with eligible resources ready. Generation produces the full translation; checking can read source and candidate and emit a shorter verdict, reducing decoding work. These durations are illustrative; Equation 3 also accounts for input processing and occupied overhead. Local preparation and delivery add five assumed minutes.
• Power boundary: An assumed 40 W occupied-time-weighted mean for each translation and checking role across the mixed fleet. Individual Macs and operations draw different power; this calculation covers whole-Mac wall input during the occupied slots.
• Revenue allocation: 50% of eligible settled accepted revenue forms the provider pool, with assumed 80/20 weights for translation and checking.

Preparation and approval

The customer’s parent agent keeps the glossary decisions, overall plan, and final exception review. It checks the source, destination, two-hour deadline, $0.40 budget, and completion checks before choosing delegation and scoped subagents. First, it compares the bounded translation stage with the current path. The following English instruction and French translation illustrate a protected case identifier and glossary term. For example, given "Restart the Lithi desktop app before opening case {case_id}." and a glossary mapping "case" to a support ticket, the French output is "Redémarrez l'application de bureau Lithi avant d'ouvrir le ticket {case_id}." Verification checks meaning, terminology, document ID, and placeholder preservation. The instruction is translated rather than executed.

Locally, the Kit prepares and seals the 1,000 documents into encrypted blocks. The adopted plan packs them into 1,000 one-document shards under the $0.40 quote, using Equation 1.

Once funded, the home cell assigns shards to eligible Macs, as Figure 8 shows. A 5% owner exposure allowance permits 50 source groups per owner: translation requires at least 20 distinct owners, and independent full-source checking raises the overall minimum to 40. Each document’s checker has a different owner from its executor; roles can differ for other documents. The checker reads the permitted source, glossary, candidate, and rubric within its profile. Default checking is included in the quote.

Time

At 120 combined seconds per document, the task totals 2,000 Mac-minutes, or 33 hours and 20 minutes of occupied Mac time. The exposure allowance requires multiple owners. Table 9 illustrates translation and checking time across 20, 50 and 100 concurrent Macs. With 100 concurrent slots, 1,000 shards are processed over time in about 20 minutes.

These schedules assume homogeneous stages and eligible resources ready. With 20 concurrent Macs, 20 owners translate 50 documents each and 20 different owners check them. With 50 or 100 concurrent Macs, owners can execute and check disjoint sets within their allowance. In the illustrative 100-owner schedule, each owner translates ten documents and checks ten different documents: twenty source groups within the fifty-group allowance. Preparation and delivery add five assumed minutes. Transfer delays, switching and retries can extend completion; Section 9 forecasts actual workflows.

If an owner pauses. Consider a separate variation on this batch: one translating owner pauses after 30 of their 50 documents have been checked and accepted. Local checks withhold new claims, and the Mac's availability updates the home cell's view of supply.

An unfinished attempt follows its existing completion or cancellation rules. If its lease expires before acceptance, recovery uses a higher attempt fence (Section 11). Another eligible executing owner can take the 20 unfinished documents only with room under the owner-wide 50-source-group allowance. Checking still uses independent owners; the 30 accepted translations stay recorded.

The forecast reflects the remaining eligible Macs. The $0.40 quote ceiling, privacy rules, and checking standards remain fixed. This interruption changes the timing assumptions in Table 9 rather than inheriting its illustrative finish time.

Accepted results

Suppose 990 shards pass the declared checks and are accepted, while ten remain unresolved after their attempted translation and checking.

The parent joins accepted outputs by document ID, restores only permitted fields, and reports 990 documents as partial delivery. Translation does not automatically recreate a PDF's layout.

Accepted documents arrive as files with source identities and coverage records. The parent agent reviews those files and resolves exceptions; Section 15 includes its retained planning and review calls in the full-task cost.

Electricity

The 20-concurrent-Mac schedule uses 40 distinct Macs and owners across two stages. The physical shares are 5/6 translation and 1/6 checking; the separate 80/20 revenue weights allocate the provider pool. Attempts on unresolved documents still consume electricity. The full-precision reconciliation is in Appendix D.

Together these roles consume approximately 1.33 kWh, excluding activity outside the occupied slots.

Charges and allocations

Once the ten unresolved items close without further accepted usage, reconciliation releases the unused $0.004 to the account’s available credit. The $0.396 charge remains recorded for the 990 accepted translations. Appendix D.1 reconciles the balance.

Section 15 compares full task cost for this 1,000-document population using a separate 24-hour deadline and 95% completion floor: $7.396 with Lithi against $35.00 for the agent alone. Task allocations are separate from cash payouts and monthly earnings (Section 14; Appendix E.2). Payment-processing fees apply to the credit purchase rather than each task. The parent reconciles delivered files, source coverage, exceptions and full cost before using the result.

The task’s allocations lead us to the Mac owners who provided its capacity.

The people and businesses sharing their Macs

What does an owner agree to, and what do they earn? Owners can use Lithi Connect directly or begin with the separate provider Copy prompt in a supported agent. The agent reviews the intended provider account, permitted Macs, working times and available management tools, then prepares changes for approval. Owners review permissions and consent to participation. Only qualified Macs receive assignments.

The Lithi Provider CLI, lithi-provider, supports discovery, plans, management and read-back through commands exposed by the approved build. It begins with version and capability checks. Provider access is separate from customer Compute credentials and does not authorize customer spending. The provider setup guide explains the handoff.

Choose when to participate

Lithi Connect uses signed, sandboxed workers for customer data and registered operations. The worker boundary requires less access than the personal desktop application: approved models and task storage, with personal files, accounts, and general networking excluded. Customers supply data, rather than programs to install or execute. Section 10.2 explains these requirements and the separate host-memory limit.

Customer credit and provider enrollment are independent: owners do not buy credit to contribute, and customers need not enroll a Mac. A shared installer or invitation does not transfer device identity or consent. Setup identifies the device, release, permissions, hours, and timezone; selection, consent, enrollment, and qualification remain distinct.

Owners can permit unattended claims during approved hours, including overnight or off-peak windows, pause, or withdraw. Before claiming work, Lithi Connect checks approved hours, pause state, power, heat, and available resources. When local conditions restrict participation, the Mac reports its availability and withholds new claims. Placement uses current eligible capacity; existing attempts follow their completion or cancellation rules. Signed updates preserve consent. Withdrawal reconciles remaining work and removes only Lithi-owned components.

Manage a selected fleet

The same worker boundary applies to every fleet Mac. Task permissions exclude company files outside the run, corporate intranets, shared personal application state, and customer-supplied commands. IT deployment does not widen those permissions. A customer using its own or an explicitly trusted managed fleet changes which administrators it trusts; fleet management alone does not create confidential execution memory.

A provider organization selects Macs it is authorized to manage and begins with a fixed pilot, verifying it before expanding to another reviewed group. Multiple personal Macs do not require a business account. Existing approved tools can deliver verified software. Secure Shell, abbreviated SSH, provides remote command-line login. Mobile Device Management, or MDM, configures company Macs centrally. The provider plan records the intended account, targets, and policy.

The organization’s existing MDM performs its deployment actions [33]. Each Mac still needs valid provider authorization, its own device identity, required permissions and runtime qualification. Installation, enrollment, qualification and current availability are separate results. Roles can permit device administration without exposing earnings or payout controls. Fleet reports retain every selected target, including unavailable Macs and those awaiting action. Remote changes remain subject to local checks and applicable managed policy.

Adding Macs does not multiply an owner's source-exposure allowance or create independent checking owners. Section 8's bound continues across devices controlled by that verified owner. The fleet guide covers setup and management.

How earnings are allocated

Work arranged by customer agents feeds the provider pool, connecting bounded task budgets with computing hours that people and businesses choose to contribute. Half of eligible settled distributable revenue forms the provider pool. The signed policy divides it among Macs whose execution and checking produced accepted results. An inviting owner earns 10% of the invited Mac’s eligible earnings. That reward comes from Lithi’s share and is capped at 5% of task revenue. The invited owner keeps their full allocation.

More independent owners in a region expand local execution and cross-owner checking options, helping more regional work fit inside the local matching area. Lithi handles customer acquisition, billing, support and coordination from its share. Allocated revenue reports each owner's contribution; electricity and other operating costs determine net return.

Separate invitation example. If an invited Mac earns $1 from eligible settled work, the inviting owner earns $0.10 from Lithi's share and the invited owner keeps the full $1. The 5% task-revenue cap applies. This is separate from the $0.396 translation-task illustration.

The provider pool equals half of eligible settled distributable task revenue. Each Mac’s gross allocation sums its policy-weighted share of those pools across tasks. Equation 4 distinguishes the shared pool from an individual Mac’s allocated earnings.

provider pool(j) = 0.5 × eligible settled distributable revenue(j); allocated earnings(m) = sum over tasks j of allocation weight(m,j) × provider pool(j).

Here Dⱼ is eligible settled distributable revenue for task j, Pⱼ is its provider pool, and wₘ,ⱼ is Mac m’s allocation weight. For each allocated pool, the signed policy’s weights are non-negative and sum to one. Gₘ is that Mac’s gross allocated earnings across tasks.

Earnings statements identify accepted work and the owner’s share once the customer has paid. Earned, payable, and paid amounts remain separate; fractions of a cent carry forward. Payouts use verified, settled funds after declared taxes, refund reserves, and customer obligations are covered.

What the calculator illustrates

Planning illustrations. The calculator illustrates the owner’s share for selected Mac configurations, available hours, and electricity price. This example uses 12 available hours a day over a 30-day month. Annual figures multiply the monthly illustration by twelve. Actual earnings follow demand, eligible accepted contributions, and settled payment.

Each figure assumes 12 available hours a day (360 hours in a 30-day month) and electricity at $0.1835 per kWh, the US average residential price, June 2026 (EIA Electric Power Monthly, Table 5.3). It is in US dollars, after estimated electricity and before tax.

Table 12 uses the Lithi Connect calculator [22] and dated EIA price [23].

The calculator starts with a hardware planning figure for 240 available hours and scales it to the hours selected. Family and chip-class premiums and memory adjustments are planning assumptions, rather than measured throughput rates. Electricity uses 80% of the stated power reference: Apple’s published maximum power for desktops and bundled-adapter bounds for notebooks. Adapter ratings include charging and do not measure working draw. Monthly figures are rounded to cents; the 12-month illustration is the monthly figure multiplied by 12. Displayed estimates have a zero lower bound. Actual statements report recorded work and payments.

Apple’s desktop power references state their measurement conditions [24] [25] [26]. Notebook bounds use the applicable adapter references [27] [28]. The full calculator guide lists every available illustration and explains how to use other hours or your own electricity price. Hardware compatibility, workload qualification and an available earnings illustration are separate checks.

Table 12 spans 16 GB configurations through 512 GB workstations. Chip capability and available headroom decide which released workloads fit each Mac. Smaller systems support extraction, native analysis, and checking. More memory fits larger working sets and supported concurrency. Each Mac runs a complete runtime. Input-heavy work can return labels, vectors, or extracted fields. Accepted results, cost, coverage, and completion time describe the contribution.

For customers, the corresponding question is the full cost of accepted work.

Compare results and improve the network

Does delegation improve value? Compare the full cost of reaching the same required result. Keep the source population, output requirements, acceptance checks, deadline, and completion policy fixed. Record preparation, execution, checking, delivery, coverage, elapsed time, cost, and electricity. Operational controls react within approved settings; experiments compare permitted alternatives under fixed task requirements. Quality, safety, permissions, and owner protection remain constraints when comparing cost and speed.

A configuration c fixes the host agent model, instructions, guidance, tools, task policy, and stopping rules. Full cost adds host-agent calls, Lithi usage, other tools, local preparation and review, and setup and evaluation. Equation 5 keeps these costs within the same task boundary.

Full task cost for configuration c = host-agent calls(c) + recognized Lithi usage(c) + external tools(c) + local preparation and review(c) + setup and evaluation(c).

Host cost covers agent-model calls. Lithi cost counts recognized usage rather than unspent credit purchases. Tool cost covers external services. Local preparation and exception review form one cost component. Setup and evaluation cover preparing and assessing the comparison. Count unsuccessful calls and trials in their incurred category. Included platform retries never become another customer charge.

Table 13 illustrates a reference host-model API comparison for translation over 24 hours with a 95% completion floor. Configuration A processes 6 million input and 1 million output tokens on the host model. At $3 per million input and $15 per million output, its model charge is $33.00. Configuration B incurs $0.396 for 990 documents on Lithi and assumes $5.00 in host planning and coordination. Both add $2.00 for local setup and review. Ratios use exact totals before rounding.

For each configuration, count accepted outcomes that meet the declared deadline and quality floor. Full task cost is C_c and the accepted-outcome count is S_c. Dividing cost by outcomes gives cost per accepted outcome. Reversing the ratio gives accepted outcomes per dollar, as Equation 6 shows. The first ratio needs a positive outcome count; the second needs a positive cost.

Cost per accepted outcome = C(c) / S(c), for S(c) > 0; accepted outcomes per dollar = S(c) / C(c), for a known C(c) > 0.

Under this reference baseline, delegating bulk translation lowers full-task cost by 78.9%, from $35.00 to $7.396. The assumed accepted outcomes produce 133.9 outcomes per dollar with Lithi and 27.4 with the host model alone, about 4.9 times as many. A parent agent can use this method to compare work allocations under an approved budget.

In this illustration, Lithi usage accounts for $0.396 of the full-task cost. Half of that eligible settled revenue provides the $0.198 provider pool; host-model and local review costs remain separate components.

Report cash cost and subscription allowance in their actual billing pools. Provider terms remain separate; missing prices and evidence stay unknown. Include failed trials, local review, and external costs. Compare coverage and quality at the same endpoint. Removing unnecessary tokens lowers both the bill and provider pool while preserving the required work.

Test a change before approving it. Compare a permitted setting with the current baseline under fixed task requirements.

A separate authority approves release; running jobs keep pinned settings. Failures and unresolved work count, with retries retained in their original sample group. Consent, privacy, payout, and tariff constraints stay fixed. Comparison creates no training rights. Figure 12 and Appendix E.4 explain the release boundary.

The same work records also support electricity and emissions reporting.

Report contribution, electricity and emissions

Existing Macs perform useful work during owner-approved hours. Impact reports connect that delegated work with contributor allocations and qualified electricity records for the same period. Local matching can support regional participation; Global Mixed Matching spreads eligible participation across permitted regions. Reports reconcile past activity; operational control decisions use fresh resource and queue readings.

Each month, customers receive a dated report covering every participating Mac within the declared physical boundary. This includes execution, independent checking, failed attempts, and attributable overhead, even where no output is accepted. Electricity intervals link to work and reconcile with task allocations and network totals. The report shows contributing Macs and owners, electricity used, and estimated emissions. Shared interval energy is allocated once. Measurements, calibrated estimates, and missing coverage stay distinct; missing readings never count as zero.

Where did the number come from?

Qualified meters supply measurements; calibrated device profiles supply labeled estimates. CPU time, temperature, and charger ratings alone do not establish whole-Mac energy. Calculator assumptions remain separate from operational records.

What boundary does it cover?

Whole-Mac wall AC input and internal device DC load have different boundaries; never sum them. Occupied-slot wall power includes other device activity. Incremental task-energy claims require a declared idle or foreground baseline and separate evidence.

What activity is included?

Multiply each interval’s average power in watts by its duration in seconds. Sum the products and divide by 3.6 million for electricity in kilowatt-hours. Equation 7 applies this rule. Section 13 counts occupied translation and checking slots and excludes activity outside those slots.

E_kWh = sum over intervals k of (P(k) in watts * duration(k) in seconds) / 3,600,000.

Compare electricity using accepted results under the same task and quality requirements. Keep failed-attempt energy, unresolved work, missing intervals, and the measurement boundary visible. Lower energy with less completed work may be worse. Input-processing and generation rates explain performance but do not replace accepted work as the denominator.

Multiply each interval’s electricity in kilowatt-hours by its regional, hourly grid factor. The factor expresses grams of carbon dioxide equivalent per kilowatt-hour.

Equation 8 sums these products into estimated grams of carbon dioxide equivalent.

Operational emissions in gCO2e = sum over intervals k of (energy(k) in kWh * grid factor(k) in gCO2e/kWh).

The report records each grid factor’s source, method, version, uncertainty, and coverage.

Software Carbon Intensity, abbreviated SCI, combines operational and allocated hardware emissions per declared unit of work [14]. An avoided-emissions comparison needs a matched baseline. Appendix E.5 links hypothetical participation, distributed memory, decoding capacity, and electricity consumption.

Report earnings and qualified electricity for the same scope and period. Neither proves the other.

Figure 9 and Table 14 separate these evidence types. Retries can consume electricity without accepted output. Count distinct Macs, owners, accepted-work contributors, and paid participants separately. Count overlapping child contributions once per task.

Regional reports need complete ownership coverage and at least five independent owners per released broad region. Suppress small-group inferences, keep household addresses private, and publish no live device map.

Keep separate dates for work, energy, usage, and cash. Later evidence creates a dated revision rather than rewriting the earlier report.

These design choices build on earlier work in distributed and volunteer computing.

Related work

Volunteer computing showed that idle personal computers can support distributed scientific work. SETI@home and Folding@home used donated machines [17, 18], and BOINC generalized public-resource computing [19]. Lithi focuses on paid work from a customer's existing agent, per-owner exposure limits, home-cell acceptance and recovery, and linked work, payment, and energy records.

Protecting data from the machine’s own operator requires a different platform boundary. Apple’s Private Cloud Compute combines hardware-rooted software measurements, restricted executable releases, removal of general privileged runtime access, and per-boot storage-key protection on its Apple-silicon nodes [43, 44, 45]. These properties come from the platform as a whole. A consumer Mac application, sandbox, or dynamically loaded framework does not reproduce that operator-exclusion model.

These distinctions guide the choice of execution environment.

Limitations

Assigned plaintext and host memory. Ordinary MLX execution handles readable text, tokens, and model state in unified CPU/GPU memory. Process isolation and ephemeral keys restrict intended handling; they do not make that memory confidential from a provider-controlled kernel. Local preparation replaces selected identifiers, while surrounding text may remain identifying. Owner-wide caps bound disclosure to known owners and do not defeat collusion or false identities.

Workload fit. The caller’s context, tool access and usage restrictions, as well as current operations and profile limits, decide what can run. More Macs cannot make unsupported or indivisible over-limit work fit. Tightly synchronized workloads may be better run elsewhere.

Fallible checks. Configured checks can miss errors; unresolved items and required human review remain visible.

Illustrative figures. Unless labeled as measurements, task timings, wall-power figures, role weights and calculator outputs (Section 14.4; Appendix E.2) are planning illustrations. They do not establish measured hardware performance or promised income. Measurements apply only to their declared workload, runtime release, hardware and acceptance checks.

Participation and reporting coverage. Work depends on demand and current eligibility. Electricity and emissions reports depend on coverage and declared boundaries; missing evidence stays visible.

Choose a stronger boundary when required. If a task cannot disclose even its prepared slice to an unrelated provider, select a trust model that meets that requirement. The alternatives below change either the trusted administrator or the computation itself; they are not extra guarantees supplied by ordinary sharding.

Those boundaries keep the model useful when choosing which work to delegate.

Conclusion

Lithi Compute lets customers give their preferred AI agents goals and delegate suitable batch stages to existing Macs. In compatible hosts, parent agents coordinate bounded helpers under scoped access and approved budgets. Local preparation, bounded disclosure and independent checking return source-linked results the parent can review and reconcile. Half of eligible settled distributable task revenue supports the people and businesses contributing those computing hours. Bounded feedback matches demand with qualified capacity within customer limits and each Mac owner’s control. Dated work, payout and electricity records make the value of that shared computing visible to its participants.

References

1. Model Context Protocol. Specification (2026-07-28).

2. Anthropic. Claude Code subagents and delegation controls.

3. OpenAI. Codex Model Context Protocol connections.

4. Cursor. Model Context Protocol.

5. Agent Skills. Specification and progressive disclosure.

6. OpenAPI Initiative. OpenAPI Specification.

7. NIST. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (SP 800-38D).

8. IETF. Hybrid Public Key Encryption (RFC 9180).

9. D. Connolly, P. Schwabe and B. Westerbaan. X-Wing: General-Purpose Hybrid Post-Quantum KEM. Internet-Draft, revision 06. Reference revision, not a final RFC.

10. IETF. HMAC-based Extract-and-Expand Key Derivation Function (RFC 5869).

11. Apple Developer Documentation. Protecting user data with App Sandbox.

12. Apache Parquet. Logical types.

13. Apache Arrow. Columnar format.

14. Green Software Foundation. Software Carbon Intensity specification.

15. J. Dean and L. A. Barroso. 2013. The Tail at Scale. Communications of the ACM 56(2), 74-80. DOI 10.1145/2408776.2408794.

16. W. Hoeffding. 1963. Probability Inequalities for Sums of Bounded Random Variables. Journal of the American Statistical Association 58(301), 13-30.

17. D. P. Anderson, J. Cobb, E. Korpela, M. Lebofsky and D. Werthimer. 2002. SETI@home: An Experiment in Public-Resource Computing. Communications of the ACM 45(11), 56–61.

18. M. Shirts and V. S. Pande. 2000. Screen Savers of the World Unite! Science 290(5498), 1903–1904.

19. D. P. Anderson. 2004. BOINC: A System for Public-Resource Computing and Storage. Fifth IEEE/ACM International Workshop on Grid Computing, 4–10.

20. Hugging Face. Chat templating documentation.

21. MLX. Prompt processing and generation measurements (mlx_lm.generate).

22. Lithi. Connect earnings calculator and methodology. Checked 2026-10-27.

23. U.S. Energy Information Administration. Electric Power Monthly, Table 5.3. June 2026 residential electricity price. Checked 2026-10-27.

24. Apple. Mac mini power consumption and thermal output information. Checked 2026-10-27.

25. Apple. Mac Studio power consumption and thermal output information. Checked 2026-10-27.

26. Apple. iMac power consumption and thermal output information. Checked 2026-10-27.

27. Apple. MacBook Air (13-inch, M4, 2025) technical specifications. Checked 2026-10-27.

28. Apple. MacBook Pro power adapters and charging. Checked 2026-10-27.

29. Apple Developer Documentation. Core ML: on-device model execution.

30. MLX. A framework for machine learning on Apple silicon.

31. OpenAI. ChatGPT pricing and plan usage limits. Checked 2026-10-29.

32. Anthropic. How do usage and length limits work? Checked 2026-10-29.

33. Apple Developer Documentation. Device Management. Checked 2026-10-29.

34. Gemini CLI. MCP servers with Gemini CLI. Checked 2026-10-30.

35. GitHub Docs. Extending GitHub Copilot Chat with Model Context Protocol (MCP) servers. Checked 2026-10-30.

36. S. R. Howard, A. Ramdas, J. McAuliffe, and J. Sekhon. 2021. Time-uniform, nonparametric, nonasymptotic confidence sequences. The Annals of Statistics 49(2), 1055–1080.

37. MLX. Unified memory: shared CPU and GPU access. Checked 2026-11-03.

38. Apple. Dynamic Library Programming Topics: introduction. Checked 2026-11-03.

39. Apple Platform Security. Managed Device Attestation for Apple devices. Checked 2026-11-03.

40. Apple Platform Deployment. Managed Device Attestation: enrollment, validation and freshness. Checked 2026-11-03.

41. Apple Developer Documentation. SecureEnclave.MLKEM768. macOS 26 availability. Checked 2026-11-03.

42. Apple Platform Security. Volume encryption with FileVault in macOS. Checked 2026-11-03.

43. Apple. Private Cloud Compute: Hardware Root of Trust. Checked 2026-11-03.

44. Apple. Private Cloud Compute: No Privileged Runtime Access. Checked 2026-11-03.

45. Apple. Private Cloud Compute: Software Foundations. Checked 2026-11-03.

46. NVIDIA. Confidential Computing: trust boundaries, attestation and policy-controlled secret release. Checked 2026-11-03.

47. Scaling up FHE-based Privacy-Preserving ML: Higher Throughput, Longer Inputs for LLama-3-8B. 2026. arXiv:2601.18511. Checked 2026-11-03.

48. MP-SPDZ. Protocols and security models: corruption and collusion assumptions. Checked 2026-11-03.

49. U.S. Department of Health and Human Services, Office for Civil Rights. Guidance Regarding Methods for De-identification of Protected Health Information. Checked 2026-11-04.

50. Information Commissioner’s Office. Pseudonymisation guidance. Checked 2026-11-04.

The appendices provide supporting detail: work terms, customer capabilities, encryption, billing, comparisons, and privacy and security limits.

Work terms, roles and delegation

Work terms

Table 16 defines input, logical work, physical attempts and financial authority. Recovery preserves the original work while recording any new attempt. An identifier alone grants no permission.

Acceptance, delivery and financial settlement have separate progress records. Unresolved work and its outstanding obligations remain accounted for until reconciliation under the declared completion policy.

Kit modules

The Kit has four parts that share the execution contract.

Home-cell responsibilities

Global services assign each workflow to one home cell; owners control participation.

Each home-cell state change and its outgoing queue signal commit together in one short database transaction. If a queue message is lost, the surviving record replays it under the same work identity. A trusted restart recovers in place; an approved migration advances the workflow's home epoch and fences off the old cell's authority for that workflow.

Scoped delegation

Section 5 and Figure 3 follow the goal-to-result cycle. Work keys bind API permissions and expiry; shared funded task identity and spend policy govern limits. Labels create no credit. Independently managed helpers use separate keys and connections where hosts support them; provider Macs use execution permits.

Approved source versions or completed snapshots identify paid input. Each scheduled occurrence keeps its original identity for redelivery; deliberate reprocessing needs new approval. Delivery uses approved destinations and resource-scoped credentials. Private-network and loopback endpoints are excluded to prevent internal network probing; loopback refers to the local computer itself.

The host owns context, nesting, checkpoints, time, calls, iterations, concurrency and stopping rules. The Kit has no independent scheduler or retry daemon. Changed destinations, broader disclosure, unresolved submissions, exhausted allowance or security holds pause continuation until reconciliation. The host resumes its saved plan, checking results, coverage, exceptions and full cost. Revocation restricts future actions; accepted work and obligations remain recorded and reconcile.

Service outputs and checks

This catalog groups 46 customer capability identities into the seven domains introduced in Section 4. Four additional build and test manifests are internal. The domain labels organize the lookup; each operation’s approved profile determines the work it can perform.

Each admitted release fixes its reader, representation, runtime, limits, metering and checks. Current discovery determines available profiles. Table 18 fixes the model, tokenizer and prompt-template identities for the MLX path; a different release needs its own admitted profile.

Table 19 is the domain index. Its examples describe useful operations across text, records, visuals, audio, and tensors; a workflow can combine capabilities from several domains.

Joining shard outputs

A declared reducer combines partial results rather than simply concatenating them. Counts and sums produce exact means; ranking, deduplication, and joins need their declared cross-piece rules. Merge stages preserve source identity and the same disclosure limits.

Preparation obligations

On your machine, the Kit fixes the source version and checks format and resource limits. Document ID 000123 remains a string, not 123. The manifest records which inspections ran, distinguishing inspected with no findings from not inspected:

• Typed records: JSON, JSONL, CSV, Parquet and Arrow profiles preserve IDs, integer precision, decimal scale, nulls and timestamps. Related records can cross row groups, so required groups stay together before encryption; unsupported nesting or conversions are not silently flattened [12, 13].
• Documents: PDF and scans preserve reading order and tables; supported OCR reports regions and uncertainty. Workbooks distinguish formulas from cached values, and slides retain order and permitted notes.
• Media: Admitted image, audio and video profiles govern codecs, tracks, language, channels, timebases and coordinates.
• Archives and repositories: Admitted members retain stable relative paths and revision identity. An extension alone does not admit a decoder or codec.

Capability catalog

A workflow may reuse a capability at several stages. Each approved profile fixes the reader, representation, runtime, limits, metering, and checks. Table 20 groups the 46 identities in the same domain order as Table 19. Read each input, returned result, and checking subject together; current discovery supplies precise profile limits. The returned artifact and check records establish the outcome; an output digest alone is incomplete.

Encryption and key access

The Lithi Compute Kit encrypts permitted input before transfer. Storage access and permission to release keys remain separate, as Figure 11 shows.

Table 21 names the public cryptographic methods and their roles [7, 8, 9, 10].

Key release checks the complete assignment described in Section 10.1, including account, device, worker session, release, model, task, attempt, lease, fence, expiry, and recipient. Current cell identity and epoch remain part of that authority. Execution and checking receive separate authorization after the owner-exposure reservation.

X-Wing defines shared-secret establishment, not hardware key custody. A software CryptoKit private key, including a key reconstructed from an imported seed, does not establish non-exportability. The execution boundary requires fresh task keys inside the executor and excludes usable keys from UI state, transport, and persistent task storage. Secure Enclave ML-KEM-768 offers a separate hardware key mechanism on supported systems [41]; protocol compatibility and lifecycle need their own qualification.

Software expiry checks and revocation prevent future authorized releases. Server-side fencing rejects stale state after snapshot restoration. Neither control can invalidate key material or plaintext a hostile host already copied. Table 6 preserves the distinction between required process handling and host-memory exposure.

Metering, billing records and collection

Table 22 specifies how signed recipes count each representation under the tariff in Equation (1). Internal ledgers track holds, recognized usage and balances in integer nano-dollars, or billionths of a US dollar. Display rounding changes neither admission nor settlement. Purchases, usage and refunds remain separate records.

Count admitted work

Counts follow the content the operation actually consumes. A document contributes extracted text and page visuals only when those visuals are read; video contributes its admitted frames and audio. Archives and repositories contribute admitted members without a container surcharge. Content already embedded in a prompt is not counted again as a separate input attachment.

Accepted output is the actual returned content under its metering recipe, not a digest or receipt describing it. Every accepted output resolves to a positive count or an explicit deterministic zero-output rule; missing output never counts as zero. Counts bind to the pinned tokenizer, template, canonicalization, and metering profile. Identical canonical input under the same profile gives the same count regardless of executor speed or target earnings. Table 23 distinguishes the three work quantities.

Example: the account balance for Section 13. Funding $100 of credit, excluding tax, and applying Table 11's $0.40 hold leaves $99.60 available. Recognizing the $0.396 charge and closing the remaining obligation without further billable usage releases unused credit, leaving $99.604 available.

At the assumed 40 W role means, multiply 40 watts by 5,000 translation seconds per Mac and divide by 3.6 million. This gives 0.0555556 kWh mean per translating Mac, or 1.111111 kWh across 20 Macs. Checking uses 1,000 seconds per Mac, giving 0.0111111 kWh per Mac and 0.222222 kWh across 20 Macs. The occupied-slot total is 1.333333 kWh.

See the billing guide for purchase, invoice, reload and refund procedures.

Funding and reconciliation

Funding, accepted usage, reserved credit, refunds and provider payouts retain separate records. Repeated payment events credit the original purchase once; refunds reconcile eligible unused value under the original identity. Uncertain payments, refunds and disputes keep their holds until resolved. Access to retained invoices and statements remains available at zero credit. New reservations require current funding authority, while existing grants retain their finite limits during an outage.

The billing and invoice guide explains credit purchases, paid invoices, prepaid usage statements and refund documents. These documents distinguish prepayment from service use so importing them preserves one expense and payable history.

Automated rule verification. Disposable PostgreSQL, Redis/BullMQ, and mocked-payment suites check that stale attempts cannot replace committed winners; parallel reservations respect owner allowance A; and recognition consumes held credit once without overspending. Expired leases, lost messages, stale epochs, and interrupted payment replies recover from committed records and outboxes. An outbox saves pending messages with related state in one transaction. Recovery is idempotent: repeating a committed action creates no extra acceptance, authority, or charge. These suites verify execution and accounting; separate evaluations assess model quality and fleet performance.

Security acceptance requirements. Accepting an executor boundary requires evidence that forged hardware claims, substituted recipient keys, mismatched worker sessions, and replayed or expired permits are rejected. Crash, reboot, and snapshot tests must preserve fresh-authorization requirements. Synthetic customer markers must be searched for in UI state, broker logs, persistent caches, and other locations outside the intended worker boundary. Hostile payload tests must exercise access to provider files, credentials, local networks, and unrestricted code execution. Test records identify the signed build, device, policy, exercised path, and observed result. Source inspection or a passing software test does not establish confidentiality from a provider-controlled operating system.

Comparing configurations

A lower bill and a better result are different findings. Compare the full cost of meeting the same task requirements, then assess whether the evidence supports an improvement.

Compare the full cost

See Section 15 for the full-cost comparison.

Input-heavy work and Mac earnings

Under Equation (1), 1 million billable input tokens and 1,000 billable output tokens cost $0.0501. If the full charge is eligible and settled, its provider pool is $0.025050 under Equation (4). This task allocation is distinct from the monthly hardware illustrations in Section 14.4.

Section 15 compares input-heavy work on the same full-cost and quality basis, including local preparation.

Decide whether the outcome improved

Use independent source-family groups with equally weighted scores Y between zero and one. Retries and shards stay within their group. Fix sample sizes, planned comparisons, and one analysis time. Hoeffding’s inequality bounds uncertainty for independent outcomes within known limits, without assuming a bell-curve distribution [16]. Equation 9 uses it to compare mean group scores. Add and subtract the sum of both allowances around the difference in means.

delta_hat = mu_hat(B) - mu_hat(A); epsilon(a) = sqrt(ln(4K / alpha) / (2 * n(a))), for a in {A, B}.

The hatted means are average group scores; n counts independent groups per method, K planned comparisons, and α family-wise interval error. With 1,000 groups per method, K = 1 and α = 0.05, each allowance is about 4.68 percentage points. The hypothetical three-point gain therefore remains inconclusive. Table 24 shows the worked comparison.

Improvement requires the entire interval above a predeclared threshold δ and all quality and safety floors. A non-inferiority comparison asks whether a candidate falls behind the baseline by no more than a predeclared acceptable margin. A cheaper processing path still has to satisfy that quality rule. Count every assigned group and bound missing scores conservatively.

Repeatedly checking a fixed-sample interval and stopping when it looks favorable can exceed its declared error rate. A confidence sequence is an uncertainty bound designed to stay valid across repeated looks under its stated assumptions [36]. Sequential methods, adaptive candidates, and reused groups require a method justified for that sampling design.

Test and approve network changes

Operational controls react inside an approved policy. The slower experimental loop asks whether a permitted setting should change. Figure 12 follows one candidate through a fixed comparison, evaluation, and separate release approval. Home cells retain acceptance.

The comparison records assigned groups, accepted coverage, quality, deadline performance, full cost, and qualified electricity evidence. Missing outcomes follow the declared analysis rules. Statistical evidence informs the release decision; it grants no deployment authority. After release, monitoring admits qualified findings for the next proposal and retains rollback. Running jobs keep their approved settings.

Table 25 lists permitted comparison dimensions and the invariants that remain fixed across every trial.

Participation scenario

Assume a hypothetical base of 100 million M-series Macs, 15% participation and 10 offered hours per participant per day. For an admitted generative profile, set an assumed output-decoding rate of 40 tokens per second of occupied decoding time. One decoding hour yields 144,000 output tokens; ten full decoding hours yield 1.44 million. These are physical output-decoding units; input prefill and signed media-meter recipes use their own units.

These figures describe offered slots and decoding-time capacity; the 5/6 fraction borrows the translation example's generation/checking time split. Equation 3 adds input processing and task overhead, while occupancy, decoding duty factor and accepted yield determine completed output; Mac-hours describe internal scenario capacity.

Privacy and security limits

Table 27 pairs risks with their remaining limits. Both routing modes retain approved data, jurisdiction and disclosed execution boundaries. Geographic dispersion does not establish anonymity; de-identification requires a separate assessment [49, 50].

Scoped pseudonymization and restoration

Aliases use keyed, domain-separated derivation of reviewed entity IDs within tenant, purpose and dataset scope. The private map stays local and version-stable across retries. Equal names do not merge different people; ambiguous mentions need review. Reverse mappings stay outside provider manifests, ordinary agent context and logs. Restoration requires item-scoped permission; wrong-scope requests are refused.

Agent reference and permissions

Use the Work interface and permissions for task submission. Current profiles and limits come from GET /v1/capabilities; request and response schemas come from /.well-known/compute-openapi.json. Account access, availability, approval, and admission are separate checks. This paper explains responsibilities and grants no access or execution authority.