A Model Guide for the GPT-6 Family: Three Tiers, Reasoning Effort and Cost Control

On October 2, 2026, OpenAI published "A model guide for the GPT-6 family," a practical document aimed at startups and developers. The guide does not announce a new model. Instead, it turns a lineup that is already on sale into an engineering method that teams can follow. The framing is clear from the first paragraph: GPT-6 is a suite, not a single model. The suite has three members. GPT-6 Astra is described as the most intelligent, priced at $10.00 per million input tokens, $50.00 per million output tokens, and $1.00 for cached input. GPT-6.1 Sol offers near-Astra intelligence for a fifth of the price, at $2.00 input, $10.00 output, and $0.10 cached input. GPT-6 Luna targets fast, efficient everyday work at scale, at $0.10 input, $0.50 output, and $0.01 cached input. The spread is wide. Luna's input price is one percent of Astra's. Model choice therefore stops being a question of "use the best one" and becomes a budgeting decision that every team must make deliberately.

The first section of the guide covers running well in production, and its central advice is to manage context before anything else. Cut the context a task does not need, but keep the evidence it does need. Run independent tasks together so that one slow step does not hold up unrelated work. Reuse shared context through prompt caching for recurring work. OpenAI states that cached input tokens cost up to 95 percent less than uncached input tokens, depending on the model. The price list bears this out: Sol's cached rate of $0.10 is one twentieth of its standard input rate. To collect that discount, teams should place stable instructions and reference material before the changing task details, and keep tool definitions consistent from call to call. A caching dashboard and a diagnostics guide help teams see where reuse breaks down. When estimating the cost of a complete workflow, the guide adds, include cache writes and any long-context rates. For longer conversations, compaction reduces context size while preserving the state needed to continue. Before deployment, teams should run representative tasks and measure task success, latency, and cost per successful task. That last metric deserves attention. A cheap call is not a cheap workflow. A model that needs three attempts to finish a job may cost more in practice than a pricier model that finishes it once.

The second section addresses matching the model to the workload, which the guide frames as an intelligence and price tradeoff. Astra is reserved for the hardest reasoning work, where maximum intelligence is needed. Sol fits complex coding, research, and computer use. Luna suits focused tasks at scale with a clear goal, such as extracting invoice fields, classifying requests, or producing structured summaries. Beyond the model, the API lets developers choose a reasoning level. Low effort suits routine tasks such as extracting facts or making small edits. Medium suits work that requires judgment, such as planning a feature or comparing options. High suits difficult debugging, deeper analysis, or careful review. The extra high or max tiers, where supported, should be tested only when High falls short, and kept only if the improvement justifies the added time and cost. In the API, reasoning effort can change mid-conversation without breaking the cache. In Codex, the advice is to start at the default level for the model, then lower it for simpler tasks or raise it for deeper analysis. Where response time matters, as in chat apps and coding tools, the API also offers a Fast mode. Together, model, effort, and speed give teams three dials. They let a team configure cost per task rather than per product line.

The third section turns to prompts and skills. The guide asks developers to give the model a clear assignment and to define the output they need. Prompts, skills, and repository instructions should agree with one another on what the model should deliver, what it may do independently, and what counts as done. This sounds ordinary, yet it is among the most common sources of failure in agentic workflows. If a repository file says the model may edit freely while the prompt says to ask first, the model will swing between two instructions. Writing the definition of done as a testable condition also reduces the tendency to stop too early or to polish without end.

The fourth section concerns long-running work. OpenAI recommends steering, async tools, and delegation to handle mid-task updates and independent subtasks, and it asks teams to set clear boundaries for when the model should stop and ask for input. For long tasks, that boundary matters more than raw intelligence, because an agent that acts when it should have asked costs far more than one extra question. For Codex, the guide also points to computer use, which lets the model do more of the job that a person would otherwise perform by hand. The article closes with examples of teams moving from testing to production with GPT-6 Astra.

The value of this guide lies less in new capability than in how it makes cost control part of product design. Teams used to pick the strongest model first and then hunt for savings. OpenAI now proposes the opposite order. Define the task and the success criteria. Choose the cheapest model and effort level that meets them. Then use caching, compaction, and parallelism to reduce the bill. For startups, this means an evaluation set and cost per successful task should become daily metrics. Tiered models with adjustable reasoning effort are likely to become the default industry pattern, and competition will shift from single benchmark scores toward the reliability and unit economics of whole workflows.