Local CLI and proxy
SymVeil runs on your machine. It learns the identifiers that would give a firmware program away — internal functions, types, macros, registers, chip code names, hostnames, and IPs — and secrets. Prompts to Claude Code, Codex, and Cursor CLI leave with those strings replaced. Replies come back with your names restored.
Opt-in base URL. C, C++, and device tree only for now. Cursor editor chats and web chats are outside the proxy.
Example rewrite
Same question. The function, the register, and the lab address are swapped for stable tokens before the provider sees them.
Why does aurora_rcc_enable_pll spin on AURORA_RCC_CTRL_REG at 10.8.0.14?
Why does @@sv:d37237d7@@ spin on @@sv:de828083@@ at @@sv:18d75a83@@?
Function
aurora_rcc_enable_pll
becomes
@@sv:d37237d7@@
Register
AURORA_RCC_CTRL_REG
becomes
@@sv:de828083@@
IP address
10.8.0.14
becomes
@@sv:18d75a83@@
Three steps
Point SymVeil at the tree. It collects internal function, type, and macro names, register names, chip code names, internal hostnames, and IP addresses, and it picks up secrets. The dictionary is built on the machine. It is kept there.
Set the agent's base URL to the local proxy. That choice is the opt-in: clients you leave pointed at the provider talk to the provider directly. On the way out, a learned name such asaurora_rcc_enable_pll becomes a token such as @@sv:d37237d7@@. Code structure, comments, and other prose stay, unless they match a learned identifier or a secret.
Tokens in the response are mapped back to the original identifiers before you read them. You seeaurora_rcc_enable_pll. The provider saw @@sv:d37237d7@@. The map stays on the machine that ran the proxy.
Names, and keys
A secret scanner is the right tool for keys, tokens, and other credentials. The three strings in the example are ordinary identifiers. Under an NDA they can still name the chip, the register map, and the lab network. SymVeil learns that vocabulary from the tree and veils it, and it veils secrets as well.
aurora_rcc_enable_pll
AURORA_RCC_CTRL_REG
10.8.0.14
These three look like normal firmware source. A scanner has no credential to flag.
Learning currently covers C, C++, and device tree. Names that live only in other languages stay in the prompt.
Pricing
There is no checkout here, and this site does not ship the proxy. The waitlist is how you hear when there is a build to run, or when Pro is actually for sale.
Open source
Open source. You run it on your machine.
Planned
The price we expect to charge a solo developer. It can change before anything is sold.
FAQ
The boundaries are part of the product. These are the ones that matter today.
The request your agent was already going to send to its model provider, with learned identifiers and secrets replaced by tokens. SymVeil hosts no model. The dictionary that maps tokens back to names stays on the computer running the proxy.
You point Claude Code, Codex, or Cursor CLI at the local proxy by setting that client's base URL. Coverage starts with that setting. Clients left on the provider's own URL keep sending unveiled prompts.
Cursor CLI, when its base URL is the local proxy. Cursor editor chats and Cursor web chats are outside SymVeil. There is no editor plugin and no web-chat rewrite.
C, C++, and device tree only, for now. Identifiers that exist only in other languages are left as written.
Scanners match credentials. aurora_rcc_enable_pll, AURORA_RCC_CTRL_REG, and10.8.0.14 are names and an address, and they can still identify an NDA program. SymVeil's job is that vocabulary, with secrets included. A scanner remains the right check for files you are about to commit.
A token is a stand-in so the literal identifier is absent from the prompt. It is a redaction of that string. Code structure, comments, and constants that were left in place can still describe the design, and a model can still be less useful when the hidden name carried the meaning. Replies are restored locally, so what you read uses your names.
The email address you submit and the time it was accepted. Locally those two fields are appended to a JSONL file. On Vercel they are written to Upstash Redis. The IP address is not stored with the signup. The page loads no third-party scripts, fonts, or analytics, and it shows no signup count.
Pro is planned around $9 a month and has no billing yet. The core is meant to be open source and local, and this site does not distribute a binary. The price can change before Pro exists.
Waitlist
Leave an email if you want to hear when the local core is available to try, or when the Pro tier — planned around $9 a month — is actually for sale. One address. No confirmation mail from this form. No signup count on this page.
Stored fields are the email address and the time the endpoint accepted it. Locally those lines go todata/waitlist.jsonl. On Vercel the same fields are stored in Upstash Redis. Your IP address is not one of those fields.
The browser posts to /api/waitlist. SetPUBLIC_WAITLIST_ENDPOINT when you build the site to point that at your own endpoint. When the variable is unset, the form posts to /api/waitlist.
On Vercel, /api/waitlist is a serverless function. It writes to Upstash Redis whenUPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN are set, or whenKV_REST_API_URL and KV_REST_API_TOKEN are set. Local dev keeps the JSONL file. The README has the request contract.