AI provider
Connect your own LLM provider so Spec0's AI features bill to your account, not ours. Why we built it this way and what attribution you get back.
Spec0's AI features — Ask Spec0 chat today, more landing through the year — call a large-language-model provider. You bring the provider key. Calls go directly between Spec0 and your account at Anthropic or OpenAI; Spec0 never proxies the request body, never logs prompts, never logs responses. The compliance footprint is small on purpose.
This page covers what you connect, how to connect it, where the calls actually go, and the philosophy behind that choice.
What you connect
| Provider | Status | Models |
|---|---|---|
| Anthropic | Available | claude-sonnet-4-6, claude-opus-4-7, claude-haiku-4-5 |
| OpenAI | Available | gpt-4o, gpt-4o-mini |
| AWS Bedrock | Enterprise tier | (on request) |
| Azure OpenAI | Enterprise tier | (on request) |
You configure one provider per organisation. Switching providers later is a matter of saving a different key — there's no migration step.
How to connect
- Settings → Organization → AI provider. The page is hidden for orgs that don't yet have the AI features rolled out; if you don't see it, ask your Spec0 contact about enabling it.
- Pick a provider tab. Anthropic is selected by default.
- Paste your API key. It's encrypted with AES-GCM before it touches storage; we keep only the last four characters in cleartext for you to identify it later. Spec0 never echoes the key back in any response or log.
- Pick a chat model. The dropdown is provider-aware.
- Save. Then click Test Connection — Spec0 sends one minimal completion through your key and stores the timestamp + outcome on the row. If the test fails, you'll see the provider's error verbatim.
To rotate the key, paste a new one and save — the old key is overwritten in place. To disconnect, click Remove; AI features will stop working until a new provider is configured.
Where calls go
You ──HTTP──▶ Spec0 ──HTTP──▶ Anthropic / OpenAI
│
your account, your invoiceSpec0 constructs a fresh provider client per request, signed with your key, and forwards the call directly to the provider. The request body and the response body never persist anywhere on Spec0's side. What we do persist is one row of metadata per call:
org_id,user_id,provider,model- input + output token counts
- latency in ms
- outcome (
ok,provider_error_<status>,transport_failure, …) - the Spec0 surface that initiated the call —
chat,test, and (as Phase 1 features ship)spec_critic,changelog,subscription_review,dashboard_insight
That last field is the one you can't get from your provider's console. Anthropic and OpenAI see one aggregate stream of calls from Spec0; only Spec0 knows which feature initiated each one.
Streaming responses
Chat responses stream — Ask Spec0 renders the answer token-by-token as the provider generates it, so you don't wait for a full reply before anything appears. Citations land before the first token (so source candidates are visible immediately) and the stream signals completion when the answer settles.
If you're integrating against the public REST surface directly rather than using the dashboard, the streaming endpoint is POST /api-management/api-discovery/chat/stream (Server-Sent Events). The non-streaming POST /api-management/api-discovery/chat returns the full response in one shot. Both paths route through the same BYO machinery; the only difference is the wire transport.
Usage attribution
Below the credentials card on the AI provider page, a Usage by Spec0 feature table breaks down activity over the last 7, 30, or 90 days:
| Feature | Successful calls | Failed | Tokens in | Tokens out |
|---|---|---|---|---|
Ask Spec0 (chat) | 4,217 | 12 | 1,829,440 | 312,008 |
Provider connection test (test) | 6 | 0 | 18 | 24 |
Below the table, a link out to your provider's billing console:
Token counts come from Spec0's audit log — useful for attribution by feature, but actual billing always reflects your provider's invoice (prompt caching, batch discounts, tier negotiations). Open Anthropic Console for the source of truth.
The deliberate non-feature here: we don't show dollar estimates. Token counts × public model rates always diverge from the invoice you actually pay (prompt caching, batch discounts, tier negotiations, free-credit allocations), and the gap turns into a permanent support load. We give you the per-feature attribution your provider can't, and we send you to the provider for the number that matters.
Why BYO
Three reasons, in order of how often they come up in conversations.
Procurement. If you've already signed a DPA with an AI vendor, routing AI calls through a third party's master key (ours) typically means a new procurement — data-flow review, security questionnaire, an addendum to the existing DPA. With BYO, the data flow is between you and the vendor you've already approved. Spec0 doesn't enter the procurement scope for AI usage at all.
Pricing transparency. When the customer pays the AI provider directly, Spec0 has no incentive to mark up tokens. Per-seat pricing for the platform stays decoupled from how aggressively your team uses AI features. We don't profit from heavy usage; we don't penalise light usage.
It frees us to ship more AI features. Internally, every AI feature used to come with a "what does this cost us per call" review. With BYO, the marginal cost of a new AI surface to Spec0 is the engineering — not the inference. That's why we can afford to put AI affordances next to most of the surfaces you already use, instead of holding them back for premium tiers.
The audit-log shape — metadata only, surface tag, attribution rolled up over the last 7 / 30 / 90 days in the UI — falls out of these reasons. You need attribution to debug "what's my chat costing"; you don't need Spec0 to be a parallel source of truth on dollars.
What's not on this page
- The agents docs MCP — that's a different surface (a public, unauth MCP server hosting Spec0's documentation as agent-callable tools). See AI agents. It runs on Spec0 infrastructure, not your provider key.
- Embedding provider. Embeddings are still on Spec0's deployment-wide key in v0; embedding cost is per-ingest (not per-query) and small enough that we haven't pushed it onto BYO. BYO-embeddings is on the roadmap.
- Per-feature provider routing ("Claude for the spec critic, GPT for the changelog"). Today one provider per org. We may add per-feature routing if the value differential between providers per Spec0 surface turns out to be material.