OpenAI-Compatible Is Only the Beginning

Magnitude can make local inference reachable through a familiar completion interface, but reachability is not the same as a native agent experience. This chapter examines the three integration surfaces around Magnitude—machine control, inference observation, and user-interface projection—then connects them to validation and privacy. The reader will be able to judge what “supported” means for a particular harness instead of treating one compatible endpoint as proof that every control, progress signal, and status display will work.

Compatibility has three surfaces

An OpenAI-compatible endpoint is a valuable common language. It lets a client send a model identifier, messages, tools, and streaming options through a protocol that many agent harnesses already understand. Magnitude's local service also exposes gateways for more than one request style, so an agent can reach local inference without learning the native details of ICN's model engine. But a protocol describes how a request and its semantic answer cross a boundary. It does not decide who starts the service, who loads the model, who observes loading progress, or where a harness can display that progress.

The repository's integration analysis separates three capabilities.

Machine control means that an integration can invoke Magnitude operations such as checking model status, loading a model, or stopping it, and can present the result as a real state rather than scraping human-oriented text. This is the most basic surface. It answers whether the model can be selected or stopped, but it does not necessarily tell the user what the native engine is doing inside a long request.

Inference observation means that an integration can see Magnitude-specific events while the completion is streaming. The local protocol can opt into progress events for model loading, queueing, preparation, prefill, and generation. A harness needs access to the raw response stream early enough to observe those events before its ordinary OpenAI parser discards unknown or choice-less chunks. That is a transport problem, not a model-selection problem.

Native UI projection means that the integration has a supported place to render the observed state: a footer, prompt status row, status bar, or another surface that belongs to the harness. Without that surface, a plugin may know that a model is loading but still have no honest way to show the information without injecting a fake conversation message, misusing a toast, or encoding telemetry into text. Control, telemetry, and presentation are related, but they are not interchangeable.

flowchart TD A[Agent harness] --> B[Machine control] B --> C[Local service and model state] A --> D[OpenAI-compatible semantic request] D --> E[Messages tools usage and terminal result] D --> F[Optional Magnitude progress stream] F --> G[Integration observer] G --> H[Harness-native status surface] C --> I[Primitive correctness evidence] C --> J[Composite endpoint measurements] B --> K[Plugin installation and lifecycle] K --> L[User-authority and ownership boundary]

This model explains why two integrations can both “connect to Magnitude” while providing different experiences. One may let the user choose and load a model but show no live prefill state. Another may observe loading and generation progress but require a restart before the harness can use the new provider. A third may have a status slot but no supported bridge from the server process that receives the raw stream to the UI process that renders it.

Pi is the clearest positive case in the repository's review. Its extension and provider APIs can execute Magnitude commands, register slash commands, project status into the built-in footer, and override the provider stream with a custom fetch path.