Thinking Levels

MaxLabs lets you control how much reasoning effort a model can spend before and during a task.

Five thinking levels are available:

• Minimal
• Low
• Medium
• High
• Auto

These levels are available across the MaxLabs API, desktop applications, and CLI.

Thinking level does not select a different model.

If you are using Worker, you are still using Worker. If you are using Pro, you are still using Pro.

Instead, thinking level controls how much computational effort the selected model can spend reasoning through the current problem.

This gives you two separate controls:

Control	Determines
Model	The underlying reasoning and coding capability
Thinking level	How much computational effort the model can spend on the task

You can use Worker with High thinking.

You can use Pro with Minimal thinking.

The right combination depends on the problem.

Choosing a Thinking Level

For most tasks, use this as a starting point:

Level	Typical Use
Minimal	Mechanical edits and exact instructions
Low	Straightforward development work
Medium	Normal feature development and debugging
High	Difficult investigation, architecture, and complex debugging
Auto	Sessions where task complexity changes frequently

If you are unsure which fixed level to use, Medium is usually a sensible default.

Minimal

Minimal performs little or no additional reasoning before acting.

Use it when the required change is obvious and there is little value in investigating alternatives.

Examples include:

• Renaming variables
• Adjusting copy
• Changing configuration values
• Small CSS changes
• Correcting simple syntax problems
• Generating predictable boilerplate
• Modifying a known file in a clearly defined way

For example:

Change the pagination limit from 25 to 50.

Minimal is also useful when your prompt already contains a complete implementation plan.

Low

Low provides a small reasoning budget.

It works well when the model needs to inspect some context and make a few decisions, but the overall path remains clear.

Typical tasks include:

• Normal bug fixes
• Extending an existing CRUD module
• Adding simple validation
• Adding another endpoint using an existing pattern
• Adding tests to an established feature
• Small refactors
• Straightforward integrations

Medium

Medium is a strong default for ordinary software development.

It gives the model enough reasoning capacity to inspect the repository, understand relevant patterns, formulate an approach, and revise that approach when necessary.

Medium is suitable for:

• Feature development
• Multi-file changes
• Integrations
• Repository-aware debugging
• Refactoring
• Moderate planning
• API development
• Frontend and backend changes together

High

High gives the model substantially more opportunity to reason before and during execution.

Use it when getting the decision right matters more than receiving the fastest possible response.

High is particularly useful for:

• Difficult debugging
• Complex feature development
• Architectural changes
• Unfamiliar repositories
• Concurrency problems
• Migrations
• Security-sensitive changes
• Cross-module reasoning
• Complicated integrations
• Tasks with several plausible solutions

Higher thinking does not guarantee a correct answer. It gives the model more opportunity to reach one.

Auto

Auto allows MaxLabs to adjust reasoning effort dynamically as the task develops.

This is useful when a session contains a mixture of simple and difficult work.

Auto does not simply classify the initial prompt once. A task that initially looks simple may become more complex after repository inspection.

Signals may include:

• Request complexity
• Repository exploration required
• Uncertainty between possible solutions
• Failures encountered during execution
• Number of interacting components
• Assumptions that need revision
• Complexity revealed by tools or tests

The exact implementation of Auto may evolve as MaxLabs improves its models and agent infrastructure.

Thinking Is Not the Same as Model Capability

Increasing the thinking level does not turn Worker into Pro.

Likewise, reducing the thinking level does not turn Pro into Worker.

The underlying model remains unchanged.

A Worker task at High may perform better than Worker at Minimal on a difficult repository problem because the same model has more opportunity to investigate.

However, Pro still has the greater underlying reasoning capability of Pro.

Configuration	Typical Use
Worker + Minimal	Very simple edits and mechanical tasks
Worker + Low	Straightforward day-to-day changes
Worker + Medium	Normal feature development
Worker + High	Complex features or difficult debugging
Pro + Medium	Difficult analysis where latency and compute still matter
Pro + High	Deep debugging, architecture, and complex investigation

Worker and Thinking Levels

A practical starting point is:

Task	Suggested Level
Exact mechanical edit	Minimal
Small straightforward fix	Low
Normal feature development	Medium
Complex multi-component feature	Medium or High
Difficult debugging	High
Mixed interactive session	Auto

Worker + Medium is a good general-purpose configuration.

Pro and Thinking Levels

Because Pro already provides greater underlying reasoning capability, you do not necessarily need High for every Pro task.

Task	Suggested Level
Relatively clear Pro task	Low or Medium
Architecture analysis	Medium or High
Large legacy-system investigation	High
Difficult root-cause analysis	High
Mixed exploratory session	Auto

What Higher Thinking Actually Changes

Higher thinking gives the model additional computational room to work through a problem internally.

The model may use additional reasoning to:

• Evaluate several possible explanations
• Compare implementation approaches
• Trace dependencies
• Revisit an assumption after inspecting new code
• Check whether a change conflicts with another subsystem
• Consider edge cases
• Analyse failures returned by tools
• Determine what information it still needs
• Decide whether additional repository exploration is justified

Higher thinking works best when the model can combine reasoning with authoritative evidence from the environment, including repository inspection, tests, compiler output, type checking, logs, and tool results.

More Thinking Is Not Always Better

Reasoning has a cost.

Higher thinking generally means some combination of:

• More compute
• Higher latency
• Greater token consumption
• More time before visible progress
• Potentially higher API cost depending on your plan

Models can also overthink.

Excessive reasoning can lead to:

• Over-engineering
• Unnecessary abstractions
• Modifying more files than required
• Solving adjacent problems
• Reconsidering already-settled decisions
• Expanding beyond the requested scope
• Higher latency without a better result

When this happens, reduce the thinking level or constrain the task explicitly:

Keep the implementation minimal. Do not refactor unrelated code.

Thinking and Context

Thinking also consumes part of the model's working capacity.

Depending on the task, the context window may contain:

• Your instructions
• Conversation history
• Repository contents
• Retrieved files
• Tool results
• Logs
• Test output
• Generated reasoning
• Final responses

Higher reasoning effort can generate more intermediate tokens, so extremely context-heavy tasks combined with extensive reasoning can increase context pressure.

This does not mean selecting High changes the model into one with a smaller advertised context window.

Context capacity is the model's total working limit.

Context usage is how much of that limit the current task consumes.

Higher thinking primarily affects context usage.

MaxLabs' coding harness actively manages working context by retrieving files when needed, retaining high-value information, discarding irrelevant tool output, summarizing previous work, and re-reading authoritative files where appropriate.

Repository Quality Affects Required Thinking

A conventional Laravel application may expose predictable routing, models, migrations, policies, services, and tests.

Worker may complete substantial feature work at Medium because the repository answers many architectural questions directly.

A small custom legacy system may require High simply to determine where a particular behaviour originates.

This is why thinking level should not be chosen based on task size alone.

Current CLI Behaviour With Auto

As of October 2026, we have observed an issue where Worker can occasionally enter an excessively long reasoning cycle when Auto is selected in the CLI.

Instead of concluding that it has gathered enough information and moving forward, Worker may continue reasoning or investigating without making useful progress.

A fix is planned for the next CLI release.

Until then, if you encounter this behaviour, switch from Auto to a fixed level such as Medium or High.

A Practical Rule

The goal is not to make the model think as much as possible.

The goal is to give it enough reasoning capacity to make a good decision without spending compute where it adds little value.

Simple task → less thinking

Uncertain task → more thinking

Use Minimal when the answer is effectively known.

Use Low when the task requires only a small amount of reasoning.

Use Medium for ordinary software development.

Use High when investigation and decision quality matter more than speed.

Use Auto when you want MaxLabs to adjust reasoning effort as the task evolves.

More reasoning should earn its cost.