Let the in-TUI viewer send a steering message to a running agent during a
live scan, reusing the same delivery path the TUI uses. Standalone strix
view reports steering unavailable, so the web composer only shows when a
live scan is in process.
- Verify your email right on the Past runs page instead of being sent off
to the Email report page; the list unlocks in place once verified.
- Show a clean target-based title (like arch.co) and a relative time
instead of the raw run folder name everywhere runs are listed.
- Land on Agents while a scan is still live and on Overview once it is
done, without ever overriding where you navigate yourself.
- Collapse the sidebar into one ordered list of uniform two-line rows (icon +
label + short one-liner), no tier sections.
- Sidebar Pro/Enterprise rows now open an in-app FeatureDetail upsell page
instead of linking out; the page's primary CTA is the sign-up link.
- Past runs "View runs" runs a verify-only flow that never sends a report.
- Ask for a work email: helper text, an instant common-domain check, and a
friendly message when the relay rejects a personal domain.
The subtext now leads with the zero-knowledge assurance (we cannot read the
report) and frames the email step as verifying who we send to via a one-time
code, rather than unlocking a feature.
`strix view` opens a run in the browser, served locally from the run files
(nothing is uploaded). There's also a quick link to it from the TUI and the
end-of-run summary.
An httpx.Timeout in ModelSettings.extra_args crashes
ModelSettings.to_json_dict() (PydanticSerializationError) on the Chat
Completions and LiteLLM model paths, which serialize settings for their
tracing generation span — failing every model turn on those paths. Pass
the timeout as a plain float, which httpx-based clients apply as the
read (inactivity) timeout.
The SDK's http_status retry policy only retries errors carrying a known
HTTP status code, but quota/billing (and other provider-side) failures
often surface inside a streamed response as a bare error with no status
code, so they were failing on the first attempt. Add a statusless retry
policy to DEFAULT_MODEL_RETRY (retry count and backoff unchanged) so they
are retried before a genuine exhaustion fails the run; user aborts are
never retried.
The SDK's http_status retry policy only retries errors carrying a known
HTTP status code, but quota/billing (and other provider-side) failures
often surface inside a streamed response as a bare error with no status
code, so they were failing on the first attempt. Add a statusless retry
policy to DEFAULT_MODEL_RETRY so they are retried (before any content is
streamed; user aborts are never retried), restoring the pre-SDK engine's
resilience. If the provider is genuinely exhausted, the error still
propagates and fails the scan after retries.
Jonathan Singer