utterpulsar

API YES · local API service hub

One local gateway for every API key.

API YES is a personal desktop control plane for API keys. Upstream provider keys stay on the local machine, and API YES turns them into local API services with the URL, access key, scope, and request format each tool actually needs.

Local API gateway provider key management OpenAI · Responses · Anthropic usage history Windows · macOS · Linux
Demo 01

Create a local API entry, test it, and keep the usage record.

Premise

A local gateway instead of scattered keys.

API keys usually end up spread across tools, scripts, and temporary experiments. API YES starts from a simpler operating model: collect the provider-owned keys in one local desktop app, then let local endpoints represent the exact services that downstream tools should use.

The upstream provider API stays unified inside API YES. The tool using the model does not need to know where the original key came from, which base URL it uses, or which compatible format it expects. It receives a local URL and a local access key; API YES handles the routing, pass-through, limits, and records around that request.

API YES is a personal API gateway: provider APIs go in, customized local API services come out.

Local model

Provider APIs in, customized local services out.

The important idea is not to create another cloud account or enterprise secrets manager. API YES is a local-first control layer for personal development: one place to store owned keys, one place to start the local server, and one place to expose separate API shapes for separate tools.

01

Keys stay local

Provider keys are stored on the desktop and encrypted through the operating system keychain.

02

Local API entries

Each downstream tool can receive its own generated local URL and access key, with loopback or LAN access.

03

Format adapters

OpenAI, OpenAI Responses, and Anthropic-style interfaces can be exposed from the same local control plane.

04

Visible usage

Request history, token tallies, quick tests, and token ceilings make each local service easier to inspect.

Demos

Two cuts of the local API workflow.

The clips focus on the path API YES is built around: create a local service from an owned upstream key, test the service, and inspect the recorded activity afterward.

01

Create and test a local service

Add the upstream key once, generate a local API entry, choose the compatible request format, and run a quick test before using it elsewhere.

02

Review the request record

API YES keeps usage visible at the key level: requests, token totals, cached tokens, reasoning tokens, and ceilings that can stop exhausted local entries with HTTP 429.

Architecture

An Electron desktop app with a local HTTP server.

API YES is built with Electron, Vite, React, TypeScript, Zustand, Tailwind CSS, framer-motion, and Rough.js. The local API server defaults to 127.0.0.1:8788, while application data lives in the operating system app-data area and secrets are encrypted with Electron safeStorage.

The server is designed as a format-faithful pass-through layer: compatible tools can point at a local base URL while provider-specific parameters, access settings, and request accounting stay centralized inside API YES.

Status

A personal gateway for local API control.

API YES is a personal local tool, not an enterprise secrets platform. Its value is practical: fewer scattered keys, clearer local endpoints, quick testing, and usage visibility around the APIs used by everyday tools.

View repository Back to home