SUITE-API

IThe problem

AI developers work inside a fragmented model ecosystem. Providers differ, models get replaced, prices and capabilities move, and each one has its own key setup and its own configuration dialect. Alongside that sits an awkward question that most tooling answers only implicitly: where is my credential actually stored, and how exactly is it used?

The friction is rarely one broken step. It is the accumulation — searching a registry by hand, comparing tabs that present the same information in four different shapes, and re-entering the same connection details into tool after tool.

SUITE-API treats that as a single workflow rather than a row of vendor surfaces: discover, compare, connect, use.

Deployment boundary: SUITE-API is built as a desktop application. The public URLs are an intentionally limited static showcase and read-only Studio preview of it: the hosted control plane is not deployed there, and private credential operations are disabled in the public build by design.

IIWhat it does

• Model Finder — Searches and sorts a registry of AI models, and surfaces the information actually relevant to a decision.
• PULSE — Organises model information around speed, value, coding and reasoning, on a dashboard designed to make comparison easier.
• Fast Connect — Guides provider connection and configuration as a workflow, instead of documentation to read and re-read.
• Safe Vault — A local-first credential-handling design built around authenticated encryption and explicit control over sensitive key material.
• Developer launchers — Prepares model and connection configuration for tools such as Cursor and Claude Code, and other supported agent workflows.
• Vibe Mode / Dev Mode — Presents the same system for creative builders and for developers, at different depths.
• Pre-flight diagnostics — Checks supported provider connections before configuration proceeds, rather than after it fails.

IIIHow it is built

The desktop architecture is a Next.js and TypeScript control plane supported by Prisma on SQLite, wrapped in an Electron shell with background services behind it. Local-first is the structural choice: the application owns its persistence instead of depending on a hosted service being reachable, because a credential manager that stops working when a network call fails is not a credential manager.

Safe Vault is the security boundary that mattered most. Credential storage was designed around authenticated encryption and local control of key material, with the sensitive operations deliberately confined to the local application. That boundary is what allows a public deployment to exist without exposing the private capability — the public build disables it.

Two interface modes sit over one architecture. Vibe Mode and Dev Mode change presentation, not the underlying system, so the approachable surface cannot quietly drift away from the technical one.

IVThe evidence

A deployment-verification record dated 7 October 2026 documented successful production builds, typechecking and linting, and a 54 / 54 quality-test result. The same record compared 26 served files against their local SHA-256 hashes, so what is served was checked file by file against the local build. The deployed interface’s key interactions were verified directly.

The public deployment is an intentionally limited static showcase with a read-only Studio preview. The built desktop application is not hosted there, and private credential operations are disabled in that build by design.

VMy role

I had the product concept, the architecture, the feature design and the model-discovery workflows. I designed the credential-handling model — Safe Vault — around a clear security boundary, which is the difference between a control plane and a collection of API clients.

I set the implementation direction and verified the application and its deployed presentation, including the file-level hash comparison. As with the other cases, implementation was carried out by coding agents against specifications and review I directed.