Early coding agents revealed something surprisingly powerful: give an agent access to Bash, and it can do almost anything — from writing code and gathering context to managing complete Git workflows.
That insight helped fuel a broader movement toward CLI-first software. Command-line interfaces began to look like the standard way to make complex applications accessible to AI agents, giving rise to a familiar slogan:
CLI is all you need.
But there is a hidden cost. Agents often use a terminal much like a human would: run a short command, inspect the result, and then decide what to do next. As tasks become more complex, this creates more back-and-forth between the model and its tools, which means more LLM calls, more context wasted, and more time spent waiting.
Instead of asking agents to assemble complicated shell scripts, we would prefer them to coordinate tasks in a programming language they already understand. This leads to a slightly different architecture:
Keep the CLI as the universal entry point, but use code as the actual way to interact with the software.
The agent submits a block of code that contains the operations, decisions, and data processing that would otherwise be spread across several rounds of interaction. The local runtime then executes the workflow.
ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and orchestrate them.
In this article, we compare heredoc and REPL, two ways of executing code through a CLI, and share the experimental results from ego-browser. With heredoc, the agent finished the same tasks in 44% fewer execution rounds, with 35.5% fewer tool calls, at 21.6% lower cost.
“CLI is all you need” — then what?
The claim that “CLI is all you need” assumes the model already knows how to use that CLI.
For well-known tools such as Git, Docker, and FFmpeg, this is usually not a problem. Models have seen countless commands, tutorials, scripts, and error messages during training, and already know the arguments and how the commands fit together.
But when we build a brand-new CLI for agents, the picture changes. Every CLI has its own subcommands, arguments, output formats, and error semantics. To the model, it is essentially a new mini-language. Even with complete documentation, the model still has to learn the rules first, then figure out through repeated calls how the commands fit together.
Expose the same capabilities as a JavaScript API instead, or an API in any other language, and the model still has to learn the new domain concepts, but it no longer needs to relearn control flow, data structures, or composition. Loops, conditions, exception handling, and data processing all stay in a programming language it already knows.
Take a simple task: open a webpage and read its main heading. If ego-browser exposed a traditional command-style interface, the agent might need several steps to finish it:
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role headingAfter every step, the agent waits for the tool, reads the result, and decides what to do next.
The code interface ego-browser actually uses lets it express the entire workflow at once:
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);Both approaches get the same thing done. The command-style interface splits the process into multiple rounds of model–tool interaction; the code interface lets the agent write out the complete process once and hand it to the local runtime.
This is exactly the design idea mentioned earlier: keep the CLI as the universal entry point, but use code as the actual interface to the software. It keeps the CLI's advantage of being easy to call and integrate, while letting the model use the programming skills it already has for composition and orchestration.
When the CLI becomes a gateway to code
Once a CLI accepts code, the next question is how should the agent hand that code to the execution environment?
Strictly speaking, heredoc is shell input syntax and REPL is an interpreter's execution mode; the two are not at the same abstraction layer. What this article actually compares is one-shot code execution entered through a heredoc in ego-browser, versus a persistent interactive session built on a REPL. For brevity, we will just call them heredoc and REPL from here on.
One option is the heredoc. In ego-browser, the agent submits an entire block of JavaScript in one go:
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOFThe shell passes the code to ego-browser, waits for it to finish, receives the result, and exits. To the agent, this behaves like a conventional tool call:
Submit command → wait for process → receive resultA REPL works differently. The interpreter remains alive, allowing the agent to enter code repeatedly while retaining variables and session state:
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"In terms of expressive power, the two are essentially equivalent. A REPL can run a complete program with loops, conditions, and exception handling in one shot, and a heredoc can submit just a single line.
The clear difference is the process lifecycle. With a heredoc, the process exits as soon as the code finishes running; a REPL keeps the interpreter process alive, waiting for further input. This also means the two place different demands on agent tools. A heredoc runs directly on the familiar request–response model:
submit the command → wait for the process to exit → get the resultREPL asks more of the tool: persistent processes, session management, continuous input, interruption, and recovery. Most agents' built-in Bash tools do not have these capabilities. Among mainstream products today, only Codex supports them reasonably well. And tool support is only a necessary condition for using a REPL. It does not decide how the model will actually use one. Even when both environments can run the same code, the model may still write code differently in each.
How models write code in each environment
In theory, a model has the same programming ability in both environments. In practice, we observed a consistent behavioral difference:
- In a REPL, the model tends to enter code incrementally.
- In a heredoc, it is more likely to generate a complete program in one pass.
Software for humans must account for ergonomics. Software for agents needs a similar discipline: call it model-experience engineering. An interface should work with the behavioral patterns models developed during training.
The contrast between REPL and heredoc mirrors the distribution of their training data.
REPL examples usually come from tutorials, debugging sessions, and question-and-answer exchanges. Their typical pattern is exploratory:
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textHeredoc code blocks look more like scripts or source files. They have explicit beginning and ending boundaries, which encourages the model to produce a continuous workflow:
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);This does not mean a REPL is incapable of running complete programs. The model could submit the same block of code to a REPL in one step.
The distinction is contextual. A REPL encourages an execute, observe, continue pattern. A heredoc encourages an organize first, then execute pattern.
That tendency also determines where control flow lives. In a REPL, the model is more likely to split the task into several stages and decide what to do after every result. In a heredoc, it is more likely to put loops, conditions, filtering, and data processing directly into the program and let the local runtime handle them.
What the experiments showed
Among the mainstream agent tools we could integrate reliably, Codex provided the execution capabilities a persistent REPL requires. So we built an automated benchmark on the Codex SDK: the same agent completed four types of real browser tasks through both REPL and heredoc, and we aggregated the results across repeated runs for comparison.
The tasks were:
- X trending-post analysis:Collect OpenAI's original posts from the past seven days, exclude pinned posts, reposts, and replies, rank the top five by views, and calculate their engagement rates and overall average.
- OpenAI job application: Find the correct Cloud Infrastructure position in San Francisco, upload a resume, complete the application form, and stop before the final submission.
- Redfin mortgage calculation: Filter properties in Austin by home type and price, open the first result after sorting, change the down payment to 20%, and retrieve the updated estimated monthly payment.
- Expedia flight search:Find a one-way, nonstop flight from JFK to MIA, select the cheapest option from a specified airline, enter the passenger's information, and stop before payment.
These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.
Both approaches completed most of the tasks. Heredoc achieved a 77.5% success rate, compared with 75.0% for REPL. The difference in reliability was modest.
The larger difference was efficiency:
- Average completion time fell by 35.0%.
- Median completion time fell by 30.7%.
- Tool calls fell by 35.5%.
- Token consumption fell by 29.8%.
- Average cost fell by 21.6%.
Although a REPL can reuse runtime state, that advantage did not produce fewer interactions. In practice, the heredoc agent made fewer tool calls.
The results matched our earlier observations. Once inside a REPL, the agent often ran a small piece of code, examined the result, and then decided what to do next. Loops, filters, and decisions that could have been handled inside a single program were instead distributed across several model–tool exchanges.
The two environments offer similar expressive power. Their efficiency difference comes primarily from how their interaction patterns shape agent behavior. At least for these four browser-agent tasks, heredoc more consistently encouraged the model to organize a complete program, push loops, filtering, and decisions into the code, and avoid the extra round trips of step-by-step decision-making.
We also examined whether the same pattern held at a larger scale by comparing ego-browser with a similar REPL-based browser automation product on the Odysseys dataset. Unlike the controlled experiment above, this comparison involved two complete products rather than the same model operating through two interfaces. It is therefore useful as an overall efficiency comparison, but its differences cannot be attributed entirely to heredoc versus REPL.
This is not a permanent victory for heredoc
We do not believe heredoc is inherently superior to REPL.
Our conclusion depends on the capabilities of models, the distribution of their training data, and the design of agent tools as they exist in 2026.
Today's agents are generally better at producing a complete block of code in one pass. Their shell tools are also designed around a simple lifecycle: submit a command, wait for it to exit, and return the result. Under those conditions, heredoc makes it easier to reduce interaction rounds and move control flow into locally executed code.
Those conditions may change quickly.
Future agent tools may provide reliable persistent sessions, structured outputs, and robust state recovery. Agents may no longer need to handle REPL prompts, process state, and interrupted sessions themselves. Targeted training could also teach models to submit complete programs proactively inside a REPL instead of falling into unnecessary step-by-step interaction.
If that happens, REPLs could preserve the benefits of state reuse and immediate feedback without requiring more model calls. They may even become the better choice for tasks with expensive initialization, long-lived state, or a genuinely exploratory workflow.
That is why the title specifies 2026. We are not claiming to have discovered a permanent law. This is a point-in-time engineering judgment based on the models and agent tooling available today.