Files
only-cli f84074701d perf: spend one command where the tool used to need two
A tool call inside an agent session costs 23,000 to 33,000 tokens of
overhead whatever it prints, so the page-view win only reaches the
session total if answering a task takes fewer commands. Three places
were charging a command to say what the next command should be, each
found by capturing the command stream of a real agent run rather than
by reading the code.

A search result title is a link. Every engine puts it in an anchor
filling an <h2>, and the walk took the heading's text and returned,
dropping the href, so `do` on the most obvious number on a results page
printed the title back. The agent then spent a second command finding
the number that navigates. The href now rides along when the anchor is
the whole heading, which is the test documentation fails on purpose:
every heading in the Rust book and on an AWS CLI reference page carries
a permalink to its own id, and following one would refetch the page the
agent is already reading.

`find` pointed at its answer. With a single match it printed the block
and a number, and the agent's next command was always the `read` on
that number, so it now prints the region. With several matches it
showed a 200 character snippet of each even when the budget had room
for them whole, so it spends that room, on the same terms `FINISH`
already documents for a page that nearly fits.

A truncated block ended mid sentence. Asked for the first sentence of a
page, an agent was handed it complete, followed by a marker saying 302
characters were cut, and spent a command on `read` to find out whether
the sentence went on. The cut now falls on the last sentence that
finished inside the cap, and measured across five real pages it costs
nothing: four came out within three characters of before.

The package-lock name field catches up with the scoped package name,
which npm rewrites on any install.
2026-08-23 08:46:10 -04:00

32 lines
1.6 KiB
HTML

<!doctype html>
<html><head><title>s3 cp recursive at Fixture Search</title></head>
<body>
<div id="links">
<!-- The shape every engine uses: the result title is an anchor filling an
h2, wrapped in the engine's own click tracker. Following it is the
whole point of the page. -->
<div class="result">
<h2 class="result__title"><a class="result__a" href="//fixture.test/l/?uddg=https%3A%2F%2Fdocs.example.test%2Fs3%2Fcp.html">cp - Fixture CLI Command Reference</a></h2>
<a class="result__url" href="//fixture.test/l/?uddg=https%3A%2F%2Fdocs.example.test%2Fs3%2Fcp.html">docs.example.test/s3/cp.html</a>
<a class="result__snippet" href="//fixture.test/l/?uddg=https%3A%2F%2Fdocs.example.test%2Fs3%2Fcp.html">Recursively copying local files to S3 with the --recursive parameter.</a>
</div>
<div class="result">
<h2 class="result__title"><a class="result__a" href="https://docs.example.test/s3/index.html">s3 - Fixture CLI Command Reference</a></h2>
<a class="result__snippet" href="https://docs.example.test/s3/index.html">High level commands for the object store.</a>
</div>
<!-- A heading that only contains a link is not a heading that is one. -->
<div class="result">
<h2 class="result__title">Related searches for <a href="https://docs.example.test/s3/sync.html">s3 sync</a></h2>
</div>
<!-- Documentation markup, and the reason the href cannot ride along
unconditionally: both of these point back into this same page. -->
<h2 id="options">Options<a class="headerlink" href="#options">&para;</a></h2>
<h2><a class="anchor" href="#see-also">See also</a></h2>
</div>
</body></html>