Choosing an AI assistant and model in Maestro

Understand assistants, models and agents, compare two options on a small task, and prepare a switch without losing your project decisions.

When you open Maestro, you may see the name of an agent, an assistant and a model. It is tempting to start by asking which is best. Yet these three choices answer different questions. Understanding them helps you begin with access you already have, then switch models for a specific reason.

Consider a fictional example: Léa runs a small repair workshop. She wants to build a tool to track items, quotes and collections. She does not need to compare the entire AI industry. She needs to choose an option that helps her define a rule, build a screen and check the result without losing track of decisions.

Agent, assistant and model: three different roles

In Maestro, an agent represents a role in the work: clarifying the need, defining the product, designing screens, developing or checking. That role provides a mission and a framework. When Léa discusses the information needed to accept an item, she is defining requirements, even if the model could also write code.

The assistant is the software that carries out work using AI. Claude Code, Codex, Cursor and Mistral Vibe are the four assistants publicly listed as compatible with Maestro. The model is the reasoning and generation engine the assistant uses. One assistant may offer several models.

This distinction clears up a common misunderstanding: Maestro’s nine agents do not mean nine separate subscriptions. They are roles organized within the product. Usage conditions depend on the assistant, account and plan you use. Assigning a task to a different role does not automatically mean changing providers.

What to check across the four assistants

Compatibility with Maestro does not mean every feature of an assistant is reproduced inside Maestro. A tool may also exist as an editor, extension, application or online service. For your project, check the connected account and the options actually available in your version of Maestro.

Claude Code and Codex

Claude Code offers model families and versions with varying availability. Its model documentation distinguishes family names from specific versions. Record the selection displayed during a trial: a family name alone does not permanently identify a version.

Codex supports ChatGPT sign-in or an API key, with different billing arrangements, as its authentication documentation explains. Identify the active connection before comparing usage. Owning a subscription does not, by itself, prove the session is using it.

Cursor and Mistral Vibe

Cursor also provides a command-line assistant that can work on files. This helps explain why Maestro can use Cursor without requiring you to work in its editor. It does not mean every Cursor editor feature becomes a Maestro feature.

Mistral Vibe configuration supports model selection and may include organization-managed settings. A missing or unavailable option does not necessarily indicate a problem with your project. Check account access and permitted configuration first.

These points explain differences in how the tools work; they are not quality rankings. None of these brands guarantees a correct business rule. For Léa, the useful evidence will be an item recorded correctly, a quote calculated as intended and a collection that preserves the history.

Start with an account you can already use

A sensible first choice is often the assistant you can already access under suitable conditions. Check sign-in, model access, organizational rules and billing before subscribing elsewhere. Switching is worthwhile when it addresses an observed difficulty or enables a useful trial.

In our example, Léa has an account she is allowed to use for the project. She starts with a description containing no real customer data. This lets her check whether the assistant responds, understands the request and produces something she can review. Real data will come later, after explicit preparation.

• Check the identity of the connected account and, where applicable, the selected organization.
• Identify whether usage draws on a subscription, credits or API billing.
• Confirm that the intended model is actually available to that account.
• Decide which information you authorize for the first trial.

Keeping a project on your computer and exchanging information with an AI provider are separate matters. Choosing Maestro for local work does not automatically make the assistant’s reasoning run offline. If you have particular confidentiality requirements, examine where the data goes and the provider’s terms before the trial.

Choose for a specific task

“Build my application” is too broad a request for comparing models. Break down what you need now: rewording a requirement, analyzing a complicated rule, changing a screen or investigating a problem. You can then judge the response against observable criteria.

In the fictional workshop, rewording “your item is ready” is a small edit. Defining what happens when an accepted quote changes involves several rules. Fixing a calculation used across multiple screens is a different task again. There is no need to apply the same model preference blindly to all three.

Before choosing, describe the task in a few words: a small edit, a document to review or a change affecting several rules. This classification gives you a reason to compare options. It is neither a model quality test nor a promise about the request’s final price.

A more capable model may help when several constraints must be reconciled. It does not replace a clear requirement. If Léa forgets to explain that an accepted quote must remain available after a change, no setting turns that unspoken intention into an established rule.

Automatic selection or a fixed model?

Check the options actually offered in your version of Maestro and by the connected assistant. If automatic mode is available, it avoids choosing an engine before every request. If you can select a fixed model, choose one your account can access. Availability may change.

Where available, automatic mode can provide a starting point while you explore the product. An identified model is more useful for comparing results. Record its name, the date and visible settings that may affect the work. This gives you a reference if behavior changes later.

Avoid changing the model, request and supporting documents all at once. If the response improves, you will not know which change helped. Start by clarifying the request. Then change one element at a time when you want to understand its effect.

Compare two options on a small exercise

Prepare an exercise small enough to check every answer. For Léa’s workshop, it concerns collecting an item: the customer gives a reference number, any remaining payment must be checked, and the collection date must be retained. The exercise uses invented names and data.

Before starting either trial, write down the expected outcome as a set of checks. The goal is not to prefer the most persuasive wording. It is to see which option addresses the same constraints, identifies missing information and avoids unnecessary changes to the rest of the workflow.

• Provide the same requirement, documents and starting state.
• Request the same deliverable, such as a detailed rule and cases to check.
• Keep the exercise within a scope you can review completely.
• Save each result before trying the other option.
• Record useful questions, mistakes and necessary corrections.

An expected outcome, not an impression

Léa expects an item to be marked as collected only after the agreed checks. She wants a record of any unpaid amount and a way to correct a collection entered by mistake. If a proposal misses that final case, she records the omission even if the writing sounds highly professional.

If the trial changes code, start from separate copies of the same state or ask someone qualified to prepare them. Two assistants working simultaneously in the same files would make the comparison hard to interpret. Comparing written proposals avoids that problem for an initial trial.

Measure the work left for you

Response time is immediately visible. The time needed to reach a correct result is less obvious. Count clarification, correction and checking. A quick answer that needs three revisions may be less convenient than a slower proposal usable after a short review.

Take an entirely fictional comparison: option A produces a proposal in two minutes, then needs ten minutes of correction. Option B takes five minutes, then four minutes of correction. A responds faster; B takes nine minutes overall rather than twelve. This illustrates a measurement method, not the performance of two products.

Add the outcome of your checks and whatever usage data is actually available in your records. Do not turn an unknown measurement into zero. If costs cannot be compared on the same basis, write “not comparable” and explain why. Our guide to understanding AI usage explains how to read those figures.

A small exercise cannot identify the best model for an entire project. It can support a limited decision: retain one option for clarifying rules, try another on a difficult fix, and review that choice when results change.

Switch models for an identifiable reason

Switching becomes useful when you can name the problem: the same constraints keep being missed despite a clear request, the model cannot handle the necessary material, or time and usage seem unsuitable for the work. First check whether the requirement and expected outcome are specific enough.

Switching after every disappointing answer can hide the real issue. If three models propose three different layouts for the same screen, Léa may need to decide which action matters most to her team. While that priority remains absent from the brief, switching produces variations without resolving the decision.

Equally, do not keep trying indefinitely when an approach stops making progress. Save the last correct version, describe what fails and prepare a short handover to another option. Set a specific question to resolve: for example, why a cancelled collection still appears in the statistics.

Prepare continuity before switching

A model choice should not erase project decisions. Before switching, gather the requirement, agreed rules, last usable version, checks already performed and remaining problem. These are more reliable than assuming the next assistant will automatically know everything.

Changing models within an assistant and changing assistants are different operations. The new software may not inherit the same conversations, permissions or connected services. Check what it actually receives. Project files may remain available without the full reasoning history transferring with them.

• Goal: allow collection after checking the remaining payment.
• Agreed decision: retain previous quotes and the collection date.
• Current state: the screen works with the planned fictional data.
• Open problem: cancelling a collection does not correct the statistics.
• Next action: explain the cause before proposing a targeted change.

This fictional handover takes only a few lines, but preserves the meaning of the work. Ask the new option to restate the next action and what must remain unchanged. Review that restatement before an important modification. It can expose a misunderstanding before it becomes a code change.

When a model is missing or stops responding

An unavailable option can have several causes: an expired sign-in, account-specific access, the assistant version, organizational settings or a provider incident. Start by recording the exact message and checking the account. Avoid changing the project to fix a service-access problem.

If a list looks outdated, check available updates and the assistant’s documentation. A name in a picker does not guarantee unlimited access. Execution and the resulting message provide additional information. Record the date of the problem to make any support request more useful.

Useful work may still be possible while waiting: review rules, prepare trial data or inspect a screenshot. If you use another option, follow the same handover process. Urgency does not remove the need to understand which account is working, what information it receives and how usage is billed.

A simple decision for your next trial

You do not need a universal ranking to make progress. Choose an accessible assistant, check its account, prepare a small task and define what success will look like. Start with an available setting you can identify, then observe the result and the revisions needed.

Use the non-technical requirements guide to prepare the first task. To organize the wider project, our guide to building an application without coding skills explains how to move from an idea to a version you can try and verify.

Maestro is available in an invitation-only beta for Mac, starting with macOS 13. The application is free during beta and AI usage remains separate; Windows is in development. You can explore the workflow and request an invitation with a specific need. Model selection can then serve that need, one task at a time.

Back to contents