The Final Solder Joint: Wiring localStorage Persistence into a GPU-Proving Dashboard

Message Summary

Now add onchange="saveDisk()" to the disk input and oninput to max-cpp for real-time saving: [edit] /tmp/czk/cmd/vast-manager/ui.html Edit applied successfully.

At first glance, this message from the opencode coding session appears almost trivial — a single line of HTML attributes being patched into a web UI file. But this seemingly minor edit is the final solder joint in a carefully planned chain of UI enhancements, the last step that transforms a static dialog into a persistent, user-friendly tool. Understanding why this message exists, and why it was written exactly this way, requires unpacking the context, the reasoning, and the broader system it serves.

The Context: A GPU-Farming Dashboard Under Active Development

The vast-manager system is a management platform for distributed GPU proving operations on the Filecoin network. It orchestrates instances on Vast.ai (a GPU rental marketplace), deploys proving software, benchmarks performance, and automatically destroys underperforming instances. By the time of this message ([msg 1592]), the system had already undergone extensive development: Docker builds, benchmark scripts, a comprehensive web UI dashboard, a database-backed instance lifecycle, and a sophisticated offer-search system that lets operators find cost-effective GPU rentals.

The user's request in [msg 1583] was twofold: first, persist the "min price per proof" setting (the maximum cost per proof the operator is willing to accept) across page reloads using localStorage; second, add multi-select checkboxes to the offers table so operators can bulk-deploy or bulk-ignore multiple machines at once. These are pure UX quality-of-life improvements — they don't change the backend logic, but they dramatically improve the operator's workflow when deploying dozens of GPU instances.

The Planning Phase: A Systematic Approach

The assistant's response to the user's request reveals a methodical planning process. In [msg 1585], it enumerated a todo list with four items:

Persist max $/proof value in localStorage and restore on page load
Add checkbox column to offers table for multi-select
Add bulk action toolbar (Deploy Selected, Ignore Selected)
Implement bulk deploy and bulk ignore This structured approach is characteristic of the assistant's working style throughout the session. Rather than making scattered edits, it first reads the existing code ([msg 1584]), formulates a plan, and then executes each step in dependency order. The localStorage persistence came first because it was the simplest change and could be verified independently. The checkbox and bulk actions came next because they required structural changes to the table rendering.

The Execution: Building the Persistence Layer

The assistant implemented localStorage persistence across four consecutive edits ([msg 1586] through [msg 1591]), each building on the previous one:

[msg 1586]: Added the initial localStorage save/load scaffolding — likely defining saveDisk() and saveMaxCPP() functions, and loading saved values on page initialization.
[msg 1590]: Updated openDeployDialog to read saved values from localStorage and populate the form fields, and set default values in the HTML inputs.
[msg 1591]: Updated recalcMinRate (the function that calculates the minimum acceptable proofs-per-hour rate from the price-per-proof and the GPU's dollar-per-hour cost) to also save the max-cpp value to localStorage. Added disk saving on change.
[msg 1592] (the subject): The final wiring step — attaching onchange="saveDisk()" and oninput event handlers to the HTML input elements themselves. This sequence reveals a deliberate bottom-up construction: define the save functions first, then load them in the dialog opener, then save from the calculation function, and finally wire the HTML inputs directly. The subject message is the last piece because it connects the user's interaction (typing in a field or changing a dropdown) to the persistence logic that was already built.

Why `onchange` vs `oninput`? A Deliberate UX Choice

The subject message distinguishes between two event handlers: onchange="saveDisk()" for the disk input, and oninput for the max-cpp field. This is not an arbitrary choice — it reflects a thoughtful understanding of how users interact with these fields.

The onchange event fires only when the user commits a change — typically when they tab away from the field or click elsewhere (the "blur" event). For the disk input, which represents a storage allocation in gigabytes, the user is likely to type a value and then move on. Saving on change (blur) is appropriate because it avoids writing to localStorage on every keystroke for a value that doesn't need real-time feedback.

The oninput event, by contrast, fires on every keystroke or value change. For the max-cpp (maximum cost per proof) field, real-time saving makes sense because this value is used immediately by the recalcMinRate function to compute the minimum acceptable proofs-per-hour rate. The deploy dialog shows this calculated rate to the user, so saving on every input ensures the displayed rate stays consistent even if the user navigates away and back. It's a subtle but meaningful UX refinement.

Assumptions and Knowledge Boundaries

This message makes several implicit assumptions. First, it assumes that saveDisk() and the max-cpp save function already exist in the JavaScript scope — which they do, having been defined in [msg 1590] and [msg 1591]. Second, it assumes that the HTML input elements have the correct id attributes (disk and max-cpp or similar) that these functions reference. Third, it assumes localStorage is available in the browser environment — a reasonable assumption for modern browsers, but one that would fail in older or restricted environments.

The assistant also assumes that the user wants real-time persistence rather than persistence only on form submission. This is a design choice that prioritizes resilience: if the user accidentally closes the tab, their settings are preserved even if they never clicked "deploy." The trade-off is slightly more frequent localStorage writes, but since localStorage operations are synchronous and cheap, this is negligible.

Input and Output Knowledge

To understand this message, a reader needs to know: what localStorage is and how it works in web browsers; the difference between onchange and oninput DOM events; the structure of the vast-manager UI (particularly the deploy dialog with its disk and max-cpp fields); and the fact that saveDisk() and the max-cpp save function were defined in preceding edits.

The output knowledge created by this message is a fully persistent deploy dialog. Before this edit, the user's max price per proof and disk size preferences would reset to defaults on every page reload. After this edit, those values survive browser refreshes, tab closures, and even full system reboots (as long as the browser doesn't clear its localStorage). This is a significant UX improvement for an operator who deploys instances repeatedly — they no longer need to re-enter their preferred cost threshold every time.

The Thinking Process: What the Message Reveals

The subject message is terse — it doesn't explain why onchange is used for disk and oninput for max-cpp. But the reasoning is visible in the sequence of edits that precede it. In [msg 1591], the assistant updated recalcMinRate to save the max-cpp value. This function is called whenever the max-cpp or dph value changes, so saving from within that function covers the case where the value changes programmatically (e.g., through the recalculation logic). But it doesn't cover the case where the user types directly into the max-cpp input field without triggering a recalculation. The oninput handler in the subject message closes this gap, ensuring that any change to the input — whether typed, pasted, or adjusted via spinner buttons — is persisted immediately.

The choice of onchange for the disk input, meanwhile, reflects a judgment that disk size is a "set and forget" value. Users typically choose a disk size (250 GB, 500 GB, etc.) and don't tweak it repeatedly. Saving on blur is sufficient and avoids unnecessary writes.

The Broader Significance

This message, for all its brevity, represents the difference between a functional UI and a polished one. The localStorage persistence, the multi-select checkboxes, and the bulk action toolbar that were all added in this sequence ([msg 1586]–[msg 1592]) transform the vast-manager dashboard from a tool that works into a tool that works well. The operator can now search for GPU offers, check the ones they want, click "Deploy Selected," and have their pricing preferences remembered across sessions. Each of these features reduces friction in the deployment workflow, which matters when you're managing dozens of GPU instances across multiple continents.

In the broader arc of the session, this UI polish phase sits between two very different kinds of work: operational monitoring (checking instance states, cleaning the database, watching benchmark results) and deep protocol-level debugging (investigating a PoRep PSProve CuZK failure that would dominate the subsequent conversation). The subject message is a moment of craftsmanship in a session that would soon pivot to cross-language serialization bugs and Rust deserialization edge cases. It's a reminder that even in a system dealing with zero-knowledge proofs, GPU proving, and distributed instance orchestration, the humble HTML input event handler still deserves careful thought.