> ## Documentation Index
> Fetch the complete documentation index at: https://docs.valarhq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# ValarCode overview

> Route your coding agents through Valar to cut spend, with per-engineer routing and measured savings

ValarCode puts Valar in front of your coding agents. Claude Code, Claude Desktop, Cursor, Codex, Pi and VS Code keep working the way they do now, but their model calls go through Valar, an inference provider built for agentic workloads. Valar runs both frontier Claude models and open-weight models on throughput-optimized inference, so agents get highly efficient serving whichever model they land on.

Most of ValarCode's value comes from that serving. Because open-weight models run on the same throughput-optimized inference, you can route part of your coding traffic to them and cut cost without giving up serving efficiency. You control the split across engineers, and the dashboard shows usage and savings against a Claude-only baseline.

Engineers run one connect command and carry on as usual. Each Opus, Sonnet, Haiku, or Fable request is routed — by Valar's Auto routing, or by a split you set — to either a frontier Claude model or an open-weight model such as GLM-5.2, Kimi-K3, or DeepSeek-V4-Pro.

## Why teams use it

* Cut coding-model spend by more than 50%. Open-weight models on Valar cost well under half of the equivalent Claude call, so routing traffic to them lowers the bill directly.
* Improve efficiency. Every request runs on Valar's throughput-optimized inference built for agents, which keeps the open-weight models usable as an everyday default and not just a cheap fallback.
* Keep the existing workflow. Engineers connect their harness once with the CLI, and routing is managed server-side on the coding key.

## How it works

```mermaid theme={"system"}
flowchart LR
  MSG["Claude Code · Claude Desktop<br/>Pi · VS Code"] -->|"/v1/messages"| GW["Valar gateway"]
  RSP["Codex"] -->|"/v1/responses"| GW
  CHAT["Cursor"] -->|"/v1/chat/completions"| GW
  GW --> RT["Route request<br/>Opus / Sonnet / Haiku / Fable to target model"]
  RT --> MS["Valar model serving"]
```

1. An engineer connects their harness with a **coding key** using the `valar` CLI. Connecting changes only the base URL and the key; the model names the harness sends are left unchanged.
2. On each request, Valar reads which model class the harness asked for (Opus, Sonnet, Haiku, or Fable) and routes it to a target model. Valar picks that target by default; you can also set the mapping yourself per cohort.
3. Valar serves the request on throughput-optimized inference tuned for agents, whether the target is a Claude model or an open-weight one.
4. Usage is attributed per engineer, and the dashboard shows how serving is performing alongside savings against a Claude-only baseline.

Most harnesses speak the Anthropic Messages API, so ValarCode gives them an Anthropic-compatible `/v1/messages` endpoint. Codex uses `/v1/responses` and Cursor `/v1/chat/completions`. All require a coding key.

## Get started

<CardGroup cols={2}>
  <Card title="Set up ValarCode" icon="rocket" href="/valarcode/setup">
    Install the CLI, create a coding key, and connect a harness.
  </Card>

  <Card title="Model routing" icon="route" href="/valarcode/routing">
    How cohorts and the split decide which model serves each request.
  </Card>

  <Card title="Models" icon="microchip" href="/valarcode/models">
    The open-weight targets and the frontier Claude tiers.
  </Card>

  <Card title="Analytics & savings" icon="chart-line" href="/valarcode/analytics">
    Per-engineer usage and how savings are worked out.
  </Card>
</CardGroup>

## Supported harnesses

Each harness has its own page covering how to connect it and what the CLI writes behind the scenes:

<CardGroup cols={3}>
  <Card title="Claude Code" icon="code" href="/valarcode/claude-code">
    `valar claude on`
  </Card>

  <Card title="Claude Desktop" icon="desktop" href="/valarcode/claude-desktop">
    `valar claude-desktop on`
  </Card>

  <Card title="Cursor" icon="command" href="/valarcode/cursor">
    `valar cursor on`
  </Card>

  <Card title="Codex" icon="terminal" href="/valarcode/codex">
    `valar codex on`
  </Card>

  <Card title="Pi" icon="microchip" href="/valarcode/pi">
    `valar pi on`
  </Card>

  <Card title="VS Code" icon="window" href="/valarcode/vscode">
    `valar copilot on`
  </Card>
</CardGroup>

## LiteLLM

If you run a LiteLLM proxy, you can keep it and still use ValarCode. Claude Code (or Pi) points at LiteLLM, LiteLLM forwards to Valar, and per-engineer routing and attribution work as long as the client id header survives the hop.

<Card title="LiteLLM integration" icon="diagram-project" href="/valarcode/litellm">
  Route Claude Code through a LiteLLM proxy without losing per-engineer attribution.
</Card>