Claude Code

Claude Code reads ANTHROPIC_AUTH_TOKEN and ANTHROPIC_BASE_URL from the environment. Point those at Wardin and every Claude Code session is automatically tracked, budgeted, and policy-enforced — no changes to how your team uses Claude Code.

Setup

export ANTHROPIC_AUTH_TOKEN=wardin_sk_YOUR_KEY
export ANTHROPIC_BASE_URL=https://gw.wardin.ai

ANTHROPIC_API_KEY works too — the gateway accepts both the Authorization: Bearer and x-api-key auth headers. ANTHROPIC_AUTH_TOKEN is preferred for gateways because Claude Code treats it as a proxy credential and won’t prompt about a custom API key.

Add these to your shell profile (~/.zshrc, ~/.bashrc) or your team’s shared environment setup. You can also set them per-project using a .env file (never commit it) or your shell’s direnv setup.

What gets tracked

Once routed through Wardin, every Claude Code request appears in the dashboard with:

Token usage — input, output, cache creation, cache read (split correctly for Claude Code’s prompt-caching-heavy workload)
Cost — broken down by token type
Session grouping — Claude Code requests are grouped into sessions automatically using idle-timeout bucketing (30-minute sliding window). One coding task = one session.
Model — which Claude model was used for each request

Issuing team keys

Create one virtual key per developer:

# Create a key for each developer
curl -X POST https://api.wardin.ai/v1/keys \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "alice-claude-code",
    "keyClass": "interactive",
    "budgetUsd": 100,
    "ownerId": "550e8400-e29b-41d4-a716-446655440000"
  }'

See the full endpoint reference: POST /v1/keys. Send each developer their wardin_sk_ key. They set ANTHROPIC_AUTH_TOKEN=wardin_sk_... and nothing else changes. (Keys can also be created in the dashboard: Console → Keys & Limits.)

CI / headless usage

For CI pipelines, create a separate key with its own budget pool:

curl -X POST https://api.wardin.ai/v1/keys \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "ci-claude-code",
    "keyClass": "ci",
    "budgetUsd": 200,
    "rpmLimit": 20
  }'

See the full endpoint reference: POST /v1/keys. CI keys return structured JSON errors on 429/403 — no HTML, no human-readable pages.

Model allowlist for Claude Code

If you want to restrict Claude Code to specific models (e.g., block Opus for cost control):

curl -X POST https://api.wardin.ai/v1/policies \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "claude-code-models",
    "type": "model_allowlist",
    "enabled": true,
    "yaml": "routing:\n  allowed_models:\n    - claude-sonnet-4-6\n    - claude-haiku-4-5\n"
  }'

See the full endpoint reference: POST /v1/policies. Note this is tenant-wide, not Claude-Code-specific — it restricts every key in the tenant, not just Claude Code traffic. Claude Code will receive a 403 with a clear error message if it attempts to use a blocked model.

Session attribution in the dashboard

Claude Code doesn’t send a session ID by default. Wardin groups consecutive requests (< 30 minutes apart) into sessions automatically. You can also set a session ID explicitly via Claude Code’s custom-headers variable:

export ANTHROPIC_CUSTOM_HEADERS="X-Wardin-Session-Id: my-task-$(date +%s)"

ANTHROPIC_CUSTOM_HEADERS is a Claude Code convention that attaches extra headers to every API request. Wardin trusts an explicit X-Wardin-Session-Id as-is; without it, the idle-timeout bucketing applies.

Grading a session from its GitHub PR outcome

OUTCOMES’ quality score is driven by real GitHub PR outcomes, not manual grading — a merged, closed, or reverted pull request is the acceptance signal. Nobody has to click anything inside Wardin for it to count. The linkage is the same session id, twice: once in the request header above, and once as a footer line in the PR body. When your Wardin tenant has a GitHub connection for the repo, the pull_request webhook carries the footer straight to the scoring pipeline — merged scores 1.0, closed-unmerged scores 0.0, and an auto-revert re-scores the original PR back down to 0.0. No GitHub API calls, no extra client-side tooling.

export WARDIN_SESSION_ID="task-webui-refactor-$(date +%s)"
export ANTHROPIC_CUSTOM_HEADERS="X-Wardin-Session-Id: $WARDIN_SESSION_ID"

Then, when the task’s PR is opened, add a line carrying the same id to the PR body:

Wardin-Session-Id: task-webui-refactor-1751830000

Drop this block into the repo’s CLAUDE.md so Claude Code writes the footer itself, the same way it already writes a Co-Authored-By: trailer:

## Wardin session attribution

Before your first request in a task, set a session id and export it as a
custom header:

```bash
export WARDIN_SESSION_ID="task-<short-desc>-$(date +%s)"
export ANTHROPIC_CUSTOM_HEADERS="X-Wardin-Session-Id: $WARDIN_SESSION_ID"
```

When you open a pull request for this task, add this line to the PR body,
substituting the exact value of `$WARDIN_SESSION_ID` from that task:

```
Wardin-Session-Id: <value of $WARDIN_SESSION_ID>
```

Reuse the same id for the whole task, even across multiple requests or tool
calls. If the task produces more than one PR, add the same footer line to
each.

This is opt-in per team: a repo needs a Wardin GitHub connection for the webhook to reach the scoring pipeline, and a PR needs the footer to be matched. Missing either produces no signal — never a wrong one. Ask your Wardin admin whether your repo is connected; the OUTCOMES screen’s coverage meter shows how many sessions are graded so you can see the coverage directly.

Getting Started

Concepts

Gateway

Guides

Setup

What gets tracked

Issuing team keys

CI / headless usage

Model allowlist for Claude Code

Session attribution in the dashboard

Grading a session from its GitHub PR outcome

​Setup

​What gets tracked

​Issuing team keys

​CI / headless usage

​Model allowlist for Claude Code

​Session attribution in the dashboard

​Grading a session from its GitHub PR outcome

Setup

What gets tracked

Issuing team keys

CI / headless usage

Model allowlist for Claude Code

Session attribution in the dashboard

Grading a session from its GitHub PR outcome