Your dashboard says a model is running. Is it really?

Published Oct 17, 2026

1. SEPARATE Role / benchmark / endpoint Saved descriptions and past test models answer different questions from current metadata.
2. READ Bounded metadata GETs Configured private /v1/models and optional /props only; no prompts, discovery or model changes.
3. IDENTITY GATE One supported model report Generic catalogs and multiple IDs are not a selected loaded model; mismatched properties invalidate the read.
4. TIME GATE Row + snapshot must be fresh Failed reads or invalid, beyond-tolerance future or over-ten-minute times cannot headline a retained identity as current.
5. REPORT Artifact / quant / slot context Keep exact reported details; absent metadata stays unknown, not zero or training context.
6. LIMIT Identity is not health No inference about throughput, successful requests, fleet totals or all-host installation.

A computer’s role can say “local AI” long after the model serving on it has changed. A benchmark can keep showing the model that was tested last week. The dashboard can look perfectly consistent while answering the wrong question.

I want to know what the configured endpoint reported, when it reported it, and what that observation does not prove. That is the distinction behind the October 16 macfleet-dash v0.9.4 release.

This is the next layer after my AI setup: the dashboard observes parts of the system. It does not choose the engine for every task, and it should not pretend an old description is live detection.

Four readings I don’t want merged

The new readout has its own Model checked time. Refreshing the page is not the same as obtaining a new endpoint observation. Neither is seeing a recent overall snapshot enough if the model row itself is old.

What v0.9.4 actually reads

The public release adds a separate Current model readout to cards and computer details. I checked the implementation and tests at 3f239e2, not just the release title.

The optional snapshot helper reads explicitly configured private llama.cpp endpoints. It uses a bounded GET /v1/models and, where available, GET /props. It does not send a prompt to see whether the model sounds right.

The boundary is deliberately small:

• The configured metadata URL must use a private IP, the expected path and an explicit port. When the registered computer’s address is supplied, the URL must match it. This is not a network scan.
• Credentials in the URL, query strings and fragments are rejected. Redirects are not followed; machine proxy settings are not forwarded.
• Each metadata read has a two-second timeout and a response-size cap. The configured endpoint set is bounded too.
• A single llama.cpp-owned model row can establish a reported identity. A generic catalog cannot establish which model is loaded.
• If properties arrive, their model alias must agree with the identity read. A model change between the two reads makes the result unavailable rather than mixing the old identity with new details.
• Only the artifact filename survives projection. The full private model path and endpoint URL are not reader-facing output.

There is no model load, restart, completion request, discovery, security-access change or new background service in this feature. The viewer reads local snapshots; the optional helper is where the metadata requests happen. Standalone operators must connect it to their own existing refresh arrangement before claiming automatic checks. One manual run does not establish that arrangement.

An exact identity needs more than the friendly model name

A useful report keeps the identifier and its serving details together:

• Endpoint model ID: the alias reported by this server, not necessarily a globally unique weights identity.
• Artifact: the exact filename, when reported. Keep the quantization suffix; don’t shorten away the useful part.
• Quantization: what the endpoint actually reports, not a guess from the family name.
• Context per slot: the active serving context, not the model’s training context or a sum across slots.
• Serving engine and observation time: enough to understand the source contract and how old the report is.

That slot distinction is easy to miss. The collector test deliberately supplies different values for training context, metadata context and the active properties setting. It asserts the active setting, rather than quietly displaying the largest number. Missing optional details remain unknown.

Here is a dated example from my retained private snapshot—not a screenshot, not a test fixture, and not a claim about what is running now:

This observation is from a Mac-hosted endpoint. It is not the GLM route across the two NVIDIA DGX Sparks. The current-model helper’s llama.cpp contract should not be stretched into a claim that it verifies every engine in my setup.

The private snapshot is evidence of that endpoint’s reported metadata at that time. It is not a weights checksum, a completed task, a performance test or a per-host deployment inventory. The filename and quantization are reported values, not independently inspected weights.

“Unverified” is a useful answer

The implementation refuses several attractive shortcuts:

A failed optional /props read is a narrower case: a valid llama.cpp model response can still identify the reported model, while the artifact and other absent details stay unknown. That is different from a failed identity read. I don’t want to discard a valid observation, but I also don’t want to invent its missing fields.

When a previously available identity becomes stale or the latest snapshot read fails, the details can retain it as Last reported model. It must not remain the headline Current model. Historical evidence is useful precisely because it is labeled historical.

Metadata doesn’t heal the computer

The source joins model metadata onto already registered computer rows. It does not add new computers or change resource values, health status or fleet totals. The viewer tests explicitly check those boundaries.

That matters in a mixed fleet. A current-model row cannot turn a pending Windows computer into monitored coverage, any more than a saved role could. The Windows monitoring story explains those enrollment and natural-operation distinctions.

Likewise, “the endpoint reported model X” does not establish throughput, token usage or successful requests. A healthy-looking model name should not silence a separate computer-health warning. If I need to prove generation works, that is a different, authorized check with a different result—not something this metadata feature secretly does.

What is released, and what isn’t proven

The v0.9.4 changelog, public release, pinned collector and viewer source, and their tests support this feature description. The release reports its own local and exported-source verification. I reviewed that evidence; I did not rerun those release suites as part of writing this article.

The viewer release leaves the health collector/probe at v0.6.0. Its existence does not establish v0.9.4 installed on every host, a new service running, or fresh observations from every model server. My dated private snapshot is a bounded example, not a fleet-wide rollout receipt.

I used a decision diagram rather than publishing a dashboard image containing private inventory. It explains the checks; it is not a rendered monitoring result.

The checklist I now use

Before I repeat a dashboard’s model claim, I ask:

1. Is this a saved description, an old benchmark, or a fresh endpoint observation?
2. Do I have one supported identity—or only a catalog, multiple choices or a failed read?
3. What exact artifact, quantization and active per-slot context were actually reported? Which fields are unknown?
4. Are both the model-check time and containing snapshot fresh and plausible?
5. Am I about to turn metadata into a claim about health, successful work or installed coverage?

That last question is the important one. A dashboard earns trust by keeping different claims separate, not by finding another way to display green.

Public references and private evidence

• v0.9.4 release and verification scope
• README and operator setup at 3f239e2
• Bounded metadata collector and collector tests
• Current-model viewer and viewer tests

Those public links let readers inspect the behavior. The dated endpoint snapshot is retained privately; the public repository intentionally does not ship my inventory or live model settings. Neither the repository nor this article provides access to those endpoints.