Choosing GPT models by workload: Astra, Sol and Luna in one application

The same application may summarize a short ticket, investigate a complicated failure and prepare a customer-facing recommendation. Calling all three “AI requests” hides the differences that determine model choice.

A routing policy assigns each kind of work to a model and configuration that has passed the relevant evaluation. It also states when the system should escalate, ask for information or stop. The cheapest possible request is not the objective. The objective is an acceptable result at an appropriate total cost and delay.

OpenAI's GPT-6 family provides several model choices, but the business still needs to define the work. Start with distinct task classes and a tested baseline. Add routing complexity only when it solves a measured problem.

What the GPT-6 names mean for this decision

OpenAI's model catalog, checked on 26 September 2026, presents GPT-6 Astra for its most demanding work, GPT-6 Sol as a balance of capability and cost, and GPT-6 Luna for cost-sensitive, high-volume workloads. These descriptions are useful starting hypotheses for an evaluation.

They do not establish that every short request belongs on Luna or that every long document belongs on Astra. Difficulty depends on ambiguity, required judgement, evidence quality and the consequence of an error.

Record the exact model identifier and relevant configuration in the routing policy. A label such as “premium” is not enough to reproduce a result after the application or provider changes.

Divide the workload by outcome

Begin with the business deliverable. A ticket category, a draft summary, an evidence comparison and an executable action proposal have different acceptance criteria.

Then record the input conditions. A summary of a clean, short conversation differs from a summary of multiple contradictory threads. A routing rule that looks only at input length may miss that distinction.

Finally, identify the error cost. A wrong internal tag can often be corrected cheaply. An incorrect customer commitment can create downstream work even if it is phrased politely and arrives quickly.

The table is a proposed policy shape. It is not a benchmark ranking of the three models.

Establish one baseline before a router

If the current application is small, a single well-tested configuration may be easier to operate than a dynamic router. It gives the team a stable starting point and makes failures easier to diagnose.

Collect representative tasks, record their acceptance criteria and run the baseline. Measure supported correctness, latency and review effort. Separate unusually difficult cases from the routine workload without quietly removing them from the results.

Only introduce a second route when there is a clear reason: a task class is consistently over-served, a difficult class fails the baseline or a time-sensitive interaction needs a different trade-off.

A complicated router introduced before this evidence can create an additional model-selection problem without reducing the original one.

Escalation needs an observable trigger

A common design asks a smaller model to rate its confidence and sends low-confidence answers to a stronger model. That score may be useful as one feature, but it is not a calibrated guarantee of correctness.

Prefer observable conditions where available. Escalate when evidence conflicts, a required field cannot be supported, a task exceeds the tested scope or the output fails a meaningful check. Route policy exceptions to a person when more reasoning cannot resolve the missing authority.

Do not escalate missing information into invented certainty

If the delivery system has no confirmed date, a stronger model cannot create one. If the requester has no permission to see a contract, escalation must not use a credential that bypasses the restriction.

Classify the reason for escalation. “Insufficient capability,” “missing evidence,” “invalid request” and “unauthorized action” are different conditions. Only some of them are candidates for a more capable model.

Count the cost of the whole route

A cheap first pass followed by a second call can cost more than sending the difficult task to the stronger model directly. The route also adds time, repeated context and another opportunity for the two outputs to disagree.

Measure the escalation rate and include both calls in the cost of the completed result. Count failed validation, rejected drafts and manual intervention. If the router keeps sending the same kind of task through two models, consider classifying it earlier.

A simple illustrative calculation

Suppose a hypothetical route costs one unit for the initial attempt and six additional units when escalation occurs. At an escalation rate of one in five, the average model cost is 2.2 units before review and other services. Those are invented accounting units to explain the method, not provider prices.

If a direct route costs two units and meets the same acceptance standard, the cheaper first pass has not saved money. Add latency and maintenance effort before deciding whether the router is worthwhile.

Preserve the evidence between routes

Escalation should pass the original task, permitted evidence and the specific reason for escalation. Do not give the second model only the first model's answer. Otherwise an unsupported claim can become the foundation for another polished response.

If the second route critiques the first draft, label the draft as generated material. Keep it separate from authoritative source records. Preserve the source versions so the two attempts can be compared fairly.

Record whether the final output used a new source lookup. A better answer based on fresh evidence is not proof that the second model alone caused the improvement.

Model choice and permissions are separate policies

A stronger model should not automatically receive broader tools. Route selection answers which model processes the assignment. Authorization answers which data and actions that assignment may access.

Keep these policies independent. If a task moves from Luna to Sol or Astra, the customer scope and operation limits should stay the same unless a separately authorized change occurs.

This also simplifies provider changes. The business can replace the model implementation while preserving its access boundaries and action checks.

Test routing against real operating conditions

An evaluation should include bursts, partial source failures and requests outside the expected categories. Measure the route chosen as well as the final output. A good answer obtained through an expensive unintended path can hide a routing defect.

Use a stable set of difficult cases that cannot be solved merely by matching keywords. A short message may contain a complex commercial exception, while a long transcript may require only a straightforward summary.

Run the same cases when changing the routing prompt, model configuration or task schema. If the route selection changes substantially, investigate before treating the change as an optimization.

Keep model updates reversible

Store the previous policy and preserve a rollback path. Record which version handled each job. When a reviewer reports a regression, the team should be able to distinguish a model change from a router change or a source-data change.

Avoid changing every route at once. A controlled change to one task class gives a clearer account of what improved and what became worse.

Make latency visible at the business level

Users experience the time until useful work is available, not only the provider's response time. A fast model behind a slow retrieval step may not improve the application.

For an interactive feature, show a clear pending state and a way to continue without the result. For background work, track queue age and completion deadlines. A model suitable for a nightly report may be unsuitable for a live agent-assist panel.

Define separate targets for each task class. Combining all model calls into one average obscures the very differences the routing policy is intended to manage.

A practical portfolio for a support application

In a hypothetical support portal, the team starts with three functions: assigning a permitted topic label, drafting an internal summary and investigating conflicting service records.

The team evaluates an efficient route for labels, a balanced route for summaries and a high-capability route for investigations. These are candidate assignments, not assumptions that any particular model will pass.

During the pilot, reviewers discover that some summaries involve contractual exceptions. Those cases become a separate task class with explicit evidence requirements. They are not simply hidden in the summary route's error rate.

The final policy names an owner for each class, the acceptance checks and the escalation destination. It also identifies requests that should remain manual, such as decisions requiring commercial discretion outside a written policy.

Know when to simplify again

Routing policies accumulate exceptions. A new model or a changed workload can make old distinctions unnecessary. Periodically compare the portfolio with a simpler baseline.

If several routes deliver equivalent quality and cost, consolidate them. If one rarely used route needs disproportionate maintenance, remove it or make it a manual option. The value of a router is the decision it improves, not the number of models it can select.

KYCONNECTS can help place this policy inside the application rather than leaving it as an undocumented prompt. That includes usage records, source boundaries and a reviewable change process.

Write the routing policy as an operational document

For each task class, record its input contract, candidate model, acceptance checks, maximum work budget and escalation destination. State which policy conditions override ordinary routing, such as missing authorization or unavailable evidence.

Keep the document readable by the product owner. A router that only its author can explain will be difficult to review when costs or errors increase. The useful question is whether another engineer can predict the selected path for a representative request.

Include a reason code in the job record. “Conflicting source versions” tells an operator more than “premium route selected.” It also allows the team to identify expensive routing caused by poor source quality rather than genuine reasoning difficulty.

Review the traffic mix, not only the model bill

Imagine that a new customer starts sending unusually long case histories. Spending increases even though neither the model nor the routing code changed. A report grouped only by model name makes the increase look like a provider problem.

A report grouped by task class, input category and reason for escalation shows the new workload. The team can then decide whether to improve retrieval, change the output scope or price the service differently. That decision belongs with the business owner as well as engineering.

Measure the effect of routing on review capacity. An inexpensive route that produces a larger volume of borderline drafts can overload the people responsible for approval. Include queue age and correction effort in the policy review.

Prepare a focused routing assessment

Bring representative tasks from each proposed class, including cases the current system handles badly. Provide the business deadline and the acceptance standard, not only a preferred model list.

Ask for a baseline result, a proposed routing table and a comparison of complete job cost. The deliverable should state where the evidence is insufficient and which routes should remain experimental.

A useful first implementation may have only two paths: a tested default and a manual exception. Add more models when the evidence supports them. This keeps the routing policy understandable and gives the operations team a service it can maintain.

Questions about GPT model selection