[Bug]: session time.streamed is never persisted and step.streamed fires after the stream ends, not at first token #57178

Activity

1. opencode-agent commented on Oct 19, 2026

   

   opencode-agentBot

   on Oct 19, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed write-up. Before we go further, could you describe briefly, in your own words, what you did, what you expected and what you saw? Two specific questions:

   1. How did you check the database? Please share the exact query or tool and which table you read. In v2, the assistant message is saved as JSON in the data column of the session message table, and the code in both v2.0.32 and dev writes time.streamed there when session.step.streamed is handled. Please also confirm that those 1,285 messages were created by v2 (opencode --version → 2.0.32) and not by a v1 install, whose messages don't have this field. Which provider/model did you use?
   2. About the first-token timing: ending at the end of the response is intended. The schema documents time.streamed as "When the provider response body ended, before tool settlement", a test asserts that timing, and the TUI token-rate and debug metrics use streamed - created as the response duration (see fix(core): include provider wait in token throughput timing #47125). Publishing it at the first token would collapse that duration and inflate tok/s, which is the problem described in tui: token rate uses the final metadata burst instead of model-call duration #46883. A separate time-to-first-token value would be a feature request rather than a fix to this field.

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.

   Related issues, ordered by likelihood of relevance:

   • fix(core): publish step.streamed at the first provider event (TTFB), not stream end #57179: your PR moving step.streamed to the first provider event
   • tui: token rate uses the final metadata burst instead of model-call duration #46883: token rate is wrong when the streamed - created span is too short, which moving streamed earlier would also cause
   • fix(core): include provider wait in token throughput timing #47125: the fix that kept time.streamed at the end of the response body for throughput
   • [FEATURE]: Performance tab with TTFT / tok/s / wall time per LLM call in the web app #49381: request for a performance view with TTFT / tok/s per LLM call
2. opencode-agent

   added

   triaging

   on Oct 19, 2026
3. opencode-agent

   closed this as not plannedon Oct 22, 2026
4. opencode-agent commented on Oct 22, 2026

   

   opencode-agentBot

   on Oct 22, 2026 – with OpenCode Agent

   Contributor

   More actions

   We're closing this as not planned because we haven't heard back on the questions above.

   To recap:

   • Recording time.streamed at the end of the response is intended. The schema documents the field that way, and the token-rate and debug metrics depend on it (see fix(core): include provider wait in token throughput timing #47125 and tui: token rate uses the final metadata burst instead of model-call duration #46883).
   • We couldn't confirm the "never persisted" part. In v2.0.32 and dev the code writes time.streamed to the message data, so we'd need to know how the DB was queried and that the sessions came from v2.

   If you can share those details, or want to suggest a separate time-to-first-token value as a feature, please comment here or open a new issue. Thanks for the report.
5. mradwankhalil commented on Oct 22, 2026

   

   mradwankhalil

   on Oct 22, 2026

   ContributorAuthor

   More actions

   Closing is fair given that I missed the earlier question. Here is the exact check I used.

   Tool: Python 3.13 sqlite3 in read-only URI mode against the live v2 database (...\.opencode-v2\data\opencode.db).

   SELECT COUNT(*) AS assistant,
          SUM(json_extract(data, '$.time.streamed') IS NOT NULL) AS with_streamed
   FROM message
   WHERE json_extract(data, '$.role') = 'assistant';

   Current result: 190 assistant messages / 0 with time.streamed. The earlier database snapshot quoted in the report had 1,285 assistant messages and the same zero result. The stored v2 message JSON has time.created (and, when completed, time.completed), but no time.streamed key.

   I am not disputing your point that recording time.streamed at the end of the response is intended. The remaining actionable part of the report is the session.step.streamed timing: it currently fires after the stream ends, so it cannot represent first provider event / TTFB. A narrower follow-up can cover that without changing time.streamed semantics. I have not reopened this issue or opened a replacement without a maintainer decision.
6. mradwankhalil commented on Oct 22, 2026

   

   mradwankhalil

   on Oct 22, 2026

   ContributorAuthor

   More actions

   Reopened. The scope is now the separate session.step.streamed timing question: it should mark the first provider event, not stream end. The time.streamed end-of-stream semantics are not being changed, and the DB query/result is in the previous comment.
7. mradwankhalil commented on Oct 22, 2026

   

   mradwankhalil

   on Oct 22, 2026

   ContributorAuthor

   More actions

   I tried to reopen this issue, but GitHub returns “Could not reopen the issue” for this contributor account (author association: CONTRIBUTOR; repository permissions: pull only). Could a maintainer reopen it, or confirm whether a narrowed replacement issue is preferred? The database evidence and the scoped session.step.streamed question are in the comment above.