This video explains the command you'll use in the lab to prompt models from the shell. We'll walk through it on Claude Code first, and at the end we'll show the equivalent command for Codex.
Here is the way you have been running Claude Code until now. You type claude, a session opens, you ask it a question, you get an answer, and the prompt is waiting for your next turn. The session carries the conversation and tool results forward as context for the next turn.
There is a second way to run it. Add the flag dash p, and put the prompt right there on the command line. Claude Code handles the request, prints the answer, and exits to your shell. You do not enter the interactive prompt. We call this one-shot mode.
Without a continue or resume option, each call starts a new conversation. In an interactive session, a follow-up question can refer back to an earlier one. In a fresh one-shot call, that earlier question is absent. The model might still answer the follow-up, but it has to do so without knowing what the earlier interaction was.
One shot describes your side of the exchange. The harness can still run the agent loop several times, handling tool calls before printing the final answer. One prompt does not mean one model request.
The prompt does not have to be a quoted argument on the command line. It can arrive on standard input instead. Here echo writes the prompt, and the pipe passes it to claude dash p. This supplies the same prompt as the quoted argument.
Standard input is useful for a prompt stored in a file or produced by another program. You can pass the contents directly instead of putting the whole prompt inside a shell command. When using a variable, keep it quoted, as in the example.
Here the prompt sits in a shell variable, and a loop sends it five times, starting a fresh conversation each time. The mutex question is just an example of the command syntax. Because the model samples its output, identical prompts can produce different answers. Repeated runs tell us how often an answer is correct under the same conditions.
This bar shows the context window. That is everything the model receives in one request. By default, one-shot mode still adds the harness's own pieces. These are its instructions, its tool definitions, and any instruction files that apply. Your prompt is only a small part of what the model receives. To compare models and prompts in the lab, we need to control what the harness adds. Three settings take these pieces out, one at a time.
The first setting is dash dash system-prompt. It replaces the harness's own instructions with a string you supply. The usual instructions describe how to work as a coding agent. Here we replace them with one short instruction: you are a helpful assistant.
The second setting is dash dash tools. It lists the built-in tools the model may use. Give it an empty string, and no built-in tool is available. Disable any external M-C-P tools too. With tool access disabled, the model cannot use the harness to read a file or run code. It has to generate its answer from the supplied context and what it learned during training.
The third setting is the folder you run in. If you use an empty directory, no project instruction file loads. Parent and user instructions and saved memories can still be present. So check what your setup loads, and keep it the same across conditions in case you experiment using this approach.
The model flag chooses which model receives the prompt. The lab starts with Haiku, the fast, lower-cost option in the group shown here.
The other two options shown are Sonnet and Opus. They offer different balances of capability, speed, and cost. Haiku is aimed at faster, less expensive work, while Opus is aimed at harder tasks.
The dash dash model flag, set to haiku, sends this call to Haiku. To compare with Sonnet or Opus, change that value and send the same prompts. Record which model version handled each set of runs.
The lab asks whether having the model write out its thoughts and work step by step changes how often it answers correctly. To interpret that comparison, we need to distinguish steps in the visible response from separate thinking tokens. A reasoning model can generate thinking tokens before its final answer. Those tokens are separate from the answer you normally read.
Thinking tokens are generated through the same next-token process as the answer, with each token using the preceding context. This gives the model space to try an approach and check intermediate results before answering. That can help on difficult problems, but it also takes time and computation to generate these extra tokens.
There are two related controls. Effort sets how much reasoning to request. In a session you type slash effort, and on the command line you add the effort flag. It is not an exact token count. On models with a fixed thinking budget, MAX underscore THINKING underscore TOKENS sets that budget numerically. The lab uses zero to disable separate thinking.
With separate thinking disabled, generation starts with the visible response rather than a separate thinking section. The model still has its training and still generates one token at a time. It can also write intermediate steps in the visible response if you ask it to.
In this pipeline, an assignment before a command sets an environment variable for that command. Put it on the side of the pipe where it is needed. In this line it sits after the pipe and right before the word claude, so it is claude that gets it.
Move the assignment before echo, and it applies to echo. The claude process does not receive that assignment, so it uses whatever thinking setting it otherwise had. If a comparison looks surprising, check that the setting reached the process you meant to test.
This is the starting command in the Lab 2 handout, with the settings we've just explained. Set the PROMPT variable to whichever prompt you need, then run it from the empty directory you prepared.
Change one thing at a time. For example, to test whether asking for working helps, keep the model and problem fixed and change only that instruction in your prompt. Keep tools and separate thinking disabled throughout the lab, and keep the system prompt and loaded memory the same.
Repeat each input multiple times under each setting, with a fresh conversation every time, and record how often the answer is correct. Use your agent to build a test program around this command. Decide how to check answers before running it, then inspect a few responses to make sure the program scores them correctly.
If you installed Codex rather than Claude Code, the handout has the same command for it. Here it is, with every switch already set. Codex exec is its one-shot mode, and the rest of the line selects the model, turns separate thinking off, replaces the default instructions, and disables the tools. You do not need to memorize these switches. The handout has the command ready to copy, and it explains what each switch does.
On the Codex side, the models you can select are Sol, Terra and Luna, and also Astra. There is one difference to keep in mind. Astra has no setting that turns thinking off. Its lowest effort is low, so it always thinks a little. If you test it, say so in your report. You now have a way to turn your questions about the model into experiments. Your test program can collect the answers, and you can use the results to find out which changes help on your chosen problem.