For minimap enthusiasts I'd love to get some user feedback and thoughts about how to best implement this, especially for cloud. I'd appreciate anyone who wants to test it out on local and cloud and give me some feedback. You can access my branch here (I have not opened a PR): github.com/FraterCCCLXIII/openhands-main/tree/minimap Notes about implementation and open questions: The conversation minimap currently builds its strip by walking every event page on open (

events/search

until exhaustion). Chat only loads the last ~50 events and paginates on scroll-up. On Cloud that full walk hits the App API (

/api/v1/conversation/{id}/events/search

) and downloads actions/observations, not just user turns — then a click on an unloaded turn walks those pages again into the chat store. That’s expensive and the wrong split: the strip needs a turn index, chat needs pages on demand. What we could do: 1. Stop the Cloud full-history fetch on open.Until a cheap index exists, build minimap segments from the chat store only (loaded tail + live websocket). 2. Keep click-to-scroll as

loadOlder()

until that user event is in the store, then scroll. Pay per jump, not per open. Use`strictPagination: true`so old Cloud backends that 500 on pagination filters fail loudly instead of returning empty pages. 3. Add a cheap turn summaryin software-agent-sdk, then typescript-client, then this frontend. Preferred:`GET /api/v1/conversation/{id}/turns`→`{ id, timestamp, preview, agent_response_length }`. After that, the strip can show every turn without downloading the transcript. Do not keep the independent full walk and inject it on click (still bills every open), and do not fetch a timestamp window that leaves a hole in the store (breaks scroll-up pagination).

Oh, this sounds great! How about: • point 3, add /turns, or something to easily keep and retrieve/match the pair

(user message, end-turn agent message)

• replace the main conversation view with the human-agent conversation (the per-turn exchange of messages) • maybe we could keep a “full timeline” elsewhere, on a side or behind a link (I believe @hundreds-twilight-32833 had a timeline This is very funny… and it makes me reconsider some stuff… I’ve had my agent add some

turns

to the agent-server API a long time ago, and since then I keep meaning to remove them (and get back to compatibility with the regular openhands agent-server). 😅 But

turns

is… a very good primitive for human-agent communication! Please note it’s also what the user experiences when using messaging apps, e.g. OpenHands in Slack. As agents got good, I honestly believe that looking into the detail of some random tool call is just not going to be a thing. So, you know, I keep wondering why do we keep the main real estate for them? One could say, well, sometimes you may want to debug a thing, but then, that’s what observability dashboards are for, aren’t they?

Re: timeline view -> Have you seen what Deepseek did for agent activity inspection in their new harness? I think that would be a goal 😄

Re: `GET /api/v1/conversation/{id}/turns`→`{ id, timestamp, preview, agent_response_length }` I think the public API needs to return the references or content as is, instead of

preview

alone, because other clients may use it, and in fact, in

agent-canvas

too we may change our mind and experiment with showing it in some way. 🤔 e.g.

GET /api/v1/conversation/{id}/turns/{id}

-> maybe user_event_id, agent_event_id, preview, length 🤔 May need a bit of thinking…