One subscription,
the whole model spectrum.

Three steps, five minutes

No credit card, no currency exchange, no documentation to read. It works even if this is your first time using a model service.

# Step two is this one line
curl -fsSL https://agiplan.dev/setup -o setup.sh && sh setup.sh

# Load it into this shell, then check the connection
. ~/.config/agiplan/env
curl -s "$API_BASE_URL/models" -H "Authorization: Bearer $API_KEY"

Everything the script does is documented, and you can skip it entirely — two environment variables do the same job. The key goes into a config file in your home directory (mode 600), outside any project, so it can't be committed to git by accident. The command-line tool isn't released yet, and the script doesn't pretend to install anything.

Whatever you use today probably just works

We speak both mainstream API protocols. If a tool lets you change its endpoint, changing that one setting is the whole integration. No plugin, no code changes.

Prism sends each task where it belongs

The work you do in a day varies enormously in difficulty. Renaming a variable and refactoring a module run on the same expensive model — that's exactly how the money burns.

Prism is our routing layer. Every request passes through it first, gets assessed for difficulty and required capabilities, then lands at the right point on the spectrum. Use the auto preset we maintain, or write your own rules.

This is an estimate based on task mix, not a guarantee. Your real multiplier depends on your actual distribution — the console sends you a measured comparison every month.

Want to pick the model yourself? Always an option

One model field, two ways to use it: name a specific model and it's pinned to that one; put auto or your own custom model name there and Prism routes it. Switching between the two changes nothing else — no reconfiguration, no code churn.

model: "model-a"        // Pinned to this model, Prism stays out of it
model: "auto"           // Handed to Prism, picked by task difficulty
model: "coder"          // Your own custom model, your own rules

A model name of your own that picks a model per turn

Answer four questions and you get a model name of your own, such as coder. Call it and taste-dependent or hard work goes to a strong model, clearly simple work to a cheap one, and the rest to the default you chose. Every rule and threshold is laid out in the console; replay a change against your own traffic, then save it as a new version.

Routing by task type is planned and not yet open. You can already create and call a custom model; until it opens, every turn goes to the model you set for “when unjudged”, and nothing needs to change on your side when it does.

Cheaper must never mean worse. When difficulty lands near a boundary, auto always rounds up — paying a little more beats degraded output every time, and that is hard-coded. In a custom model the lean is yours: work only goes down as far as you tilt it toward cost, and every such step is recorded in the routing trace.

If a model fails, we switch to a same-tier backup

Any model can hit a rate limit, time out, or go down. Prism immediately hands the request to a backup model in the same capability tier, so this call doesn't fail. It's on by default, and you can turn it off.

Every routing decision can be replayed

Automatic routing naturally invites the suspicion that you're being quietly served something cheap. The only answer is to show you every decision. Each request keeps a trace, retained 30 days, exportable.

Traces hold metadata only, never request bodies — the same architecture as the zero-retention promise in section 07. When something breaks, send us the trace_id and support can pull it up instantly.

We don't compete on price. That effort goes somewhere else: staying up, adding up, and owning it when things break.

Your code and prompts are not stored by default

You're about to send us the most sensitive material you have — source code, internal documents, client data. This section is wordier than a marketing page should be. Please actually read it.

Your request bodies have a market price

This rarely gets said out loud. Every prompt and every file a user sends can be recorded in full — distilled into smaller models, packaged and sold as training data, or quietly traded between platforms. No notification is sent, and the terms usually contain no explicit prohibition.

The internal documents, client data and unreleased code you pasted in may already be in somebody's training set.

We're against this, and not only in words.

1. 01

   Zero retention is architecture, not policy

   There is no code path in the gateway that writes a request body anywhere. Not "we promise not to look" — there is nowhere to put it. This is auditable.

2. 02

   We buy no data of unclear origin

   We purchase request corpora from no platform and no data broker, at any price, under any label.

3. 03

   We refuse data-for-price deals

   When a provider offers a lower rate in exchange for data sharing, we decline — even though it means higher costs and thinner margins for us.

4. 04

   We're willing to pay for it

   Every line above reduces what we can earn. That's the price we chose to pay, and the reason we'd like your money instead of somebody else's.

5. 05

   We accept verification

   All of this goes into the terms of service with legal force. We accept third-party security audits, and you're welcome to inspect the traffic yourself.

We can't change the whole industry. But whatever passes through our pipe, we can guarantee it goes nowhere else.

You're probably wondering.