local-proxy-shared-key · EN · 2026-10-27

Running a Local Proxy in Front of One Aggregator Key So Every Tool on a Machine Shares It

A localhost proxy in front of a single aggregator API key centralizes authentication, lets you tag requests per tool, and applies simple rate shaping so every editor, CLI, and script on a machine shares one credential instead of storing its own copy.

Why a Local Proxy?

Most workstations end up with the same API key pasted into several places: an editor extension, a command-line tool, a handful of scripts. Each copy is a maintenance and security liability, and none of them give you a single view of usage. A small proxy bound to 127.0.0.1 lets you keep one real key in one place while every other tool points at the local endpoint.

Keep the Real Key Off the Tools

  • Store the aggregator key in the proxy's environment or a local secret file.
  • Configure each tool with a placeholder token and a base URL pointing at the proxy.
  • The proxy replaces the placeholder with the real key before forwarding.

If a script or editor config leaks, the exposed value is a local-only placeholder with no value outside the machine.

Tag Requests Per Tool

Because all traffic passes through one point, you can attach metadata that would otherwise be lost:

  • Map each incoming path or port to a tool name (e.g., /editor, /cli, /batch).
  • Add a request header or query field identifying the tool and, optionally, the project.
  • Log the tag alongside the model and token counts so you can attribute usage later.

This makes it practical to answer questions like which tool drives most of the spend, or whether a background script is still calling a model after hours.

Basic Rate Shaping

A proxy is a natural place for simple, local guardrails:

  • Per-tool request-per-minute ceilings.
  • Concurrency caps so a runaway script cannot saturate your key.
  • Short queues or fast rejections when limits are exceeded.

Keep shaping conservative and observable. The goal is to stop accidental bursts, not to replace the aggregator's own limits.

Minimal Implementation Sketch

A few dozen lines in any HTTP framework are enough:

  • Listen on localhost only.
  • Match the incoming path to a tool profile.
  • Rewrite the authorization header.
  • Apply the profile's rate limits.
  • Forward to the aggregator's base URL and stream the response back.
  • Emit one structured log line per request.

Run it under a process supervisor so it restarts with the machine.

Point Tools at the Proxy

  • Editors: set the API base URL to http://127.0.0.1:<port> and use the placeholder token.
  • CLIs: many read a base-URL environment variable; set it once in your shell profile.
  • Scripts: pass the local base URL and placeholder explicitly so they never read the real key.

Document the setup in one short note so new tools follow the same pattern.

Operational Notes

  • Bind to loopback only; do not expose the proxy on a network interface.
  • Treat proxy logs as sensitive if they contain prompts or completions.
  • Keep the tool-to-path mapping in a small config file you can revise without touching each tool.
  • When you rotate the aggregator key, update it in one place.

How This Fits the Aggregator Model

You still fund one account with USDC on Base without KYC and use one key across models such as Claude, GPT, DeepSeek, Qwen, GLM, and Kimi. You pay the official price × 1.3, and key contributors are credited official price × 1.1 (premium × 1.2) in USDC. The proxy does not change pricing; it changes how cleanly you hold and observe the key on a single machine.