The Daemon Behind the Command

Magnitude's local inference experience depends on a service that remains present after a command finishes. This chapter follows the ownership boundary between the ACN daemon, its private ICN inference process, the SDK connection, and the model's own residency state. The goal is practical: when Magnitude says a service is ready, a model is loading, or a client is recovering, the reader should know what that state means and which transition can still fail.

Readiness is a boundary, not a background adjective

A command-line tool can hide a great deal of process management. It can start a server, wait for a health response, find a model, and return control to the user. That convenience becomes unreliable if every client implements the sequence independently. One client may launch a second native server, another may keep a stale model list, and a third may mistake an open port for a compatible service. Magnitude addresses this by making ACN—the local daemon—the shared application owner and keeping ICN—the native inference component—behind it.

ACN hosts product state, sessions, provider projections, model operations, and client-facing RPC. ICN owns the native inference concerns: hardware, artifacts, fit, runtime model state, and generation. The two processes have different responsibilities, but they are not competing services. ACN starts and supervises the private ICN process, exposes the public local boundary only when the application is ready, and closes that boundary during shutdown. Clients therefore have one place to ask for model state and one inference path to use.

The service lifecycle has an operational meaning. Starting means the daemon is resolving its runtime and building the application; it is not yet an invitation for ordinary operations. Ready means application admission is open: the RPC layer and the inference gateway can accept work. Stopping closes admission and begins orderly cleanup. Exact exit is the point at which the owned process and its inference runtime are actually gone. A timeout or a lost connection does not by itself prove exact exit. That distinction prevents a replacement process from being started while the predecessor still owns native resources or the fixed service boundary.