Choosing between astra, sol, terra and luna

Five 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 fast, efficient everyday work — agents, tools, coding, computer use and visual tasks — 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, the agent step that reads a screen and acts on it. It is 0.55 on input and 2.75 on output, each one half of what sol-6.1 and sol-6 charge.

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, at 0.55 credits per input token. 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-6.1 is the anchor of the whole rate table: one sol-6.1 input token is 1.1 credits, and every other number on this page is a ratio to that one. Its published role is deep reasoning, hard coding, agentic 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 provider's own guidance for the model terra runs says the same: for the most complex coding, sol-6.1 and astra remain the stronger choice.

On sol-6.1 or sol-6 the move doubles what that class of request costs: 1.1 on input against terra's 0.55, and 5.5 on output against terra's 2.75. That is a fair 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 five 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: 5.5 on input and 27.5 on output, five times what sol-6.1 charges for each. 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. luna-6 is 0.055 on input and 0.275 on output, twenty times cheaper than sol-6.1 on both.

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.

sol-6.1, sol-6 and luna-6, the GPT-6 generation

Sol's GPT-6.1 model, the newest in the family, at 1.1 AI credits per input token. The GPT-6 generation of Sol, at 1.1 AI credits per input token. The GPT-6 generation of Luna, at the lowest rates published here. sol and luna still work as model names for existing integrations: they now run sol-6.1 and luna-6, billed at those models' rates. Requests that name GPT-5.6 Terra are served by terra, which runs GPT-6.1. Naming sol-6.1 or luna-6 yourself is the same one-word change as any other move on this page, and the itemisation in your portal shows what each request cost.

Mix the five, then check the bill

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

None of this is a setting you choose once. The five 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 half 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-6.1 or astra, the workers carrying out its steps are terra, and the pass that files the results afterwards is luna-6. 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.