Summary
A set of UX improvements to reduce time-to-first-request and give administrators fine-grained control over virtual key permissions. These changes bring the AI Gateway's onboarding experience to the same level as Policy Radar's contextual setup flow.
1. Getting started cards on dashboard
The AI Gateway dashboard already detects first-time users (no API keys or endpoints configured) but the current onboarding is minimal. Add contextual InfoBox banners that guide users through setup step by step: add an API key → create your first endpoint → test in the playground → enable guardrails. Each banner appears only when the previous step is complete, and dismisses automatically once the current step is done — the same pattern used on the Policy Radar dashboard.
2. Auto-generate virtual key on first endpoint creation
Creating an endpoint and then separately creating a virtual key is unnecessary friction for new users. When a user creates their first endpoint, auto-generate a virtual key with sensible defaults (no budget limit, no expiration, linked to that endpoint) and display it once in a confirmation modal with a copy button. This reduces time-to-first-request from 5 clicks to 2.
3. "Try in playground" from model catalog
The model catalog and playground are currently disconnected — users browse models in one page and test them in another. Add a "Try in playground" button on each model card that navigates to the playground with that model pre-selected. If no endpoint exists for that model yet, offer to create one inline.
4. Integration code snippets on virtual key detail
After creating a virtual key, users need to figure out how to integrate it. Show copy-paste code snippets (curl, Python, Node.js) with the user's actual virtual key and gateway URL pre-filled. Display these in the key creation confirmation modal and make them accessible from the virtual keys list via an "Integration" action.
5. Dashboard quick actions row
Add a compact row of action buttons below the dashboard stat cards for the 4 most common tasks: "Create endpoint", "Add guardrail", "View logs", and "Open playground". Uses CustomizableButton with variant="outlined" and Lucide icons — same pattern as the Policy Radar dashboard quick actions.
6. Per-virtual-key model and provider access controls
Virtual keys currently support budgets, rate limits, expiration, and endpoint whitelists, but no model or provider-level restrictions. Add four optional fields to virtual keys: allowed_models, blocked_models, allowed_providers, blocked_providers. The proxy enforces these before forwarding — if the requested model or its provider is blocked, return 403 with a clear error message. This enables scenarios like restricting a team to cost-effective models only, blocking providers with data residency concerns, or limiting interns to small models.
Summary
A set of UX improvements to reduce time-to-first-request and give administrators fine-grained control over virtual key permissions. These changes bring the AI Gateway's onboarding experience to the same level as Policy Radar's contextual setup flow.
1. Getting started cards on dashboard
The AI Gateway dashboard already detects first-time users (no API keys or endpoints configured) but the current onboarding is minimal. Add contextual InfoBox banners that guide users through setup step by step: add an API key → create your first endpoint → test in the playground → enable guardrails. Each banner appears only when the previous step is complete, and dismisses automatically once the current step is done — the same pattern used on the Policy Radar dashboard.
2. Auto-generate virtual key on first endpoint creation
Creating an endpoint and then separately creating a virtual key is unnecessary friction for new users. When a user creates their first endpoint, auto-generate a virtual key with sensible defaults (no budget limit, no expiration, linked to that endpoint) and display it once in a confirmation modal with a copy button. This reduces time-to-first-request from 5 clicks to 2.
3. "Try in playground" from model catalog
The model catalog and playground are currently disconnected — users browse models in one page and test them in another. Add a "Try in playground" button on each model card that navigates to the playground with that model pre-selected. If no endpoint exists for that model yet, offer to create one inline.
4. Integration code snippets on virtual key detail
After creating a virtual key, users need to figure out how to integrate it. Show copy-paste code snippets (curl, Python, Node.js) with the user's actual virtual key and gateway URL pre-filled. Display these in the key creation confirmation modal and make them accessible from the virtual keys list via an "Integration" action.
5. Dashboard quick actions row
Add a compact row of action buttons below the dashboard stat cards for the 4 most common tasks: "Create endpoint", "Add guardrail", "View logs", and "Open playground". Uses
CustomizableButtonwithvariant="outlined"and Lucide icons — same pattern as the Policy Radar dashboard quick actions.6. Per-virtual-key model and provider access controls
Virtual keys currently support budgets, rate limits, expiration, and endpoint whitelists, but no model or provider-level restrictions. Add four optional fields to virtual keys:
allowed_models,blocked_models,allowed_providers,blocked_providers. The proxy enforces these before forwarding — if the requested model or its provider is blocked, return 403 with a clear error message. This enables scenarios like restricting a team to cost-effective models only, blocking providers with data residency concerns, or limiting interns to small models.