Getting started with Hyperpriors

Before you begin

You will need a Hyperpriors account, an API key from at least one model provider, and a project that makes LLM calls you would like to bring under control. The CLI works anywhere Node 20+ or Python 3.11+ runs.

Install the CLI and initialise your project:

npm install -g @hyperpriors/cli
hyperpriors init

hyperpriors init creates a hyperpriors.yaml in your project root. This file is the single source of truth for your harness configuration, eval suites, and guardrail policies — commit it alongside your code.

Step 1: Connect a provider

1. Run hyperpriors provider add and select your provider from the list.
2. Paste your provider API key when prompted. Keys are stored in your local keychain, never in hyperpriors.yaml.
3. Verify the connection with hyperpriors provider test. You should see a successful round-trip and its measured latency.

You can connect several providers to the same project. The harness treats them as interchangeable backends, which is what makes fallbacks possible later.

Step 2: Wrap your first call in a harness

A harness is the structured runtime that sits around a model call: it mediates tool use, applies retries and fallbacks, and emits a trace for every invocation. Wrapping an existing call is a small change:

from hyperpriors import harness

@harness("summarise-ticket")
def summarise(ticket_text: str) -> str:
    return client.complete(prompt=build_prompt(ticket_text))

The string argument names the harness. Everything that flows through it — inputs, outputs, tool calls, retries, token counts — is recorded against that name, so choose something you will recognise in six months.

Step 3: See your first trace

Trigger the wrapped call once, then open the dashboard:

hyperpriors dashboard

Under Traces you will find the invocation you just made. A trace shows the full lifecycle of a call: the resolved prompt, the provider and model used, any retries or fallbacks, latency and cost, and the final output. Traces are the raw material for everything else in Hyperpriors — eval suites replay them, guardrail policies annotate them, and drift detection watches them over time.

Where to go next

• Write your first eval suite so that behaviour changes surface in CI rather than in production.
• Define a guardrail policy to enforce boundaries on what the harness will let through.
• Explore the observability views for cost, latency, and drift once you have a day or two of traces.

One wrapped call is enough to start. Most teams wrap the rest within the week, largely because the traces make debugging noticeably less archaeological.