The Art of the Small Request: Why "Hide Killed Instances by Default" Reveals the Soul of Operational UI Design

In the sprawling, high-stakes conversation of an autonomous fleet management system for GPU proving infrastructure, one message stands out for its deceptive simplicity. At message index 4789, the user writes:

Also in 'Instances' hide killed instances by default

Seven words. A single sentence appended as an afterthought to a larger feature request. Yet this tiny message encapsulates a profound understanding of operational software design, exposes the hidden assumptions behind UI defaults, and triggered a chain of implementation decisions that reveal how the best user feedback is often the briefest.

The Context: A System Under Rapid Construction

To understand why this message was written, we must first understand what had just happened in the conversation. The preceding messages paint a picture of intense, rapid-fire development. The assistant had just implemented a "hard policy" monitor that automatically destroys vast.ai instances stuck in exited, error, loading, or scheduling states for more than three hours ([msg 4754]). This was a direct response to a production problem: the fleet was accumulating dead instances that continued accruing storage charges on vast.ai, silently bleeding money. The policy worked — within minutes, four exited instances and two instances stuck in loading for over a thousand hours were destroyed ([msg 4773]).

Immediately after this cleanup, the user shifted focus to the user interface. At message 4786, they reported two pain points: "Inputs in the UI reset on UI refresh, very annoying" and requested "a way to directly send a message to the agent, as well as 'trigger observe cycle now' button." The assistant acknowledged these requests ([msg 4787]) and began investigating the root cause of the input reset problem, identifying that renderAgent() used el.innerHTML = ... which destroys and recreates all DOM elements including inputs ([msg 4788]).

Then, as an addendum to this already-in-progress UI overhaul, the user added message 4789 — the request to hide killed instances by default.

The Motivation: Why This Request Matters

The user's motivation is rooted in operational reality. After the hard policy ran, the Instances panel would have been populated with a growing list of destroyed instances. Every monitor cycle that found and destroyed a dead instance would add another entry to the list. For an operator checking the dashboard, seeing a panel cluttered with "killed" entries is not just visually distracting — it actively obscures the signal the operator cares about: which instances are currently running, which are benching, and which might need attention.

The phrase "by default" is the critical qualifier. The user is not asking to remove the ability to see killed instances — they are asking for a sensible default. This distinction reveals a sophisticated understanding of UI design: the default view should optimize for the common case (operators want to see active instances), while the power user path (debugging, auditing killed instances) should remain accessible through an explicit action. The user is implicitly requesting a filter toggle, not a data deletion.

This request also reflects a shift in the system's lifecycle. Earlier in the conversation, the team was fighting fires — crashes, OOM errors, SSH connectivity failures, and agent hallucinations. Now, with the hard policy running and the agent stabilizing, the user's attention has turned to polish and operator experience. The request is a signal that the system is maturing from "make it work" to "make it usable."

Input Knowledge Required

To understand this message, one needs considerable context about the system architecture. The "Instances" panel is a UI component in the vast-manager web dashboard that displays all GPU instances managed by the system. It already had a state filter dropdown (<select id="state-filter">) with options like "All States," "Running," "Bench Done," and "Killed" ([msg 4792]). The panel renders instances from the local database, which tracks each instance through its lifecycle: provisioning, loading, running, benching, and ultimately killed or destroyed.

The reader must also understand that the hard policy ([msg 4754]) was actively destroying instances, meaning the "Killed" state was about to become very populated. Without the default filter, every operator dashboard refresh would show a growing graveyard of dead instances alongside the live ones.

Additionally, the user's request builds on the assistant's ongoing work. The assistant was already modifying renderAgent() and the broader UI rendering pipeline to fix input preservation ([msg 4788]). By appending this request to the same thread, the user signals that they expect it to be implemented as part of the same UI change batch — an assumption about development efficiency that the assistant correctly interprets.

The Assistant's Interpretation and Implementation

The assistant's response reveals how it understood the request. In message 4790, it immediately adds a new todo item: "Hide killed instances by default in Instances panel." Then in message 4791, it begins implementation by examining the existing filter mechanism:

[grep] state-filter|filter.*all|default.*killed
Found 3 matches
/tmp/czk/cmd/vast-manager/ui.html:
  Line 324: <select id="state-filter" onclick="event.stopPropagation()" onchange="renderInstances()">
  Line 541:   const filter = document.getElementById('state-filter').value;
  Line 543:   if (filter !== 'all') instances = instances.filter(i => i.state === filter);

The assistant identifies that the existing filter only had an "All States" default. The implementation decision is elegant: rather than hiding killed instances unconditionally, the assistant adds a new "Active" option to the dropdown that filters out killed instances, and sets it as the default selection (<msg id=4793-4794>). This preserves the user's ability to see all instances (including killed ones) by explicitly selecting "All States," while optimizing the default view for the operational use case.

This decision embodies a key design principle: never destroy information, just change the default lens through which it is viewed. The assistant could have simply filtered killed instances from the data entirely, but that would have broken the audit trail. Instead, it added a filter option that the user can override.

Assumptions and Their Implications

The user's message makes several assumptions. First, it assumes that the Instances panel has a filter mechanism that can be modified — an assumption validated by the existing code. Second, it assumes that "killed" is a well-defined state in the data model, which it is — instances transition to killed state when the monitor destroys them. Third, it assumes that this change is small enough to be bundled with the other UI fixes, which the assistant confirms by implementing it alongside the input preservation and message input features.

The assistant, in turn, makes its own assumptions. It assumes that "hide by default" means "add a filter option with a new default" rather than "remove killed instances from the data entirely." It assumes that the user wants the flexibility to still see killed instances when needed. It assumes that the implementation should be consistent with the existing filter pattern rather than introducing a new hiding mechanism. All of these assumptions are correct, but they are not explicitly stated in the user's message — they are inferences drawn from the system's architecture and the user's previous behavior.

The Deeper Lesson: Small Messages, Large Implications

What makes message 4789 remarkable is not its content but its placement in the conversation. It is the third UI request in a span of a few messages, appended almost as an afterthought. Yet it reveals more about the user's mental model than the longer, more detailed requests. The user is thinking holistically about the operator experience — not just fixing individual annoyances (input reset, missing message input) but shaping the overall information architecture of the dashboard.

The request also demonstrates a pattern common in effective human-AI collaboration: the user provides high-level intent ("hide killed instances by default") and trusts the AI to translate that into concrete implementation decisions (add an "Active" filter option, make it the default, keep "All States" available). The user does not specify how to hide them, only what the desired outcome is. This division of labor — human specifies the goal, AI determines the mechanism — is the hallmark of a mature collaborative relationship.

Conclusion

Message 4789 is a masterclass in concise, effective user feedback. In seven words, it communicates a clear operational need, implies a design approach (default vs. explicit override), and leverages the existing system architecture. The assistant's implementation — adding an "Active" filter option as the new default while preserving access to all states — honors the user's intent while making sensible engineering trade-offs.

The message also marks a transition point in the project's lifecycle. Earlier segments dealt with existential threats: crashes, OOM errors, agent hallucinations destroying instances. Now the conversation has shifted to UX polish: input preservation, message inputs, trigger buttons, and default filters. This is the quiet signal of a system that is stabilizing — when operators start caring about default views and information density, it means the fires are out and the focus has shifted to operational excellence.