Building a prompt workbench that keeps working when the API does not

Every tool that calls a hosted model has two behaviours: the one you demo and the one your user gets when the API is down. Prompt-Studio was an exercise in making those two as close as I could.

The problem it solves

Turning a rough idea into a specification an AI coding assistant can actually execute is repetitive work: state the objective, break it into phases, define runtime expectations, list acceptance criteria, say what done means. Doing that by hand every time is exactly the kind of task that should be a tool.

Three profiles shape the output differently. A project brief, a coding agent instruction, and a product specification are not the same document, and pretending one template fits all three produces something that fits none.

Designing the failure path first

The interesting decision was building the local optimiser before relying on the remote one. When the NVIDIA NIM call fails, times out, or hits a rate limit, the tool does not show an error and stop. It runs a deterministic local transformation and tells the user which path produced the result.

That constraint changed the architecture. The remote model became an enhancement to a pipeline that already worked, rather than the pipeline itself. Anything the tool genuinely needed had to be expressible without the API.

Measuring what it claims

The tool reports estimated token savings for its compact mode. That estimate is conservative and character based, and it is labelled as an estimate rather than presented as a measurement, because a number a user cannot verify is worse than no number.

Zero database by design

State lives in browser local storage, the backend is a plain Python HTTP server, and the front end is vanilla JavaScript. Nothing to provision, nothing to migrate, nothing to leak. For a single user tool, a database would have been infrastructure in search of a requirement.

Source: Prompt-Studio