Architecture

How a request travels through CoreValue: the ways in, the checks before the provider, how cost and budgets are kept, where data is stored and what happens when something fails.

CoreValue sits between your applications and the AI providers they call. Every request passes through the gateway, which checks it against your keys, budgets and policies, forwards it, and records what it cost. The console reads those records to show spend, run budgets and produce reports.

  Your applications and agents
  OpenAI · Anthropic · Google SDKs · Claude Code · MCP clients · agents
                         │
                         ▼
  ┌──────────────────────────────────────────────────────┐
  │  CoreValue gateway        https://gateway.corevalue.dev │
  │  identify key → check budgets and policy → forward     │
  │  → price the response → settle budgets → record        │
  └──────────────────────────────────────────────────────┘
          │                                   │
          ▼                                   ▼
  AI providers, MCP servers,          Requests, spend and budgets
  agents                              in the console (app.corevalue.dev)

The ways in

Surface	What it is	Docs
LLM gateway	The provider APIs your SDKs already speak: OpenAI-compatible (`/v1`), any provider by model prefix (`/gateway/v1`), and the native Anthropic, Google, Bedrock and Vertex endpoints.	OpenAI, Anthropic, Gemini
MCP gateway	One endpoint in front of your MCP servers. Tool calls are checked against access rules and logged with their cost.	MCP gateway
Agent gateway	Calls between agents (A2A), with rules on who may call each agent.	Agent gateway
CoreValue SDK	Optional helpers for TypeScript and Python. They set `Cova-*` headers and read cost from responses. They do not proxy or change your calls.	CoreValue SDK

A request, step by step

Identify the caller. The CoreValue key is looked up by its SHA-256 hash. The key's scopes decide which customers, models and providers it may use.

Choose the provider key. Your own provider key for that provider is used first. Your application never sees it.

Apply limits and policy. Rate limits, blocked models, and, where you have turned them on, guardrails that redact or refuse personal data.

Check budgets. Every budget that covers the request is checked: the organisation, its team, the member, the customer and the key. A budget set to block holds the request's estimated cost against its remaining amount, so concurrent requests cannot overspend it together. An organisation or team budget set to downgrade rewrites the model to a cheaper one instead.

Forward. The request goes to the provider unchanged. Failures with status 429, 500, 502, 503, 504 or 529 are retried, and a Cova-Fallbacks chain tries other models in order. Streams pass through as they arrive.

Price the response. The gateway reads the provider's usage (input, output, cached and reasoning tokens) and prices it from CoreValue's price table. The cost is returned in Cova-Request-Cost.

Settle and record. Each held amount is corrected to the actual cost, and the request is recorded with its cost, tokens, latency and tags. Recording happens after your response is sent, so it adds no time to the request.

Budgets

Budget counters are kept in micro-dollars, so sub-cent requests add up exactly. A held amount that is never settled, for example because a stream was abandoned, expires after five minutes rather than holding the budget forever. Budget settings are cached for up to 60 seconds, so a change takes effect within a minute. See Budgets.

Cost

CoreValue prices requests itself, from its own table of models and their rates. It prices input and output tokens, cached input, cache writes, reasoning tokens, per-request fees, images, audio and web search where a model charges for them. A model with no price is recorded at $0 and marked unpriced, so it shows up rather than disappearing. See How cost is calculated and Supported models.

Where data lives

All of it runs on Google Cloud in us-central1.

Store	What it holds
PostgreSQL	Organisations, members, teams, budgets and policies; CoreValue keys as SHA-256 hashes; your provider keys; the audit log.
ClickHouse	One row per request: model, provider, tokens, cost, latency and your tags.
Redis	Rate-limit and budget counters, short-lived caches, and the response cache, which is encrypted.

When something fails

If…	Then
The provider fails or rate-limits	The request is retried, then sent to the next model in `Cova-Fallbacks` if you set one.
Budget data cannot be read	The request is served. Budgets never take your traffic down.
Recording a request fails	Your response is unaffected; it was already sent.
A request is refused by a budget	HTTP `429`, before anything reaches the provider.

Security

Your keys stay out of your code. Applications hold only a CoreValue key; provider keys are stored in CoreValue and added to the request on the way out.
CoreValue keys are stored as hashes, so a key cannot be read back, only replaced.
Access in the console is decided by roles, and significant changes to budgets, roles, keys and integrations are recorded in the audit log.
Personal data in requests and tool calls can be redacted or refused by guardrails.

See Data and privacy for compliance.