The First Filter Is the Machine
Magnitude's recommendation system addresses a specific problem: a model catalog can describe what a configuration is, but only the current machine can determine whether that configuration is practical. This chapter follows the work that happens before a recommendation appears—discovery, hardware assessment, and constrained ranking—so the reader can choose among viable local models without mistaking a friendly name or a single score for a serving decision.
Discovery is not assessment
The first distinction is between finding a model and deciding that it can run. Magnitude treats these as separate operations because they answer different questions.
Discovery asks: what usable model artifacts are already here? Its scan looks through existing local Hugging Face caches for complete GGUF models. The scan is local and read-only. It does not download models or contact Hugging Face merely to find out what is on the computer. This is useful for two reasons. It avoids treating the network as a prerequisite for inventory, and it allows a model someone has already downloaded to enter the same local view as a model Magnitude knows through its curated catalog.
Assessment asks a harder question: given this artifact, this machine, and a serving configuration, can the native runtime use it? Magnitude assesses both curated choices and discovered local models for compatibility, memory fit, context and serving configuration, available acceleration, and expected generation speed. Those results are produced as background preparation, not as an incidental detail of rendering a menu. Until discovery and assessment settle, the visible list is provisional: more models may appear, a candidate may be removed as incompatible, and a recommendation can change as assessment completes.
This distinction prevents a common failure in local-model tools. A file's presence proves that bytes exist. It does not prove that the model's tensors can be placed on the available devices, that its context configuration leaves enough memory for the runtime, or that its generation rate suits the intended agent. A catalog entry proves that a configuration has been reviewed for inclusion. It does not prove that the same configuration fits every computer. Magnitude's preparation stage keeps those facts separate instead of letting the easiest fact—“the file is available”—stand in for the difficult one.
The staged process also changes when the user pays the cost of commitment. Magnitude's onboarding waits until preparation has produced choices, then asks the user to choose before downloading a catalog model. The system can assess the configuration without first fetching the full weights, so the user can reject an unsuitable option before spending bandwidth and storage. This does not mean every assessment is free: it still requires artifact metadata and native planning work. It means the expensive commitment is delayed until there is a reasoned candidate to commit to.
The two candidate sources are useful in different ways. A curated entry gives Magnitude a reviewed identity and quality context before the user has any local copy. A discovered artifact gives the system something concrete to inspect because the user already has it. Both can enter the preparation view, but they do not erase the distinction between a reviewed catalog choice and an arbitrary file found in a cache. In particular, the recommendation path is built around fitting catalog configurations, while discovered or already installed models remain part of the local inventory and runtime picture. That separation lets a user keep using an existing artifact without pretending that every discovered file has the same catalog evidence.
Assessment is also a changing state rather than a single yes-or-no prompt. The CLI can report discovery as complete while assessment is still progressing across the candidate set. A model may therefore be absent from an early recommendation view not because it has been rejected, but because its assessment has not settled. Magnitude's interface is designed to say when a list may grow or recommendations may change. That is a more honest experience than rendering a definitive ranking from whichever few candidates happened to finish first.
For a person preparing an agent, this distinction has an operational consequence. They can ask three separate questions while waiting: has the computer's local inventory been reconciled, has the desired configuration been assessed, and has the chosen model actually been acquired and loaded? The answers point to different actions. A missing candidate may call for waiting or refreshing discovery; a non-fitting candidate calls for a different profile or model; an installing candidate calls for time and storage; a loading candidate calls for available memory and runtime observation. The preparation pipeline is valuable because it makes those remedies legible.
The same state separation continues after the recommendation. A catalog model can be not installed, installing, installed, or updating. A resident model has a different runtime state: unloaded, loading, ready, or failed. The CLI exposes catalog preparation separately from local model status because “assessment complete,” “download complete,” and “the engine is ready” are not interchangeable milestones. A user waiting for the first agent response needs to know which of those operations is taking time.
The diagram's most important edge is the one from assessment to the decision gate. Discovery supplies candidates; assessment supplies a machine-specific serving judgment. The recommendation layer should not be asked to rescue a model that failed the second step. In Magnitude's local provider projection, only assessed, fitting models with a resolved local identity become usable local offerings; incompatible or non-fitting models remain visible as unavailable with a reason rather than being silently ranked.
A recommendation is a constrained negotiation
Once Magnitude knows which configurations fit, ranking becomes useful—but it is still not a contest with one permanent winner. The recommendation view applies a hard memory budget and then weighs softer objectives. That order matters. If a configuration cannot fit the machine, moving a preference toward speed or intelligence cannot make it runnable. If it lacks a capability the task requires, a higher general score does not repair the mismatch.
Memory is the clearest hard constraint. Magnitude's memory figure means the estimated memory needed while the model is running, not the download size. A small file can still have an inconvenient runtime footprint once context state and compute workspace are included. Conversely, a large mixture-of-experts model can execute only a fraction of its routed experts for each token while still needing to store a much larger set of weights. The distinction does not make the larger model automatically practical; it explains why storage, active computation, and runtime memory must be considered separately.
Context is another constrained resource. The displayed context is the amount of conversation and working material available to the selected serving configuration. It is not necessarily the absolute maximum associated with the architecture. Magnitude may choose a smaller context for a compact machine because extending context consumes memory and can slow generation, especially when the model uses attention that continues to examine more of the occupied history. A reader comparing two recommendations should therefore ask not only “which model is larger?” but also “which working context does this configuration make practical?”
After hard constraints come the trade-offs. Magnitude's normal preference views move along a speed-to-intelligence scale: faster, balanced, and smarter. They are different weightings of one catalog, not separate collections of models. fastest and smartest are explicit extremes. The first gives intelligence only limited consideration; the second gives speed only limited consideration. That distinction protects the normal recommendation from being interpreted as an instruction to maximize one dimension regardless of consequences.
The displayed dimensions need careful translation:
- Speed is Magnitude's hardware-aware estimate of generation throughput on this computer. A shorter-to-longer-context range describes how performance may change with context; it is not a confidence interval, and it is not a substitute for a benchmark under the reader's workload.
- Memory is a runtime estimate. It tells the reader whether the configuration is likely to be practical under the assessed plan, not how much storage the download will occupy.
- Context describes the selected serving capacity. A smaller value may be a deliberate resource trade-off rather than evidence that the underlying model has no larger context capability.
- Intelligence is an external composite index spanning several evaluation areas. It is a broad comparison signal, not a percentage of questions answered correctly and not a promise about one coding task.
- Accuracy, in this interface, describes expected fidelity after quantization. It is separate from factual accuracy and helps express what the local artifact may give up relative to its source model.
- Acceleration identifies a reviewed speculative-decoding method when one exists. It affects decode speed, not the target model's intelligence or quality rating.
- Capabilities identify whether the model supports features such as vision, tools, structured output, or reasoning. For a task that needs one of these features, capability is a gate before it is a scoring preference.
These labels are valuable precisely because they stop unlike facts from being merged. A model with a high Intelligence index but no required vision support is not a good vision recommendation. A fast estimate attached to a short context does not imply the same rate at a long context. A high-fidelity quantization may preserve more of the source model while consuming more memory than a lower-fidelity variant. A configuration with a reviewed acceleration method may still see little benefit if the hardware, context, or draft acceptance is unfavorable.
Imagine a reader choosing a model for an agent that spends most of its time editing a codebase. A model with a stronger general intelligence signal may be attractive, but the relevant comparison also includes the context that can remain resident, the memory available after the editor and other applications are open, and whether tool calls and structured output are supported. If the agent's turns are short and frequent, a faster configuration may produce a better working rhythm. If each turn involves difficult reasoning over a large codebase, a reader may rationally accept slower generation for more capability or context. Neither conclusion follows from the model name alone.
Now change the task to image-aware debugging. Vision is no longer a decorative capability label; it is a prerequisite. A candidate that cannot accept the needed input should be removed before speed and intelligence are compared. Change it again to a memory-constrained machine. The hard resource gate becomes decisive, and a lower-fidelity or smaller-context variant may be the only practical way to keep an agent responsive. These examples do not claim that Magnitude can infer the reader's priorities automatically. They show why the interface exposes the dimensions separately: the software can measure or review parts of the decision, while the user supplies the purpose.
There is also a temporal trade-off hidden in the word recommendation. The displayed ranking is a view over the current assessed configurations and current hardware budget. It is not a permanent identity for a model. A different machine can produce a different speed and fit result. A refreshed catalog can add or revise a reviewed configuration. A change in the user's selected preference can reorder the same viable set. An installed model, meanwhile, remains an available local asset even when it is not the current recommendation. This keeps the decision surface responsive without rewriting the user's inventory each time a preference changes.
The ranking code reflects this logic by ranking only fitting catalog models under the machine's physical-memory budget. The preference controls are connection-scoped choices; they do not rewrite the underlying catalog or change the full settings inventory. Installed models remain separately available, so a model the user already has is not erased simply because a current preference would rank another downloadable choice higher. This is a small but important product decision: recommendation helps with selection, while inventory and user ownership remain distinct concerns.
A practical decision can now be stated without pretending that the system has chosen for the user. First ask whether the model can perform the task: check required capabilities. Next ask whether the assessed serving profile fits the machine's memory and context needs. Only then compare expected speed, intelligence, artifact fidelity, and acceleration. If quick iteration dominates, a faster viable model may be more useful than a stronger but slower one. If difficult reasoning or coding dominates, the reader may accept more latency. If the task is long-context work, the selected context and its memory cost may matter more than a small difference in a broad intelligence index.
Magnitude's recommendation is therefore best understood as a constrained negotiation between a machine and a workload. It removes impossible choices, makes the remaining trade-offs visible, and asks the user to supply the priorities that the software cannot infer from hardware alone. The next issue is the foundation of that negotiation: what does Magnitude actually test when it says a configuration fits, and why can a model's name, quantization label, or active-parameter headline never answer that question by itself?