One round for a chat, as many as it takes for an agent

Two different jobs were sharing one number. A plain conversation asking a
question is one round of looking things up and then an answer; the rounds after
that were a small model that had decided searching was the answer searching
until the context ran out, at a full request each. MAX_ROUNDS is 1 now. Several
tools can still be called within that round, which is the thing worth telling
the model.

The trade is real and worth naming: a plain chat can no longer search and then
read one of the results, because reading is a second round. That is what an
agent chat is for.

An agent chat is sized by Limits instead, where steps is now a runaway backstop
and not a working budget. It was 40 and it was reached -- a step count low
enough to be the thing that ends a reply is a count that ends it halfway. What
bounds one now is the wall clock and a new completion-token ceiling, with zero
meaning no ceiling, the same convention index_chars already uses.

That ceiling would have been decorative. generation.completion_tokens is only
populated when the endpoint sends a usage block, and llama.cpp, Ollama and
friends never do; the fallback estimate is computed once, in _run's finally,
long after the loop that needs it. So _written takes the larger of reported and
estimated, and there is a test that runs the whole thing against a stream
reporting no usage at all. A limit that works on OpenAI and silently does
nothing everywhere else is the worst kind: one that looks configured.

core.rounds could not stay one fragment. "You get at most N rounds" is not the
same sentence with a different number in it -- a model told it has a budget
rations it and stops early to report progress, which is exactly the behaviour
that strands a long piece of work. So it splits: core.rounds keeps the
one-round case and gates on a new round_budget variable that _agent_values
blanks, and core.keep_working says the other thing to an agent chat.

A queued message during a one-round reply is now never taken mid-reply -- there
is no work under way to steer -- and falls through to _drain, which gives it a
reply of its own. No code change went with that; it falls out of the guard, and
there is a test so that "it happens to work" and "it is meant to work" stop
looking the same.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jaroslav Beneš
2026-08-03 11:11:05 +02:00
parent 3345df5b38
commit 7977d4ef25
13 changed files with 322 additions and 30 deletions
+18 -1
View File
@@ -66,9 +66,19 @@ def _agents_defaults() -> dict[str, Any]:
"max_timeout": 600,
"max_output_bytes": 64 * 1024,
# Per reply. See services/agent/policy.py:Limits.
"max_steps": 40,
#
# `max_steps` is a runaway backstop rather than a working budget: an
# agent reply is meant to run until the task is done, and a step count
# low enough to be the thing that stops it is a count that stops it
# halfway. What actually bounds a long reply is the wall clock and
# `max_completion_tokens`.
"max_steps": 200,
"max_wall_seconds": 900,
"max_total_output_bytes": 1024 * 1024,
# How much the model may *write* in one reply, across every round.
# Zero means no ceiling, which is a thing somebody may want and has no
# other way of being said -- the same convention as `index_chars`.
"max_completion_tokens": 200_000,
# How long a reply waits for someone to answer. Clamped on read: a zero
# here would park a background task forever.
"approval_timeout": 900,
@@ -261,4 +271,11 @@ def agents(db: DBSession) -> dict[str, Any]:
# directory for the file picker, but put none of it in the prompt", which
# is a reasonable thing to want and has no other way of being said.
values["index_chars"] = min(max(int(values.get("index_chars") or 0), 0), 20_000)
values["instructions_chars"] = min(
max(int(values.get("instructions_chars") or 0), 0), 20_000
)
# Zero is meaningful here too: no ceiling on what one reply may write.
values["max_completion_tokens"] = min(
max(int(values.get("max_completion_tokens") or 0), 0), 5_000_000
)
return values