Test 1 project on 3 models.
See which model helps with your actual work by giving three of them the same project and examining what they produce.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Run a comparable project on three models and assess the actual outputs against your needs, including the effort needed to make them useful.
What to have ready
- A project, task, or rough description; available source files and connected discussions help define it.
Where you come in
- Agree on the task and success criteria, resolve useful choices, and bridge access to models when necessary.
What you'll get
You have a comparison of three actual model runs, their outputs, and a task-specific recommendation—or an explicit partial comparison identifying any missing runs.
You're done when
You have a comparison of three actual model runs, their outputs, and a task-specific recommendation—or an explicit partial comparison identifying any missing runs.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Test one real project on three different models and help me decide which is most useful for this work. ### 1. Define a fair, useful project test. Start with the project or task I supplied. Use relevant available project files, documents, email, messages and chats, and meeting transcripts to establish its purpose, audience, source material, and constraints. If the project is too broad for a useful comparison, propose a bounded deliverable that still exercises the capability I care about. Ask focused questions where the answers would change the test. Offer two concrete scopes when helpful, such as a complete short analysis or one difficult section of a larger report. Agree on the task and what success means before running the comparison. Define observable criteria: accuracy against the sources, completeness, useful reasoning, the quality of the actual artifact, or how much repair I would need. Choose criteria that fit this project rather than an elaborate generic scorecard. ### 2. Select three models and prepare equivalent inputs. Inspect which distinct models and interfaces are actually accessible. Confirm model identities from available tool information or the interface; do not count three sessions with one model as three models. If choice of model depends on current availability or capabilities, check current primary documentation instead of relying on memory. Record the actual model/version label where available, interface, date, and relevant settings. - Build one self-contained brief with the task, constraints, expected deliverable, and necessary source material. - Give each model equivalent readable inputs and an independent starting context; do not pass one model’s output to another during the comparison. - Check that attachments and links are actually accessible to each. - If capabilities differ, decide whether to use a common supported setup or compare the available environments as they are, explaining how that affects interpretation. When direct model access is unavailable, prepare the exact briefs and files for me to carry into the appropriate tools, with concise instructions for returning the complete outputs and recording model identity. Do the preparation yourself. Wait for actual results rather than inventing a model’s response. Continue useful preparation for the other runs while access is being resolved. ### 3. Run and inspect the work. Run the same task separately on each accessible model. If the task writes files, use separate output locations or copies so runs do not overwrite one another. Preserve the original outputs, errors, and substantive clarification exchanges. Give materially relevant answers or corrections equivalently to the other runs where needed, recording what differed. Record elapsed time, usage, or cost only when actually available and comparable. Do not infer a price or speed measure from an impression. Distinguish the first output from any iteration, and keep the amount of help and repair visible. If a model cannot complete the task, record the actual failure rather than replacing it silently with a different task. ### 4. Compare against the evidence and my needs. Inspect the outputs themselves, including opening generated files, checking source claims or calculations, and trying relevant artifact interactions where supported. Apply the agreed criteria consistently. Use concrete examples of strengths and weaknesses rather than treating fluent writing or a model’s self-assessment as proof of quality. Estimate practical repair effort from observed issues or actual revisions, clearly distinguishing the two. Ask me to resolve a preference tradeoff if it would change the recommendation, and offer alternatives where useful—for example, one model for the first draft and another for a different kind of task. Keep any combined workflow recommendation separate from the original three independent runs. ### 5. Deliver a bounded conclusion. Provide the actual outputs, a concise comparison with supporting examples, and a recommendation tied to this project and setup. Explain consequential differences in tools, inputs, settings, or assistance. One task does not establish a universal ranking of models. If fewer than three real runs are available, deliver the useful partial findings and ready-to-run remaining briefs, explicitly identifying what is missing. Do not claim the three-model activity is complete until three distinct model runs have been obtained and assessed. Incorporate my corrections and finish with the evidence I can use to choose for this work. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Test 1 project on 3 models.
What the AI will do
- Run a comparable project on three models and assess the actual outputs against your needs, including the effort needed to make them useful.
What you can provide
- A project, task, or rough description; available source files and connected discussions help define it.
Where you'll take part
- Agree on the task and success criteria, resolve useful choices, and bridge access to models when necessary.
What you'll get
You have a comparison of three actual model runs, their outputs, and a task-specific recommendation—or an explicit partial comparison identifying any missing runs.
Activity context
See which model helps with your actual work by giving three of them the same project and examining what they produce.
For the user
Choose a real, bounded project or let the AI help define one from your work. It will assemble a common brief and comparison criteria, then run the models it can access. You may need to carry prepared briefs and results between tools when direct access is unavailable.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Test one real project on three different models and help me decide which is most useful for this work.
1. Define a fair, useful project test.
Start with the project or task I supplied. Use relevant available project files, documents, email, messages and chats, and meeting transcripts to establish its purpose, audience, source material, and constraints. If the project is too broad for a useful comparison, propose a bounded deliverable that still exercises the capability I care about.
Ask focused questions where the answers would change the test. Offer two concrete scopes when helpful, such as a complete short analysis or one difficult section of a larger report. Agree on the task and what success means before running the comparison. Define observable criteria: accuracy against the sources, completeness, useful reasoning, the quality of the actual artifact, or how much repair I would need. Choose criteria that fit this project rather than an elaborate generic scorecard.
2. Select three models and prepare equivalent inputs.
Inspect which distinct models and interfaces are actually accessible. Confirm model identities from available tool information or the interface; do not count three sessions with one model as three models. If choice of model depends on current availability or capabilities, check current primary documentation instead of relying on memory. Record the actual model/version label where available, interface, date, and relevant settings.
- Build one self-contained brief with the task, constraints, expected deliverable, and necessary source material.
- Give each model equivalent readable inputs and an independent starting context; do not pass one model’s output to another during the comparison.
- Check that attachments and links are actually accessible to each.
- If capabilities differ, decide whether to use a common supported setup or compare the available environments as they are, explaining how that affects interpretation.
When direct model access is unavailable, prepare the exact briefs and files for me to carry into the appropriate tools, with concise instructions for returning the complete outputs and recording model identity. Do the preparation yourself. Wait for actual results rather than inventing a model’s response. Continue useful preparation for the other runs while access is being resolved.
3. Run and inspect the work.
Run the same task separately on each accessible model. If the task writes files, use separate output locations or copies so runs do not overwrite one another. Preserve the original outputs, errors, and substantive clarification exchanges. Give materially relevant answers or corrections equivalently to the other runs where needed, recording what differed.
Record elapsed time, usage, or cost only when actually available and comparable. Do not infer a price or speed measure from an impression. Distinguish the first output from any iteration, and keep the amount of help and repair visible. If a model cannot complete the task, record the actual failure rather than replacing it silently with a different task.
4. Compare against the evidence and my needs.
Inspect the outputs themselves, including opening generated files, checking source claims or calculations, and trying relevant artifact interactions where supported. Apply the agreed criteria consistently. Use concrete examples of strengths and weaknesses rather than treating fluent writing or a model’s self-assessment as proof of quality.
Estimate practical repair effort from observed issues or actual revisions, clearly distinguishing the two. Ask me to resolve a preference tradeoff if it would change the recommendation, and offer alternatives where useful—for example, one model for the first draft and another for a different kind of task. Keep any combined workflow recommendation separate from the original three independent runs.
5. Deliver a bounded conclusion.
Provide the actual outputs, a concise comparison with supporting examples, and a recommendation tied to this project and setup. Explain consequential differences in tools, inputs, settings, or assistance. One task does not establish a universal ranking of models.
If fewer than three real runs are available, deliver the useful partial findings and ready-to-run remaining briefs, explicitly identifying what is missing. Do not claim the three-model activity is complete until three distinct model runs have been obtained and assessed. Incorporate my corrections and finish with the evidence I can use to choose for this work.
Done when
You have a comparison of three actual model runs, their outputs, and a task-specific recommendation—or an explicit partial comparison identifying any missing runs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.