Share AI access,
not your API keys .
The Klunq widget gives any page a natural-language agent. The Klunq Proxy makes that agent safely distributable — with virtual keys, hard budget caps and page-locked access.
Klunq widget
Calls /v1/chat/completions with a v-key locked to your page.
data-base-url="proxy…/v1"
LiteLLM-based gateway
- Draw from global pool at model price
- Enforce page lock
- Enforce per-key + global caps
scope: page-only
Tested open models
Only page-locked completions reach the provider. Off-page prompts are blocked with content_filter.
spend counted per model
The problem
API keys don’t belong in the browser
Storing a provider key in a data-api-key makes it visible to anyone. The usual fix is to extend your own backend with proxy logic — so users talk to your server, which talks to the LLM — or to restrict AI to backend-only jobs. Either way, you build and maintain a full gateway before you ship a single agent.
The Klunq widget takes the opposite path: make the page itself agentic with zero backend. The missing piece is safe key distribution.
The solution
A proxy that only speaks your page
Klunq Proxy sits between the widget and the LLM and is built on LiteLLM. You never share a real provider key — you hand out virtual keys (v-keys) that are capped and locked to your page, backed by a small set of tested open models.
- Controllable spend — fund a global team budget once; every request draws from that shared pool at real model pricing. Then set a cap per v-key you define — both caps apply. If a key leaks, it can’t spend more than you allowed.
- Can’t be repurposed — every request is intercepted, so a v-key only works for interactions with your page. Using it for coding, math or generic chat elsewhere is rejected.
- Drop-in for the widget — swap
data-base-urlto the proxy anddata-api-keyto a v-key. Nothing else changes.
Why Klunq Proxy
Disposable keys. Enforced limits.
Built on LiteLLM. The beta already proves the full budget and page-lock flow — without you having to build the backend.
Virtual keys, not real keys
Never ship your provider key to the browser. Issue v-keys (sk-…) scoped to a team — revocable and rotatable in seconds.
Global pool + per-key caps
Fund a global team budget once — every request draws from that pool at real model pricing. Then set a cap per v-key you define. Both caps apply, so spend stays predictable.
Page-locked, not repurposable
Every LLM request is intercepted. A v-key only works in the context of your page — it can’t be repurposed for coding, math or other off-page tasks, even if leaked.
One team, one management key
Create a team and get a single management key. It can generate, list and revoke v-keys for that team. V-keys are inference-only via an OpenAI-compatible API.
Tested open models
Pick from a small set of tested open models suited for page agents — lightweight, fast and cost-predictable. No need to evaluate the whole market.
OpenAI-compatible, LiteLLM-based
The proxy is built on LiteLLM and speaks the OpenAI API. Point the Klunq widget at it and it just works — no backend code to maintain.
How it works
Three steps to safe distribution
Fund a team, mint capped keys, embed them. The same OpenAI-compatible API — now with guardrails.
Create your team
Create a team and receive a management key. Fund a global budget — the shared pool every request draws from at real model pricing.
Issue v-keys with caps
Use the management key to generate virtual keys, each with its own budget cap that you define. Both the global and per-key caps apply.
Embed, locked to page
Point the Klunq widget at the proxy (data-base-url) and a v-key (data-api-key). The key only works for interactions with that page.
Team
You fund a global budget. Every request draws from that shared pool at real model pricing — global cap enforced.
Management key
Single key for that team. Can generate, list and revoke v-keys (OpenAI-compatible management API).
Virtual key
Inference only: /v1/chat/completions, /v1/models. Per-key cap + global cap both apply.
Drop-in embed
Same widget. Safer key.
Replace your provider base URL with the proxy and your raw key with a v-key. The widget does not notice the difference — the proxy does the rest.
<script
src="https://cdn.jsdelivr.net/npm/@klunqlabs/klunq-widget@latest/dist/klunq-widget.js"
data-model="gemma4"
data-api-key="sk-vkey-•••• (virtual key, budget you set)"
data-base-url="https://proxy.klunqlabs.com/v1"
data-scope="broad"
></script>data-base-url
Your proxy, not the provider. OpenAI-compatible and LiteLLM-based, with a small set of tested open models.
data-api-key
A v-key for that team — with a budget you set, revocable. Never a real provider secret.
page lock
Keys only work on your page — intercepted requests can’t be repurposed for other tasks.
data-base-url at the proxy. See how people really use your page.
The widget + proxy already emit rich telemetry. Observatory will turn every user ↔ AI conversation into product insight — what people ask, where they get stuck, what they buy and what they don’t — summarized by AI for you.
No dashboards to stare at — Observatory uses AI to summarize how users interact with your page, surfacings patterns, friction and buying signals across all conversations.
Top questions today
“Do you ship to EU?” — 38× · “Compare plan A vs B” — 21× · “Where is my invoice?” — 14×
Where users struggle
12 users abandoned checkout after the shipping widget failed to open — agent clicks logged but button was disabled.
What sold (and didn’t)
Widget-assisted sessions converted 2.3× higher. Most common no-buy reason: “missing size guide on PDP”.
Powered by proxy + widget telemetry
Put the widget on the open web.
The widget makes pages agentic. The proxy makes that agentic web safe to scale. Start with the widget — add the proxy when you are ready to distribute.
Beta note
Open foundation, production trajectory
The proxy beta is intentionally focused — a LiteLLM-based gateway with per-key budgets that you define, page-locked keys that are useless outside your page, and a small set of tested open models behind an OpenAI-compatible API. You don’t run or maintain the gateway — you just create a team and issue v-keys.
The same gateway will evolve to front a curated OpenRouter model list via LiteLLM routing — with real model pricing and deeper Observatory insights on top. No widget changes required.