Choosing between astra, sol, terra and luna

Four models, one endpoint, one budget. The question a new account actually has is not which of them is best — it is which of them each part of the work should go to, and the answer is never a single name. It is a routing decision you make once per class of request and then check against your own itemised usage. What follows is that decision, in the order to make it.

Start with terra

Terra is the default rather than the compromise. Its published role is everyday assistant work — RAG, agents, tools and coding — and that covers most of what a product actually sends: ordinary chat, extraction with a structure to fill, the code assistance that is more typing than thinking. On input it is half of sol, 0.5 against sol's 1, and its output weight is 3 against sol's 5.

So start a new class of request there and be honest about the result. If terra's answers are the ones you would have shipped, you have found the right model and paid the lower half of the bill for it. Moving up is a decision to make on evidence you can point at — a failure you can show somebody — rather than as a precaution.

When a class of request earns sol

Sol is the anchor of the whole rate table: one sol input token is one credit, and every other number on this page is a ratio to that one. Its published role is deep reasoning, hard coding, Codex-style tasks and research, and that is also the test for moving. Move a class of request to sol when reasoning depth visibly pays — the hard bug terra keeps circling, the multi-step analysis whose middle steps have to be right for the conclusion to be, the change that has to hold a whole file in mind at once.

The move costs twice terra's input and two-thirds more output: 1 and 5 against 0.5 and 3. That is a small price for a class of request that was failing and now succeeds, and a poor one for a class that was already fine. Move the class rather than the application — nothing about these four is a global setting, and the cheapest thing on this page is the request you never promoted.

What astra is for

Astra is frontier reasoning on a 1M-token window, for the hardest work of all, and it is priced so that you spend it deliberately: 2.5 on input and 12.5 on output, against sol's 1 and 5. Read that as an instruction rather than a warning. Astra is for the final review before something ships, for the analysis somebody is going to act on, for the one-shot task nobody will read twice — the work where a wrong answer costs more than the tokens did.

One thing that is not part of the decision: length. There is no long-context surcharge on any model here. Every model's long-context rates are the same as its short-context rates, row for row, so a long document does not change which model it should be sent to. Choose on how hard the work is, and let the size of the input be whatever it is.

luna carries the background

Not everything a product sends is worth a reasoning model. Classification, tagging, short summaries, deciding which queue an item belongs in — the passes that run on every record and that no person reads on their own — are luna's, whose published role is fast drafts, classification, summaries and high-volume chat. At 0.05 on input it is twenty times cheaper than sol, and its output weight is 0.3.

Keep its prompts lean, though, or you will hand the saving straight back. A background job does not need your whole context: the long system prompt that makes your main assistant good is usually dead weight in a classifier, and a twenty-fold saving on the rate is undone by sending twenty times the tokens. Send the item, the labels, and nothing else.

Mix the four, then check the bill

Credits per token, by model and class, drawn straight from the catalogue this site prices everything else from — the four rows the paragraphs above are ratios of:

None of this is a setting you choose once. The four models share one endpoint and one key, and the model is a field in the body you are already sending — one word to change on the request that should be cheap, one word on the request that has to be right.

POST /v1/chat/completions

{
  "model": "terra",
  "messages": [
    {"role": "user", "content": "Summarise this ticket in one line."}
  ]
}

If your code already names an OpenAI-style model, it is read as the class it belongs to, so an existing configuration keeps working while you decide what to change it to. That is what makes the mix cheap to try: you are not migrating anything to run one class of request somewhere else for a week.

An agent that loops has two more things to get right. Keep a stable prefix at the front of every turn — the system prompt, the tool definitions, the instructions that do not change between turns — because a token read back from a cached prefix is charged at a tenth of its own model's input rate, and a loop that rebuilds its prompt each turn pays full price for the same words every time round. And route the tiers on purpose rather than by habit: the planner deciding what to do next has usually earned sol or astra, the workers carrying out its steps are terra, and the pass that files the results afterwards is luna. One agent, three models, deliberately.

Then check it. Every request is itemised in your portal against the rates in the table above — the model, the token class, the credits — so the mix you think you are running is something you can verify rather than guess at. That is what turns everything above from an opinion into a procedure: take the routing from this page, run a week of your own traffic through it, and read the itemisation back.