Summary

Choosing the right AI model for application development is not simply a matter of picking the most capable model available. The better objective is to match each task to the lowest-cost model and reasoning level that can deliver the required quality quickly and reliably.

The framework in this article separates the problem into three parts. First, describe the task in terms of its complexity, context depth and consequence. Second, choose the model configuration in terms of model tier and reasoning effort. Third, evaluate the output in terms of quality, speed and cost.

For my own agentic-first, AWS-first and specification-led development workflow, this leads to a pragmatic operating model. In September 2026 I use Luna Low for mechanical and easily validated work, Luna (x)High for more substantial but still bounded tasks, and Sol High for complex, deep-context or high-consequence architectural work. Terra currently plays a smaller role in my workflow and my choices may change as my workload changes.

The most important lesson, however, is that ValueMaxxing is not just about routing work to the right model. It is also about structuring work so that cheaper models can succeed. By minimizing unnecessary context, reducing task complexity, exposing assumptions through planning, keeping threads bounded, changing reasoning effort between turns, and using handovers to reset context, the developer can improve quality while reducing both latency and model usage.

This is not a fixed recipe. Models, prices, usage limits and workloads all change. ValueMaxxing is therefore a continuing discipline of classify → route → measure → learn → re-route.

Updates

2026-09-10: Added /Status hint

Introduction

Every developer’s workload is different, so there can be no universal answer to the question of which AI models to use.

In this article I examine the factors that will guide your choice in the context of my own application-development workflow. My aim is not to prescribe a particular model, but to develop a practical framework for thinking about model selection and reasoning effort that I hope will help other developers make better-informed choices for their own workloads.

My Application-Development Workflow

My development approach is agentic-first, AWS-first and specification-led.

Agentic-first means that I design my development process around AI agents as active participants in the software-development lifecycle. Agents do not simply provide occasional coding assistance; they help create and maintain specifications, architectural artefacts, implementation code, tests and supporting documentation.

AWS-first means that I prefer AWS-managed services, AWS-supported integrations and AWS application patterns where they adequately meet the requirement, rather than building or adopting alternatives unnecessarily.

Specification-led means that specifications and architectural documentation precede and guide implementation. Architectural Decision Records (ADRs), requirements, standards and other project artefacts are not documentation created after the software has been written. They form part of the authoritative context from which agents subsequently work.

This creates a distinctive AI workload. Early in a project I work extensively with documentation, often before much application code exists. As the project develops, the corpus grows to include specifications, ADRs, plans, standards, source code, tests and infrastructure definitions. Some tasks operate on a single small file; others require an agent to understand decisions distributed across a substantial body of project context.

I am a solo developer and have a strictly limited budget. I have a $20-per-month ChatGPT Plus subscription. This does not give me a literal dollar-denominated daily token budget: Codex usage is governed by included allowances and rolling usage limits. In practice, however, the constraint feels very real. Before I started managing model choice and reasoning effort carefully, I could exhaust my five-hour usage allowance by 11am.

The challenge is therefore not simply to choose the most capable AI model available. It is to determine which model, at which reasoning level, provides sufficient capability for each task without unnecessarily consuming time, money or a limited AI usage allowance.

My Development Use Cases

My application-development workload can be grouped into a number of recurring use cases:

• Specification
• Architecture and ADRs
• Documentation
• Cross-document analysis
• Coding
• Testing and review
• Debugging
• Development operations

Each use case contains many individual tasks, and those tasks can have very different characteristics.

For example, documentation may include anything from correcting Markdown formatting in a single file to restructuring a large specification. Architecture may include drafting a new ADR, reviewing an existing ADR, or checking a set of decisions for contradictions. Coding may range from a small local change to a repository-wide refactor.

The model should therefore not be selected simply according to the use case. The relevant unit for model selection is the task within that use case.

Common Tasks and Their Attributes

The following table shows some common tasks from my development workflow, starting with those where an incorrect result could have the greatest downstream consequences.

Task	Complexity	Context Depth	Consequence
Make or revise an architectural decision	High	High	Very High
Review specifications and ADRs for consistency	High	Very High	Very High
Produce or materially revise a core specification	High	High	Very High
Generate implementation code from an approved specification	Medium–High	Medium–High	High
Review agent-generated code	Medium–High	Medium–High	High
Implement a feature spanning several files	Medium–High	Medium–High	Medium–High
Summarise a specification for working reference	Low–Medium	Medium	Medium
Correct Markdown formatting in one file	Low	Low	Low

This ordering is deliberate. A task does not need to be technically difficult to justify a more capable model. Consequence can dominate the routing decision.

An ADR is a good example. Drafting an ADR may not require more raw reasoning than debugging a difficult local defect, but an incorrect architectural decision can propagate into later specifications, infrastructure, code and tests. The quality threshold for that task should therefore be much higher.

At the other end of the table, a Markdown formatting error is normally local, visible and cheap to correct. These tasks are strong candidates for inexpensive models and low reasoning effort, particularly when automated validation can detect failures.

A Practical Model-Selection Framework

It is useful to separate three things that are often mixed together when discussing AI model selection: the task, the model configuration, and the resulting output.

Task Profile

I describe a task using three attributes:

• Complexity — how much reasoning, judgement, planning or problem-solving is required.
• Context depth — how much information must be retained, located, cross-referenced and understood together to perform the task correctly.
• Consequence — how costly an incorrect result would be and, particularly in specification-led development, how far that error could propagate into subsequent work.

These dimensions are independent. A difficult algorithmic problem may require substantial reasoning but very little context. Conversely, checking a large collection of ADRs for contradictions may require deep context even though each individual decision is straightforward.

Consequence is particularly important in my workflow. Incorrectly formatting a Markdown file is a low-consequence error: it is local, obvious and easily fixed. An incorrect ADR is different. Once accepted, the decision may influence specifications, infrastructure, implementation, tests and later architectural decisions. A relatively small error can therefore propagate throughout the project.

Workload

A task also has to be considered in terms of volume.

The cost difference between two model configurations may be insignificant for a task performed once. The same difference becomes important when an agent performs that task hundreds of times. This is particularly relevant to repetitive development activities such as formatting, linting, documentation maintenance, code analysis and test generation.

Volume therefore changes the economics of model selection even though it does not change the intrinsic characteristics of the individual task.

Model Configuration

Once the task is understood, there are two principal model attributes I can control:

• Model tier — the capability and cost level of the model selected.
• Reasoning effort — how much reasoning capacity the model is permitted to apply to the task.

These are separate choices. Moving to a more capable model is not the same as allowing the existing model to reason for longer. A cheaper model with greater reasoning effort may sometimes provide better value than immediately moving to the most capable tier.

Model Output

The chosen model configuration produces an outcome with three attributes:

• Quality — whether the result is correct, complete and suitable for its intended purpose.
• Speed — how long it takes to obtain a usable result.
• Cost — the resources consumed in obtaining that result.

Quality is the constraint that comes first. A cheap answer is not good value if it is wrong.

Cost also means more than the visible length of the answer. Reasoning models may consume substantial hidden reasoning tokens before producing a very small response. Failed attempts, retries and subsequent escalation to a stronger model consume resources as well. The meaningful measure is therefore closer to cost per successful usable result than cost per individual request.

Routing

Routing is the process of matching the task to the model configuration.

Conceptually:

Task Profile
Complexity × Context Depth × Consequence

Workload
Volume

↓

Routing

↓

Model Configuration
Model Tier × Reasoning Effort

↓

Model Output
Quality × Speed × Cost

The objective is not simply to minimize cost. It is to find the lowest-cost model configuration that reliably achieves the quality required by the task within an acceptable time.

Consequence affects that quality threshold. I can tolerate an occasional mistake in a low-consequence operation if it is immediately detectable and inexpensive to correct. I should demand much greater reliability from an architectural decision whose consequences may propagate throughout the project.

Budgeting, Failure and Retry

Routing also needs an execution policy. In my case there is a very practical constraint: I have a finite AI usage allowance.

Reasoning is therefore a resource to allocate rather than something to maximize automatically. Spending a large proportion of my allowance on mechanical operations leaves less capability available for architectural reasoning, specification development and difficult coding later in the usage window.

Failures matter for the same reason. A cheaper model that frequently fails, needs repeated prompting and eventually has to be escalated may be more expensive than selecting the stronger model initially.

For each recurring task I therefore want to understand:

• how frequently it occurs;
• how much reasoning it normally consumes;
• how often it succeeds first time;
• how often it requires retry or escalation; and
• whether the resulting quality justifies the resources consumed.

The Current Model Landscape

Sources

• (27) Valuemaxxing Reasoning Tokens: The Cheapest Reasoning Model Isn’t Always the Lowest-priced One | LinkedIn
• GPT-5.6 Sol vs Terra vs Luna: Which Model Should You Use?
• Sol, Terra or Luna. Choosing the Wrong one Can Cost you Five Times More than it should.
• GPT-5.6 Sol, Terra & Luna: Complete 2026 Guide

The sources above were published during the GPT-5.6 launch period, so some of their pricing is already out of date. Their benchmark results remain useful, but the prices below use current OpenAI pricing as of September 2026.

The broader OpenAI landscape has also continued to evolve. GPT-6 Astra was released in September 2026 and is becoming available in ChatGPT Work and Codex. My focus here remains deliberately narrower: Luna, Terra and Sol are the GPT-5.6 tiers around which I currently structure most of my development workflow.

OpenAI offers three GPT-5.6 tiers: Luna, Terra and Sol. They belong to the same model generation, but they are separate models optimized for different points on the capability, speed and cost curve rather than three settings of one model.

There is also an important product distinction. In standard ChatGPT conversations, Terra and Luna are not selectable models. In ChatGPT Work and Codex, however, Plus users can choose between Sol, Terra and Luna. Since my application-development workflow takes place primarily in Codex within VS Code, it is this latter model choice that matters to the discussion below.

GPT-5.6 Luna

Luna is the low-cost, high-throughput tier. Current OpenAI pricing is $0.20 per million input tokens and $1.20 per million output tokens, compared with $4 and $20 respectively for Sol.

Luna therefore costs just one twentieth of Sol’s input price and 6% of Sol’s output price. Its economic attraction for high-volume work is consequently even stronger than the launch-era comparisons in the articles suggest.

Luna is therefore an attractive candidate for work that is:

• well defined;
• repetitive;
• relatively low consequence;
• based on a small or bounded context; and
• easy to validate automatically.

Typical examples in my workflow include Markdown formatting, extraction, classification, simple document transformations and some bounded coding tasks.

The important limitation is context depth. Luna may accept a very large context, but that does not mean that it can use that context as reliably as the larger models. The supporting benchmark material reports a substantial deep-context performance cliff, with Luna falling to 41.3% on a cited MRCR test compared with 91.5% for Sol.

The MangoMind comparison reaches the same practical conclusion: Luna performs particularly well on bounded, high-volume work, but should be avoided for deep-context retrieval, where it reports 41.3% on MRCR compared with 91.5% for Sol and 89.6% for Terra.

This distinction between context-window capacity and usable context is particularly important for specification-led development. Luna may be an excellent choice for editing one ADR while being a poor choice for reasoning across 50 pages of specifications and architectural decisions.

Luna also demonstrates why model tier and reasoning effort need to be treated separately. In the Valuemaxxing benchmark, Luna at x-high reasoning achieved 72 correct answers out of 72 on the benchmark workload at a lower observed cost than the perfect configurations of the larger models.

The lesson is not that Luna is always the best model. It is that a smaller model with more reasoning can sometimes be better value than immediately moving up a tier.

GPT-5.6 Terra

Terra is the middle tier. Current OpenAI pricing is $2 per million input tokens and $12 per million output tokens.

The articles generally position Terra as the practical default for mainstream professional workloads. It provides substantially stronger capability than Luna on demanding context-heavy tasks while remaining materially cheaper than Sol. One of the articles describes it as delivering GPT-5.5-class performance at half the price and recommends it for everyday coding, document analysis, knowledge retrieval and routine agentic workflows.

The MangoMind comparison similarly describes Terra as the practical centre of the lineup: within roughly 2–4 benchmark points of Sol on many tests while costing materially less.

That makes Terra particularly interesting for my workflow. A great deal of specification-led development sits between the extremes. The work is too context-sensitive or consequential to hand confidently to Luna, but not sufficiently difficult to justify Sol on every operation.

Terra is therefore a natural candidate for tasks such as:

• drafting and revising substantial specifications;
• working across a bounded set of ADRs;
• everyday coding;
• implementation planning;
• code review; and
• document analysis where context depth matters.

GPT-5.6 Sol

Sol is the flagship tier and the most expensive of the three GPT-5.6 models. Current OpenAI pricing is $4 per million input tokens and $20 per million output tokens.

Sol’s strongest results appear on difficult agentic work where planning, iteration, tool use and recovery from failure matter. The articles recommend it for complex multi-file coding, deep research, cybersecurity, difficult scientific reasoning and long-running multi-step workflows.

The MangoMind article reaches a similar conclusion, reserving Sol for the hardest tasks and situations where failure is expensive.

In my development workflow, I therefore want to reserve Sol for work where one or more of the following are true:

• complexity is genuinely high;
• very deep context must be understood reliably;
• the consequence of an error is high;
• several architectural concerns must be reconciled at once; or
• cheaper model configurations have already proved inadequate.

Architectural decisions and repository-wide architectural analysis are obvious examples.

The crucial point is that Sol being the most capable GPT-5.6 model does not make it the correct model for every task. If Luna or Terra meets the required quality threshold, using Sol consumes scarce capacity without delivering corresponding value.

Reasoning Effort Changes the Picture

The model tier is only half of the configuration. Each GPT-5.6 tier supports six reasoning levels: none, low, medium, high, x-high and max.

The Valuemaxxing benchmark demonstrates that reasoning effort can have a large effect on both quality and cost. In its particular six-task workload, Luna moved from 60/72 correct at low reasoning to 72/72 at x-high.

However, the same paper also found that higher reasoning did not consistently produce higher accuracy across all models and tasks. The practical lesson is that more reasoning should not automatically be equated with better output.

This matters particularly to me because reasoning tokens consume the same limited usage allowance as useful visible output. In the Valuemaxxing benchmark’s particular workload, hidden reasoning accounted for 95% of output-token consumption. That figure should not be treated as a universal ratio for every reasoning task, but it illustrates how dramatically hidden reasoning can dominate consumption.

A model may return a three-line edit after doing a very large amount of hidden work to produce it.

What About Claude?

Anthropic’s Claude models are an important part of the broader frontier-model landscape. Claude may be the better model for particular workloads, but it is generally more expensive in the comparisons covered by these articles.

I do not currently use Claude in my application-development workflow, so I do not attempt to optimize routing between OpenAI and Anthropic models in this article.

The Practical Starting Position

The three GPT-5.6 tiers suggest a useful initial hypothesis:

Luna — bounded, repetitive, inexpensive work
Terra — mainstream development work requiring reliable comprehension
Sol — difficult, deep-context or high-consequence work

But this should only be a starting point.

The Valuemaxxing evidence shows that the combination matters:

Model tier & reasoning effort

A high-reasoning Luna configuration may outperform a low-reasoning larger model economically on some tasks, while Luna’s deep-context weakness means that no sensible increase in reasoning should be assumed to make it equivalent to Terra or Sol on every workload.

The objective is therefore not to classify each use case permanently as a Luna, Terra or Sol job. It is to find the configuration that works for each task profile.

Pragmatic Model Choices

The framework above makes model selection explicit, but there is a practical limit to how much attention I want to give it while I am actually developing software.

With three GPT-5.6 model tiers and six reasoning levels, there are already 18 possible model-and-reasoning combinations. In theory I could assess the complexity, context depth and consequence of every task and then select an individually optimized configuration. In practice that would become a task in itself.

A developer needs to get on with the work.

I therefore want a small number of pragmatic defaults that capture most of the available benefit without requiring me to make a model-routing decision every few minutes.

Some choices are already very clear.

Luna Low for Mechanical Work

Mechanical work does not need expensive reasoning. Tasks such as:

• Git commits and routine repository operations;
• simple file refactoring;
• Markdown formatting and linting;
• straightforward text transformations;
• renaming or moving files; and
• other bounded, easily validated changes

are generally low in complexity, context depth and consequence.

For these tasks I use Luna Low.

In VS Code, Luna Low is therefore my default model configuration. Most development interactions start there. This matters because these small tasks occur frequently, and using a more expensive configuration for each of them would steadily consume the limited allowance I want available for more valuable work.

Luna High for Substantial Everyday Work

One of the most useful discoveries from actually working this way is how capable Luna High (or xHigh) can be.

For tasks that require more thought but remain reasonably bounded, Luna High has produced good results for me while remaining extremely fast.

Speed matters more than I initially expected.

Model economics are usually discussed in terms of tokens and dollars, but developer time is also part of the cost. A model that gives me an adequate answer quickly means less time staring at the screen waiting for the agent to finish — or, in my case, finding another YouTube video about AI development to watch while it thinks.

For my current workflow, Luna High therefore occupies a very useful position: substantially more reasoning than my Luna Low default, without automatically moving to a more expensive model tier.

Why I Currently Make Little Use of Terra

The published guidance often presents Terra as the natural general-purpose default between Luna and Sol. That is entirely reasonable as a broad recommendation.

For my own workload, however, I currently see less reason to use it.

My practical choices tend to divide more naturally into two groups:

• work that Luna can perform adequately, where I can choose Low or High reasoning according to the task; and
• work sufficiently complex, context-heavy or consequential that I would rather move directly to Sol.

This may change as I gain more experience, but today Terra risks occupying a middle ground that I do not often need.

Sol High for the Work That Matters Most

For genuinely difficult architectural work, the calculation changes.

An architectural decision, a major specification choice or a cross-project consistency review has a high consequence if it is wrong. These are also exactly the tasks for which I want the strongest reasoning and the most reliable use of project context.

For those tasks, my current preference is Sol High.

There is little benefit in saving tokens on the initial architectural decision if an incorrect decision subsequently propagates into specifications, infrastructure, code and tests.

The constraint is that Sol High can consume my allowance quickly. Its use needs to be deliberate and proportionate to the value of the task. If I run out of daily allowance I can buy top-up credits and I have found that $10 is enough to complete most tasks.

My Current Working Set

As of September 2026, my practical model-selection strategy is therefore much simpler than the full matrix of possible configurations suggests.

This is not intended as a universal recommendation. It is my current operating point. It deliberately sacrifices theoretical optimization for operational simplicity. Instead of repeatedly choosing among 18 possible GPT-5.6 configurations, I can work with three familiar settings and concentrate on the work.

The remaining discipline is to watch my usage during the day so that I get a feel for how well I am creating tasks for the agent because better tasks cost less.

Creating optimum tasks

Model selection is only part of ValueMaxxing. A developer also has considerable control over the shape of the task presented to the agent.

The time, cost and quality of an agent’s output depend strongly on the task’s characteristics. This suggests an important principle:

Do not just choose a cheaper model for the task. Structure the task so that a cheaper model can perform it reliably.

The developer should therefore try to minimize three things wherever practical:

• Context depth — give the agent only the information it needs.
• Complexity — break difficult work into smaller, more explicit decisions.
• Consequence — avoid combining unrelated or far-reaching changes into a single operation.

Reducing these dimensions makes the task easier to reason about, cheaper to execute, quicker to complete and easier to validate.

Minimize Context

Context is the information available to the agent when it performs a task: the conversation so far, files, specifications, code and other material supplied to it.

More context is not automatically better.

This is particularly important when using Luna. Luna has a large nominal context window, but its deep-context performance deteriorates substantially compared with Terra and Sol. Keeping tasks bounded therefore makes it possible to use Luna with greater confidence.

A task such as:

Update this ADR to reflect the decision we have just made.

is potentially much cheaper than:

Read the entire project and determine what needs changing as a result of this decision.

The second instruction transfers a substantial discovery and reasoning problem to the agent. The first gives it a bounded task and the relevant context.

The objective should therefore be to provide sufficient context, not maximum context.

Minimize Required Reasoning

Reasoning is expensive.

In the Valuemaxxing benchmark’s particular workload, reasoning represented 95.3% of output-token consumption. That is not a universal ratio, but it demonstrates how dramatically hidden reasoning can dominate the amount of output-token capacity consumed.

A developer can therefore save considerable model capacity by reducing how much reasoning the agent has to perform.

This does not simply mean selecting a lower reasoning setting. The more important tactic is to make the task itself require less reasoning.

Instead of asking an agent to consider several possible approaches, infer requirements and then decide what to build, I can make those decisions explicitly and give the agent a narrower implementation task.

There is also an important counter-intuitive result from the model benchmarks: more reasoning does not necessarily produce better quality on every task. In some tested configurations, increasing reasoning effort produced no improvement or even reduced measured accuracy. This is workload-dependent rather than a general rule about high reasoning.

For simple, well-defined work, low reasoning may therefore be better on all three dimensions:

• faster;
• cheaper; and
• potentially more reliable.

One Thread for One Work Package

In VS Code Codex, I normally use a chat thread to deliver a single bounded work package.

A work package might be:

• create an ADR;
• revise a specification;
• implement a small feature;
• refactor a bounded area of the repository; or
• diagnose and correct a particular problem.

A thread contains a series of turns between me and the agent. The objective is not necessarily to complete the whole work package in one enormous prompt.

Quite the opposite.

Breaking the work into several turns lets me progressively constrain the problem. I can review intermediate results, make decisions and give the agent additional information only when it becomes relevant.

This can reduce both context and reasoning compared with asking the model to infer and execute the entire work package autonomously in one step.

A typical pattern is:

understand → plan → decide → implement → review → commit

The work package may create several artefacts, and in my specification-led workflow those artefacts are often documentation rather than code.

Keep Threads Short Enough

The advantage of a thread is continuity, but continuity eventually becomes a cost.

Each turn adds material to the conversation context. As the thread grows, the model has more history to process and more potentially irrelevant information through which to reason.

In my experience, roughly five to eight substantive turns is a useful working range for many work packages. This is not a hard technical limit, but it is a practical discipline.

If a thread is becoming long, that is often a signal that one of three things has happened:

• the work package was too large;
• a new work package has emerged; or
• enough useful state now exists to create a handover and start again with a cleaner context.

The aim is to preserve useful continuity without allowing the accumulated conversation to become the problem.

Plan Before Implementing

One of the most valuable tactics I use is the agent’s /plan capability.

Planning forces important decisions and assumptions into the open before implementation begins.

This has two benefits.

First, it reduces reasoning cost during implementation. If the agent already knows which approach I want, it does not need to repeatedly evaluate several alternative paths while doing the work.

Second, and more importantly, planning improves quality because it exposes assumptions.

An autonomous agent faced with an ambiguous requirement must make assumptions in order to proceed. Those assumptions may be perfectly reasonable and still be different from the decision I would have made. The resulting implementation can therefore be internally coherent but wrong for the project.

A planning conversation turns hidden assumptions into explicit questions.

I can answer:

• use DynamoDB rather than Aurora;
• extend the existing API rather than create another endpoint;
• modify the existing ADR rather than create a new one;
• preserve backwards compatibility;
• do not introduce another dependency.

Once those decisions are explicit, the implementation problem becomes substantially simpler.

For me, this is perhaps the strongest reason to plan: planning moves architectural judgement from implicit agent reasoning into explicit developer decisions.

Use Multiple Planning and Execution Turns

A plan does not imply that the remainder of the work package must happen in one turn.

A substantial thread might contain:

1. an initial request;
2. a planning session;
3. clarification of important decisions;
4. implementation of one part;
5. review of the result;
6. a second small plan for an issue discovered during implementation;
7. final implementation; and
8. commit.

This iterative approach lets the agent solve a sequence of smaller problems rather than one large problem.

That is beneficial to both cost and quality.

Change Reasoning Level Within the Thread

The reasoning requirement can also change during a work package.

There is no reason that every turn must consume the same amount of reasoning.

For example, I might use:

Luna High → plan the work

followed by:

Luna Low → implement the agreed plan

Once the difficult choices have been made, implementation may become substantially more mechanical.

This is particularly useful for specification-led work. Deciding what an ADR should say may require significant reasoning; applying the agreed amendments to several Markdown files may not.

I also use Luna Low for commits, because creating a well-defined Git commit from completed work is a bounded mechanical task.

I avoid changing the underlying model unnecessarily within an established thread. Changing the reasoning level, however, gives me a useful way to match compute to individual turns without discarding the useful context already established.

Use Handover Documents to Reset Context

Eventually a thread should end.

When a work package has been completed, when the context has become too large, or when I want to escalate the next stage of the work to a more capable model, I ask the agent to create a handover.

A handover is a compact description of the state required by the next thread. It might include:

• the objective;
• important decisions already made;
• relevant files;
• artefacts created or modified;
• constraints that must continue to hold;
• unresolved questions; and
• the next recommended action.

I then start a new thread using the handover rather than carrying the complete conversation history forward.

This is effectively context compression under developer control.

It has several benefits. The next agent does not need to process every exploratory conversation, rejected idea and intermediate correction from the previous thread. It receives the decisions and state that matter.

A handover is especially useful when escalating models. Rather than bringing a long Luna conversation into a Sol task, I can give Sol a clean, deliberately constructed description of the problem that actually requires its capability.

A Practical Thread Pattern

Taken together, these tactics produce a working pattern something like this:

Start a bounded work package

↓

Open a new thread with the minimum useful context

↓

Use /plan to expose assumptions and make key decisions

↓

Use higher reasoning where decisions require it

↓

Use lower reasoning for mechanical implementation

↓

Review and validate incrementally

↓

Commit using Luna Low

↓

Create a handover when the work package ends, the thread grows too large, or escalation is required

↓

Start the next thread with the compressed handover

The important point is that ValueMaxxing is not just model routing.

A well-structured task can be more valuable than a more capable model. By actively reducing context, complexity and consequence, the developer changes the economics of the task itself and makes faster, cheaper models viable for a much larger proportion of the development workflow.

Continuous Re-evaluation

None of these routing decisions should be permanent.

Models improve, prices and usage allowances change, and my own development workload evolves. A task that requires a high-capability model today may be handled perfectly well by a cheaper model tomorrow.

ValueMaxxing is therefore a continuing process:

classify → route → measure → learn → re-route

The goal is not to discover the single best AI model. It is to ensure that each part of the development workflow receives enough AI capability, but no more than it needs.

/Status

You can gain a better understanding of the current thread’s resource usage by using the CODEX /Status command that displays this widget. You can keep it on screen as you work.