Route workloads by five properties.

Video caption

Route workloads by five properties.

A busy shop floor and a rare exception need different service.

Pin the models, hardware and full acceptance path.

Escalation is part of the design.

#EricFieldNotes

Full written post / accessibility read

Before choosing where an AI task runs, write down five properties: required answer quality, privacy boundary, latency budget, concurrency and recovery tolerance. Without them, 'local is cheaper' and 'cloud is smarter' are both shortcuts.

In an illustrative plant-support workflow, a gateway handles routine short event labels locally and keeps raw state on site. A rare incident needs broader context and careful review. Sending every routine event remote adds network dependency; forcing every exception local risks poor judgment.

Use representative data that can legally cross each boundary. Test cold and warm latency, peak concurrency, task-specific correctness, recovery after lost connectivity and operator rescue. Price the complete accepted response, not a model call or device hour.

Keep bounded private work local when it passes; use a hosted or owner review path when the task, load or uncertainty demands it. Do this because the optimal split can change with workload and the cost of being wrong.

#EricFieldNotes

Four-beat scene transcript

1. Route workloads by five properties.

Before choosing where an AI task runs, write down five properties: required answer quality, privacy boundary, latency budget, concurrency and recovery tolerance. Without them, 'local is cheaper' and 'cloud is smarter' are both shortcuts.

Visual: Local and cloud solve different constraints.

2. The wrong route hurts a specific slice.

In an illustrative plant-support workflow, a gateway handles routine short event labels locally and keeps raw state on site. A rare incident needs broader context and careful review. Sending every routine event remote adds network dependency; forcing every exception local risks poor judgment.

Visual: A busy shop floor and a rare exception need different service.

3. Measure all five on real cases.

Use representative data that can legally cross each boundary. Test cold and warm latency, peak concurrency, task-specific correctness, recovery after lost connectivity and operator rescue. Price the complete accepted response, not a model call or device hour.

Visual: Pin the models, hardware and full acceptance path.

4. Choose a route per case class.

Keep bounded private work local when it passes; use a hosted or owner review path when the task, load or uncertainty demands it. Do this because the optimal split can change with workload and the cost of being wrong.

Visual: Escalation is part of the design.

Research and claim limits

• Moonshot AI: Kimi K3 official model card (S128)
• Apple: current Mac mini technical specifications (S129)

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.