Test run filters now support excluding branches that contain a specific substring. Use the new "does not contain" branch operator in the dashboard, or the query=-git_branch~"gh-readonly-queue" expression in the REST API and list_test_runs MCP tool, to hide merge queue runs such as gh-readonly-queue while keeping the rest of the test history visible.
The Runners section on your account dashboard now surfaces the full picture of the workflow_jobs Tuist Runners executes on your behalf — a Runners landing page with total-jobs, p50/p90/p99 job and workflow duration widgets and recent activity; a Workflows page with per-workflow rollups (success rate, average duration, last run) and a detail page for each workflow; and a Jobs page with status / repository / platform / branch / conclusion filters, scatter or line charts for duration and queue time, and live-updating Running and Queued widgets.
Each workflow_job has its own detail page mirroring GitHub's /<owner>/<repo>/actions/runs/<run_id>/job/<job_id> shape (so the Tuist URL and the GitHub URL nest the same way), with a timeline card for queue / claim / runtime / total durations and a deep link back to GitHub.
Compute minutes — the metered signal we bill against — roll up from the Pod's wall-clock lifetime rather than GitHub's workflow_job timestamps, the same way Namespace and Blacksmith account for their runners. Every dashboard widget that aggregates duration is scoped by the same Repository / Workflow / Platform / date-range filters as the table below it, so the chart and the rows always represent the same window.
Tuist now supports auth.md, the open agent registration specification. Agents that implement the standard can connect to the Tuist MCP server directly: depending on the agent, Tuist either confirms the registration with the agent provider, or emails you a secure link with a six-digit code to read back to the agent. No browser-based OAuth round-trip required.
Tuist-managed Kura caches can now authorize binaries scoped directly to an account, without requiring every cache artifact to belong to a project namespace. This gives account tokens first-class cache read and write grants for account-level binaries while keeping project tokens limited to project-scoped cache access.
The Xcode Cache analytics page now shows Cache transfer, latency, and throughput widgets, each with a dropdown to switch between the combined value and the per-action split.
The build detail page now surfaces a Module Cache tab when the build's associated command event recorded binary-cache data, bringing the same cache hit/miss breakdown, per-module hash, and JSON export already available on command and test run pages to xcodebuild runs.
Account settings now shows your global Kura endpoint when it is available, making it easier to point clients at the nearest healthy region without copying regional endpoints one by one.
Register HTTPS endpoints on your account, pick the Tuist events each one should listen to, and have downstream systems react the moment a test case is created or updated, or a preview is created or deleted — post fresh builds into Jira, mirror flaky-test transitions into your incident tracker, no polling required.
Test case timelines now show exact timestamps when you hover over relative dates. This makes it easier to compare when a test was marked flaky, muted, skipped, or first seen against the runs around it without leaving the dashboard.
The tooltip is available in both the Test History tab and the compact history section on the test case overview.
You can now build automations that react to individual test case changes the moment they happen, instead of waiting for the scheduled flakiness monitors to converge. Pick Test updated under When and tick the changes you care about — Marked as flaky, Unmarked as flaky, or state transitions to Enabled / Muted / Skipped — and the configured actions fire right away. The common shape: someone manually marks a flaky test, the automation immediately mutes it and pings Slack. Each automation-driven change also lands on the test case timeline attributed back to the rule that triggered it, so you can always see which automation moved a test and why.
