v0.7.4

A reply that breaks after it is on screen is no longer sent again — up to ten times, each retry printing the same answer. Now the failure is shown once and what arrived is kept. And tool_timeout_sec: 0 is refused when a run that uses the server starts, where it used to time out every call to that server the moment it was made.

Fixed

• A reply that failed after it streamed is no longer sent again and again. In an interactive session, when a stream broke at its very end — the whole answer already on screen — iota retried the request, and every retry printed the same answer again, up to ten times. A provider that fails the same way every time looked like an endless loop. Now, once text has reached the screen, a failure is shown once and not retried — the error says it was not retried because the reply had already streamed — and what arrived is kept, together with the tool calls the turn had already run, marked as possibly incomplete:

  What arrived before the failure is kept — the reply may be incomplete.

  If the reply is incomplete, send your message again. A failure before any text arrives is still retried as before.

• tool_timeout_sec: 0 is an error, not a deadline of nothing. An mcp_servers entry with tool_timeout_sec: 0 used to make every call to that server time out the moment it was made. Now a run that uses that server refuses to start, naming the server:

  config mcp_servers.<name>.tool_timeout_sec 0: want 1 or more

  0 does not mean "no deadline" either: the deadline is what gives a headless run or a bot — which have no Esc — its turn back from a server that stopped answering. For a tool that runs long, write a large number instead (86400 is a day).