Skip to main content

v0.7.5

A script, a CI hook or another iota can now send a running chat a message: iota resume <id> -m "…" on a session that is open elsewhere — and iota run <bot> -m "…" on a bot that is running — hands the message to that chat instead of refusing, and prints one line saying what became of it. A provider's rate limit or usage cap no longer turns into an endless loop: finished background jobs stop starting new attempts, iota tries again on its own later, and Esc holds the work queued behind the turn you stopped.

Added​

  • Other programs can message a running chat. Each interactive iota now listens on a private Unix socket. iota resume <id> -m "…" used to refuse a session that was open in another iota process; now it hands the message to that chat, and iota run <bot> -m "…" does the same for a bot that is running (one that is not running still refuses, as before). The sender prints the chat's receipt on stdout, one line of JSON:

    {"ok":true,"state":"queued","ahead":1}

    woken (the chat was idle and the message is its next turn), queued (the chat is busy; it goes in at the next safe point) or held (see below) mean it was taken; blocked (the chat is waiting for you — an approval, a question), too-large, refused or flooded mean it was not, and the sender exits 1.

    The message never interrupts a running tool call. It shows up as a dim [message from …] line, not as something you typed, and a leading / is never run as a command. The model is told it came from another process and is nobody's approval. A chat whose tools run without asking (auto_run, auto_write) answers held and asks you — Let the model read it or Discard it — before the model sees it.

    Programs started from the chat find its socket in IOTA_SOCKET. Only the same OS user can connect, and there is no network listener. Not available on Windows yet: there, -m on a session open elsewhere says it cannot be messaged.

Fixed​

  • A rate limit or usage cap no longer turns into an endless loop, and Esc really stops. When the provider refused with 429 and retrying did not help, every background job that finished started a new attempt — and printed another Rate limited (429) error. Now iota stops on its own. Notices from finished jobs wait, each leaving a dim line that says so:

    ⏸ [background job b2 finished] — held until 17:42

    While some are waiting, iota tries once more later: when the provider says it may (retry-after), otherwise after a minute, then less and less often, at most every 30 minutes. A try that is refused again leaves one dim line, not another error. Sending a message tries at once and takes the waiting notices with it; switching model or provider with /model tries at once there. A notice is no longer lost when its turn is refused by a rate limit, and the provider's own message, with its reset time if it gives one, is still shown.

    Esc holds too. Notices queued behind a turn you stopped no longer start new turns; they go with your next message.

    Fewer silent waits. A 429 now gets at most three more tries (it used to be ten), and a provider asking to wait more than a minute — with a 429 or any other error — is no longer waited out in silence: iota stops and holds until then (a day at the most), unless the provider insists on being retried.

  • The queue's · ↑ edit hint no longer promises what ↑ can't do. ↑ brings back only a message you typed, never a finished job's notice, yet a queue holding nothing but such notices still ended in · ↑ edit, and ↑ did nothing. The hint now shows only while the queue holds something you typed.

Changed​

  • Tool-call labels are easier to read. The [shell ls -la]-style label on every tool call — while the call is being written, while it runs, and in the line it leaves — is no longer one block of cyan: the brackets are faint, the tool's name is bold cyan and what follows it is cyan. Where a call shows its arguments as key:value, the keys are faint, so [srv:search limit:10 query:rust tui] reads as two arguments at a glance. The text is exactly what it was, and with NO_COLOR set it is plain text as before.

  • Certificate chains through the distrusted emSign intermediates are rejected (rustls-webpki 0.103.16, RUSTSEC-2026-0382): those intermediates' private keys are public. This matters on Linux, where iota checks a server's certificate itself against the system's trusted roots; on macOS and Windows the operating system checks it.

  • tokio is 1.54.1 (RUSTSEC-2026-0386). The advisory is about a part of tokio that neither iota nor anything it builds on uses, so it never applied.