§ NEW · 20-Node Mesh Connection Guide
Connecting 20 nodes to the distributed inference fabric.
A complete, production-ready reference for integrating every node with routing, scheduling, metering, DIU issuance, DIU spend, and settlement logging. Each section maps to an equivalent AWS multi-node compute onboarding step.
G.0
Guide overview & scope
This guide documents the authoritative process for connecting exactly 20 heterogeneous compute nodes to the MeshInfer.AI distributed inference fabric. Each node, regardless of platform, must complete a five-phase lifecycle before it is eligible to receive routed inference tasks:
- Phase IIdentity provisioning — NodeID, DeviceID, OrgID chain-of-trust
- Phase IIRegistration — capability declaration, DOSFI handshake, Coordinator enrollment
- Phase IIIRouting participation — admission to the task routing pool
- Phase IVMetering & economics — DIU spend accounting, inference-to-DIU issuance, settlement
- Phase VOngoing operations — health checks, reputation scoring, removal / replacement
DIU — Distributed Intelligence Unit
Throughout this guide, Vital is the colloquial name for the platform's economic unit. Its formal designation is Distributed Intelligence Unit (DIU). All metering, issuance, and settlement values are denominated in DIU. DIU is non-transferable outside the MeshNativeExchange settlement layer unless explicitly bridged.
Reference topology — 20-node mesh
topology
┌─────────────────────── DOSFI IDENTITY SERVICE ─────────────────────────┐
│ identity.dosfi.ai · OAuth 2.0 + OIDC · OrgID: org_mesh20_prod │
└──────────────────────────────┬──────────────────────────────────────────┘
│ mTLS chain-of-trust
┌─────────────────────── MESHINFER COORDINATOR ──────────────────────────┐
│ coordinator.meshinfer.ai · Gateway (CF Edge) · Router Engine │
│ Node Registry (Redis) · Task Queue (NATS JS) · Billing Meter │
└──┬────────────────────────────────────────────────────────────────────┘
│ Registered & active nodes (20 total)
├── DESKTOP TIER (8 nodes) ─────────────────────────────────────────
│ node-d01 … node-d08 · Linux/macOS/Windows · llama.cpp GGUF
├── BROWSER TIER (6 nodes) ─────────────────────────────────────────
│ node-b01 … node-b06 · Chrome/Edge · WebGPU / WASM fallback
├── MOBILE TIER (4 nodes) ─────────────────────────────────────────
│ node-m01 … node-m04 · iOS/Android · CoreML / NNAPI
└── SERVER TIER (2 nodes) ─────────────────────────────────────────
node-s01, node-s02 · Linux bare-metal · CUDA 12+ / 70B models
G.1
Phase I — Node Identity Model
Every node in the mesh is assigned a cryptographic identity before it is permitted to register. The identity model mirrors the chain-of-trust established by the DOSFI Identity Service at identity.dosfi.ai.
Identity hierarchy
| OrgID | Top-level organizational namespace. Created once per tenant. Format: org_{slug}_{env}. Controls billing, policy inheritance, and DIU settlement wallet. |
| UserID | Human operator identity. Bound to OrgID via OIDC claims. Required to issue API keys and approve node registrations. |
| DeviceID | Stable hardware fingerprint. Derived from TPM-attested UUID or, on non-TPM devices, a persisted Ed25519 keypair stored in secure enclave / IndexedDB. Never regenerated unless node is explicitly decommissioned. |
| NodeID | Runtime identity for one active mesh participant. Format: node_{uuid4}. Generated by the Coordinator on first successful registration. A DeviceID can hold at most one active NodeID at a time. |
| APIKeyID | Operator-issued bearer token. Bound to UserID + OrgID. Used for all Coordinator API calls. Rotatable without invalidating NodeID. |
Identity binding chain
sequence
OrgID
└── UserID (OIDC JWT, signed by identity.dosfi.ai)
└── APIKeyID (msk_live_..., scoped to OrgID)
└── DeviceID (Ed25519 pub, signed by UserID at registration)
└── NodeID (issued by Coordinator after DeviceID verification)
└── DIU Wallet Address (auto-created by MeshNativeExchange
on first NodeID activation)Key material lifecycle
| Ed25519 node keypair | Generated on-device at first install. Private key never leaves hardware secure enclave (Keychain/Keystore/TPM). Public key transmitted to Coordinator at registration. |
| Session key | AES-256-GCM derived via TLS exporter (RFC 5705) per WebSocket connection. Ephemeral — not stored anywhere. |
| Capability signature | Every heartbeat payload is signed with the node Ed25519 private key. Coordinator verifies against registered public key. |
| Key rotation | Growth/Enterprise tier: automated rotation every N days via scheduleAPIKeyRotation function. NodeID persists across API key rotation. |
Equivalent AWS concept
NodeID + DeviceID maps to an IAM Role + EC2 instance profile. OrgID maps to an AWS Account. The DIU Wallet Address maps to an AWS Cost Allocation Tag used for chargeback.
G.2
Phase II — Node Registration Flow
Step-by-step: registering one node
1
Install the node client
Run the platform-specific installer from the Download page. The installer generates the Ed25519 keypair, creates the DeviceID, and writes the local config to ~/.meshinfer/node.toml.
bash
# macOS / Linux
curl -fsSL https://get.meshinfer.ai/install.sh | sh
# Windows
iwr https://get.meshinfer.ai/install.ps1 | iex2
Authenticate with DOSFI Identity Service
The node daemon performs an OAuth 2.0 device-flow against identity.dosfi.ai. On success, a short-lived OIDC access token is returned and cached locally (15-min TTL, auto-refreshed).
bash
meshinfer-node auth --org org_mesh20_prod
# Opens browser → identity.dosfi.ai/device
# Displays one-time code: MESH-A1B2-C3D4
# User confirms in browser → token issued3
Run the capability probe
The daemon queries local hardware (GPU, RAM, CPU, battery, network) and produces a signed capability vector. This takes ≤ 40 ms and is re-run on each Coordinator reconnect.
bash
meshinfer-node probe
# Output:
# cpu: 8 cores · arm64 · neon+i8mm
# gpu: Apple M3 Pro · 18432 MB VRAM · WebGPU ✓
# ram: 18432 MB total · 9112 MB free
# net: rtt=34ms · 118 Mbps · 4g
# sig: ed25519:abc123...4
POST /v1/nodes/register to the Coordinator
The daemon sends the capability vector, DeviceID, and OIDC token to the Coordinator. The Coordinator verifies the OIDC signature against identity.dosfi.ai JWKS, issues a NodeID, and provisions the DIU wallet.
bash
POST https://coordinator.meshinfer.ai/v1/nodes/register
Authorization: Bearer msk_live_YOUR_API_KEY
Content-Type: application/json
{
"device_id": "did:mesh:abc123...",
"oidc_token": "eyJhbGc...",
"capability": { ...signed_probe_output... },
"platform": "desktop",
"region": "us-east",
"mesh_profile":"standard"
}
# Response 201 Created:
{
"node_id": "node_f9a3e2b1...",
"diu_wallet": "wallet_7c2d...",
"registry_ttl_s": 1800,
"heartbeat_interval_s": 15
}5
Open persistent WebSocket for heartbeats
The daemon opens a WebSocket to stream.meshinfer.ai/v1/nodes/stream using the NodeID as the session identifier. Heartbeats are sent every 15 s. Missing 3 consecutive heartbeats downgrades status to degraded; 6 missed → eviction.
bash
wss://stream.meshinfer.ai/v1/nodes/stream
Authorization: Bearer msk_live_...
X-Node-ID: node_f9a3e2b1...
→ { "type": "heartbeat",
"node_id": "node_f9a3e2b1...",
"ts": "2026-07-06T14:00:00Z",
"load": { "active_tasks": 0, "cpu_pct": 12 },
"battery": { "level": 0.94, "charging": true },
"thermal": "nominal",
"sig": "ed25519:..." }
← { "type": "ack", "server_ts": "2026-07-06T14:00:00.031Z" }Batch registration — all 20 nodes
For fleet deployments, use the fleet provisioning script. It reads a manifest file and registers all nodes in parallel, emitting a registration report on completion.
bash
# nodes.yaml — fleet manifest
nodes:
- id: node-d01
platform: linux
region: us-east
profile: standard
- id: node-d02
platform: linux
region: us-east
profile: standard
# ... 18 more ...
# Run fleet registration
meshinfer-fleet register --manifest nodes.yaml --api-key msk_live_... --org org_mesh20_prod --parallel 5
# Output: nodes_registration_report_2026-07-06.jsonG.3
Phase II-B — Dual Handshake Protocol
DOSFI identity handshake
The DOSFI handshake establishes cross-platform identity binding. It occurs once per DeviceID lifetime and must succeed before the Coordinator registration in Phase II.
sequence
Node Daemon identity.dosfi.ai Coordinator
│ │ │
│── /device/auth ───────►│ │
│◄── device_code ────────│ │
│ │◄── user_confirms ──────(browser)
│◄── access_token ───────│ │
│ (oidc_jwt, 15min) │ │
│ │ │
│── /v1/nodes/register ──────────────────────────►│
│ { oidc_jwt, device_id, capability_vec } │
│ │──JWKS verify ─────────►│
│ │◄──pub key(s) ──────────│
│◄── { node_id, diu_wallet } ────────────────────│
│ │ │MeshInfer Coordinator handshake
After DOSFI authentication, the Coordinator performs its own handshake to admit the node into the routing pool. This is an mTLS-authenticated exchange.
sequence
Node Daemon Coordinator
│ │
│── TLS ClientHello ──────────►│
│◄── TLS ServerHello ──────────│ (CF cert)
│── Client Certificate ────────►│ (Ed25519 node cert, signed by DOSFI CA)
│◄── Certificate Verified ──────│
│ │
│── { node_id, capability_vec, │
│ mesh_profile, region, │
│ sig: ed25519(...) } ────►│
│ │── verify sig against registered pubkey
│ │── capability eligibility check
│ │── assign routing pool slot
│◄── { admitted: true, │
│ pool_tier: "standard", │
│ task_queue_subject: "tasks.us-east.standard",
│ heartbeat_interval: 15 │
│ } ─────│Handshake failure modes & recovery
| OIDC token expired | Daemon auto-refreshes via refresh_token. If refresh fails → re-run device-flow auth. |
| JWKS verification failure | Coordinator rejects registration. Check that identity.dosfi.ai is reachable from the Coordinator network. Retry with exponential backoff (max 5 attempts). |
| Capability ineligible | Coordinator returns 422 with ineligibility reason (e.g. "insufficient_vram"). Node cannot join pool for rejected model sizes; may still serve smaller models. |
| mTLS cert mismatch | Ed25519 cert in ClientHello does not match registered DeviceID. Re-run `meshinfer-node auth` to re-issue the DOSFI-signed certificate. |
| Region quota exceeded | Coordinator returns 429 with Retry-After header. Fleet manager queues and retries; does not count against reputation. |
G.4
Phase III — Routing Participation Rules
Admission criteria
Traffic weight assignment
The Router assigns a weight to each eligible node in the pool based on reputation, uptime, model cache state, and latency adherence. Selection uses weighted random over the eligible pool. A small exploration factor routes a fraction of requests to random eligible nodes to maintain continuous learning and prevent any single node from monopolizing traffic.
The exact weight function, decay curves, and exploration constant are Coordinator-internal and tuned per release. Node operators influence their weight indirectly: higher reputation, better uptime, warm model caches, and lower latency all increase routing weight.
Pool tiers & task assignment
| standard | Eligible for all req_class ∈ {tiny, small}. Assigned to the standard task queue for its region. |
| capable | Eligible for req_class ∈ {tiny, small, medium}. Reputation ≥ 70 required. |
| elite | Eligible for all req_class including hard (70B+ sharded). Reputation ≥ 85, uptime ≥ 95%, ≥ 3 models cached. |
| restricted | Reputation 20–39: tiny tasks only, 10% traffic share max. Under monitoring. |
| suspended | Reputation < 20 or verification pass rate < 90%: zero tasks. Human review required. |
Equivalent AWS concept
Pool tiers map to ECS task placement constraints + Auto Scaling Groups with min/max capacity. Traffic weight formula is equivalent to Weighted Target Group routing in an ALB.
G.5
Phase III-B — Inference Scheduling Participation Rules
Task lifecycle on a node
sequence
NATS JetStream Node Daemon Coordinator
│ │ │
│─ tasks.region.tier ──────►│ │
│ { task_id, model, │ │
│ prompt_enc, │ │
│ deadline_ms, │ │
│ cost_slo_usd } │ │
│ │── preflight check │
│ │ (thermal, battery, │
│ │ model cached?) │
│ │── ACK (accept) ───────►│
│ │── start inference │
│ │── stream tokens ──────►│
│ │── task_complete ───────►│
│ │ { result_hash, │
│ │ tokens_out, │
│ │ latency_ms } │
│ │◄── meter_event ────────│
│ │ (DIU issued to node │
│ │ wallet on settlement)│Scheduling priority classes
| interactive | Deadline ≤ 200 ms to first token. Only local or top-10 reputation mesh nodes eligible. Never cold-start. Preempts background tasks on the node. |
| standard | Deadline ≤ 2 s to first token. Full eligible pool. Cold-start allowed if model loads within 800 ms. |
| background | No deadline. Lowest cost mesh nodes. Batching enabled (up to 8 concurrent tasks per node). Used for embeddings, summarization, fine-tune prep. |
| verification | A sample of all tasks re-dispatched here for deterministic-decode hash comparison. Must match original result hash. Mismatch → reputation penalty + investigation. |
Node-side scheduling rules
| Max concurrent tasks | Configurable per node. Default: 2 (standard), 8 (background). Hard cap enforced by daemon — excess task offers are NACKed to Coordinator. |
| Task acceptance deadline | Node must ACK or NACK within 500 ms of receiving task. No response → Coordinator re-dispatches with exponential backoff. |
| Preemption policy | Background tasks may be preempted by interactive tasks if the node has reached its concurrency cap. Preempted background task is re-queued; node reputation is not penalized. |
| Model cold-start window | Coordinator allocates up to 800 ms for model load before counting against latency SLO. Node must report model_loading: true in its NACK to trigger this window. |
G.6
Phase IV — Compute Metering → DIU Spend
Every inference request that consumes mesh compute generates a metering event. Metering quantifies how much DIU the requester spent on each task. Settlement (§ G.7) then determines how much DIU the serving node earned.
Metering event structure
json
{
"event_type": "inference_metered",
"request_id": "req_a1b2c3...",
"node_id": "node_f9a3e2b1...",
"user_email": "operator@org.com",
"org_id": "org_mesh20_prod",
"model": "llama-3.2-3b-q4",
"req_class": "small",
"route_decision": "mesh",
"tokens_in": 128,
"tokens_out": 512,
"latency_ms": 284,
"success": true,
"hypothetical_cloud_cost_usd": 0.00034,
"actual_cost_usd": 0.00008,
"diu_spend": 0.08,
"diu_savings": 0.26,
"timestamp": "2026-07-06T14:02:33.120Z"
}DIU spend calculation
pseudo
# DIU spend rate per 1,000 tokens (read from DOSFI pricing oracle):
RATES = {
"tiny": { local: 0.0, mesh: 0.02, cloud: 0.08 },
"small": { local: 0.0, mesh: 0.08, cloud: 0.34 },
"medium": { local: 0.0, mesh: 0.24, cloud: 1.20 },
"hard": { local: 0.0, mesh: 0.80, cloud: 4.80 },
}
diu_spend(event) =
(event.tokens_out / 1000) * RATES[event.req_class][event.route_decision]
# Example:
# 512 tokens_out, req_class="small", route="mesh"
# diu_spend = (512 / 1000) * 0.08 = 0.04096 DIUMetering pipeline
| Coordinator Billing Meter | Emits metering events to Kafka topic meshinfer.metering.events on task completion. |
| ClickHouse aggregator | Consumes Kafka stream, writes to UsageRecord entity. Aggregates into MetricSnapshot hourly/daily/monthly. |
| DOSFI pricing oracle | Consulted once per billing period to update DIU rate table. Rate changes take effect on the next billing period — no retroactive adjustments. |
| Requester wallet debit | OrgID DIU wallet is debited atomically with the metering event write. No credit means no task dispatch. |
| Audit trail | Every metering event written to AuditLog entity with resource_type: "inference_charge" for SOC 2 compliance. |
G.7
Phase IV-B — Inference Execution → DIU Issuance
When a node successfully completes an inference task, it earns DIU. Issuance is calculated from the metering event and credited to the node's wallet by the MeshNativeExchange settlement layer.
DIU issuance calculation
When a node successfully completes a task, it earns a share of the requester's DIU spend. The issuance amount is determined by three factors:
- Node share: A fixed portion of the DIU spend is allocated to the serving node; the remainder covers platform infrastructure and protocol reserve.
- Reputation multiplier: Higher-reputation nodes earn an elevated multiplier. Elite-tier nodes receive the highest bonus; low-reputation nodes receive a reduced rate.
- Quality multiplier: Nodes that meet latency SLOs earn the full multiplier. Tasks completed beyond a multiple of SLO, or failed tasks, yield zero DIU — no payment for poor service.
The exact share ratios, multiplier thresholds, and decay curves are Coordinator-internal economic parameters. They are tuned to ensure compute-backed sustainability and are not publicly replicable.
Issuance event structure
json
{
"event_type": "diu_issued",
"settlement_id": "stl_x9y8z7...",
"node_id": "node_f9a3e2b1...",
"diu_wallet": "wallet_7c2d...",
"source_request_id": "req_a1b2c3...",
"diu_gross": 0.04096,
"reputation_mult": 1.10,
"quality_mult": 1.00,
"diu_net": 0.04506,
"platform_fee": "<platform share of gross>",
"reserve": "<protocol reserve of gross>",
"settlement_epoch": "2026-07-06T15:00:00Z",
"status": "pending_settlement"
}Settlement timing
DIU issuance events are pending until the settlement epoch closes (every hour). At epoch close, MeshNativeExchange batches all pending events, verifies integrity, and commits final wallet credits. Nodes can view pending DIU in real time; settled DIU is final and auditable on-chain.
G.8
Phase IV-C — Settlement Logging → MeshNativeExchange
Settlement lifecycle
sequence
Coordinator MeshNativeExchange Node Wallet
Billing Meter Settlement │
│ │ │
│── diu_issued events ─────►│ │
│ (batch, hourly epoch) │ │
│ │── aggregate batch │
│ │── integrity check │
│ │ (hash chain verify) │
│ │── commit credits ─────►│
│ │ { wallet, diu_net, │
│ │ settlement_id } │
│ │── write SettlementLog │
│ │ → AuditLog entity │
│◄── epoch_settled ACK ────│ │
│ │── publish to DOSFI │
│ │ accounting oracle │Settlement log record
json
{
"settlement_id": "stl_epoch_20260706T150000Z",
"epoch_start": "2026-07-06T14:00:00Z",
"epoch_end": "2026-07-06T15:00:00Z",
"org_id": "org_mesh20_prod",
"node_settlements": [
{
"node_id": "node_f9a3e2b1...",
"diu_wallet": "wallet_7c2d...",
"tasks_served": 147,
"tokens_out": 89234,
"diu_gross": 6.234,
"diu_net": 6.083,
"status": "settled"
}
// ... 19 more nodes ...
],
"total_diu_issued": 98.441,
"total_platform_fee": 17.720,
"total_reserve": 9.844,
"integrity_hash": "sha256:cafe...",
"committed_at": "2026-07-06T15:00:34Z"
}Settlement entity fields (AuditLog)
| resource_type | "settlement_epoch" — queryable via audit log endpoint |
| action | "diu_settled" | "diu_disputed" | "diu_clawback" |
| status | "success" | "failure" | "disputed" |
| details.node_count | Number of nodes settled in this epoch |
| details.integrity_hash | SHA-256 hash of full settlement batch — verifiable externally |
G.9
Phase V — Node Health Checks
Health check types
Health check record schema
json
// NodeHealthCheck entity record:
{
"node_id": "node_f9a3e2b1...",
"check_type": "latency_test",
"status": "pass",
"latency_ms": 187,
"details": {
"model": "llama-3.2-3b-q4",
"req_class":"small",
"slo_ms": 300
},
"timestamp": "2026-07-06T14:05:00Z"
}G.10
Phase V-B — Node Performance Scoring
Reputation score components
Score update frequency
| Real-time component | Reputation score updated immediately on verification mismatch, thermal eviction, or missed heartbeat. |
| Rolling component | Full score recalculated every 15 minutes using a 7-day weighted rolling window. Recent events weighted 2× vs. older events. |
| Score floor | A minimum score floor protects against one-time anomalies destroying new nodes. Below a configured threshold → auto-suspended. |
| Score ceiling boost | Nodes sustaining near-perfect metrics over a sustained period earn a permanent Elite bonus that stacks with the reputation multiplier in DIU issuance. |
G.11
Phase V-C — Node Privacy Tier Enforcement
Privacy tiers
| local_only | Node serves only tasks from its own registered OrgID. No external prompts processed. Enforced at Coordinator — tasks from other orgs are never dispatched. |
| mesh_ok | Node serves tasks from any OrgID in the mesh. Prompts are encrypted (AES-256-GCM) end-to-end — node sees only ciphertext of the prompt, decrypts result for hash. |
| cloud_ok | Node may also be used as a relay for cloud fallback proxying. Only applies to server-tier nodes with explicit opt-in. |
Privacy enforcement stack
Privacy is enforced structurally at two layers:
- Coordinator-side (server): Before any task is dispatched, the Coordinator verifies that the node's privacy tier is compatible with the requester's privacy policy.
local_onlytasks are never sent to nodes outside the requester's OrgID.no_cloudtasks bypass cloud-relay nodes entirely. - Node-side (daemon): The daemon independently re-verifies the privacy tier before accepting any task. If a
local_onlynode receives a task from a different OrgID, it NACKs immediately. Prompts are decrypted only in memory, processed, and the result is re-encrypted before transmission — plaintext never leaves the node.
This dual-layer enforcement means privacy is a structural property of the dispatch path, not a runtime policy check that could be bypassed.
G.12
Phase V-D — Node Removal & Replacement Flow
Graceful removal
bash
# Initiate graceful drain on one node:
meshinfer-node drain --node-id node_f9a3e2b1...
# Drain process:
# 1. Coordinator marks node as "draining" — no new tasks dispatched
# 2. In-flight tasks complete normally (up to drain_timeout = 300 s)
# 3. After all tasks complete, daemon sends DEREGISTER to Coordinator
# 4. NodeID moved to "decommissioned" status in registry
# 5. DIU wallet settlement finalized for all pending epochs
# 6. DeviceID retained — can re-register as a new NodeIDEmergency removal (reputation / security breach)
| Triggered by | Reputation score below the minimum floor, verification mismatch rate exceeding threshold, security policy violation, or admin manual override. |
| Immediate effect | Node removed from all routing pools. In-flight tasks cancelled and re-dispatched to next-best node. Requester is not charged for cancelled tasks. |
| Reputation impact | Score set to 0 and frozen. Node cannot re-register with same DeviceID for 72-hour cooling-off period. |
| DIU clawback | Pending unsettled DIU issuance events for the flagged node are held for 24 hours pending review. Settled DIU is final. |
Node replacement procedure
1
Identify the node to replace
Use the Node Monitor dashboard or the GET /v1/nodes/{node_id} API to retrieve current status.
2
Drain the target node
Run `meshinfer-node drain --node-id <id>`. Wait for drain_complete confirmation (≤ 300 s).
3
Decommission
Run `meshinfer-node decommission --node-id <id>`. DeviceID is preserved for re-use if desired.
4
Provision replacement
Install client on replacement hardware. Run Phase I–II registration. New NodeID issued.
5
Verify pool admission
Check `meshinfer-node status` shows pool_tier ≠ "suspended". Run the Mesh Verification Test (§ V.1) on the new node.
6
Confirm DIU wallet
New NodeID has a new DIU wallet. Old wallet remains accessible for historical earnings but receives no new issuance.
G.A
Appendix — Per-Node Configuration Reference
toml
# ~/.meshinfer/node.toml — full configuration reference
[identity]
org_id = "org_mesh20_prod"
api_key = "msk_live_..." # rotate via scheduleAPIKeyRotation
node_id = "" # auto-populated on registration
device_id = "" # auto-populated on first probe
[coordinator]
endpoint = "https://coordinator.meshinfer.ai"
stream_ws = "wss://stream.meshinfer.ai/v1/nodes/stream"
region = "us-east" # us-east | us-west | eu-west | ap-south
heartbeat_s = 15
reconnect_backoff_ms = [500, 1000, 2000, 5000, 10000]
[mesh]
profile = "standard" # eco | standard | power | off
privacy_tier = "mesh_ok" # local_only | mesh_ok | cloud_ok
max_concurrent_tasks = 2
max_background_tasks = 8
[hardware]
gpu_util_cap_pct = 50 # max GPU utilization while serving tasks
cpu_util_cap_pct = 60
battery_floor = 0.20 # pause mesh work below this (mobile)
require_charging = true # mobile only
thermal_max = "fair" # nominal | fair | serious | critical
[models]
cache_dir = "~/.meshinfer/models"
auto_download = true
preferred = [
"llama-3.2-3b-q4",
"phi-3.5-mini-q4",
"qwen-2.5-7b-q5"
]
[logging]
level = "info" # debug | info | warn | error
audit_log = true # write local audit trail
telemetry = true # send telemetry to Coordinator