Built a desktop AI that never sees or stores the user's Anthropic API key. Here's the architecture + why I refused to build it as a proxy.

Posted by samarth_bhamare@reddit | LocalLLaMA | View on Reddit | 8 comments

Every "AI app" on Product Hunt today is a proxy — they take your API key, route requests through their server, and most of them quietly mark up inference cost 2-10x. I wanted to build the opposite: a desktop coach that talks to Claude directly from the user's machine with zero middleware.

Here's what that actually looks like:

Key storage. First run, the app asks for the Anthropic key and stores it in the OS-native credential store — Windows Credential Manager, macOS Keychain, libsecret on Linux. The key never touches a file on disk, never gets logged, never gets sent anywhere the user didn't explicitly click.

Inference calls. Every Claude API call goes direct from the user's machine to api.anthropic.com. No proxy, no aggregation, no "we'll handle rate limiting for you." If Anthropic is down, the app is down. If Anthropic changes the pricing, the user feels it immediately. Honest trade-off.

Telemetry. Zero analytics on prompts or responses. The only telemetry is an app-open counter (no user ID, no content) so I know if the thing is being used at all. If you run netstat while the app is open, you'll see exactly two outbound hosts: api.anthropic.com for inference and one GitHub release URL for auto-update checks.

Skills architecture. The app ships as a Claude Code skill bundle + a desktop UI wrapper. The skills live in ~/.claude/skills/. Which means even if the desktop app breaks or gets abandoned, the skill files still work standalone inside Claude Code. The user owns the files, not the vendor.

Three reasons I keep getting asked "why not just be a SaaS":

  1. SaaS economics force you to mark up API calls, which means the product has to provide "value" equal to the markup, which means it has to restrict what you can do, which means the user gets less leverage from their own API key.
  2. Key custody is a liability. If I store your key, I'm one breach away from ruining my own reputation. Not storing it is cheaper for everyone.
  3. Local-first means the user owns their workflow forever. The app is infrastructure, not a subscription.

Trade-offs I accept: no cross-device sync, no team features without rebuilding from scratch, no ability to fix a bug for the user without shipping a new binary. For a solo-founder-built tool targeting other solo founders, those are fine trade-offs.

Happy to answer anything technical about the key-handling flow or the skill file structure.