What changed, when.

Routines no longer stop because they reached a configured number of model steps. A complex run that legitimately needs many tool calls, retries, and synthesis passes can now finish its work.

What replaces the cap is a distinction between productive and stalled runs. Every run has an inactivity timeout that resets each time the run records real progress — a model step, a tool call, a tool result. A run waiting on a slow third-party API keeps its budget as long as work keeps landing; a run that goes quiet is stopped and marked as idle, distinctly from one that hit the absolute deadline.

The absolute deadline and your plan's usage guardrails still bound every run, and cancellation works as before. On the hosted scheduler, a single run is also bounded by the platform's execution window, so the effective deadline is the smaller of the two. Existing routines keep running without changes — their stored step limits are simply no longer enforced, and run traces now show why a run stopped and when it last made progress.

Meaningful product changes now land here as they ship: new capabilities, improvements to existing behavior, fixes worth knowing about, integration changes, and operational notices.

Every entry has a stable URL you can link from support threads or internal docs, a category so you can scan for what affects you, and links to the surfaces it changed. The feed at /changelog/rss.xml carries the same entries, so a reader in your team chat can follow along without checking the site.

What qualifies as an entry and who publishes it is documented in the repository, so the changelog stays a record of real changes rather than a marketing surface.

The routine library now ships fourteen templates. New arrivals include dependency vulnerability triage, GitHub issue triage, stale pull request review, error trend review, funnel conversion reporting, churn and payment-risk review, release notes drafting, and competitor site watch.

Each template now carries structured metadata — category, cadence, the roles it serves, and the integrations it works with — and the library is searchable and filterable by all of it. The same metadata drives the creation wizard, so the template you found on the site is the one you configure in the product.

Six category pages group related templates with the access each one needs, so you can start from the responsibility rather than the template name.

Three execution improvements shipped together.

Runs now gather their materials — skills, variables, and connector tools — before the model takes its first step, so a missing permission surfaces at the start of the trace instead of ten steps in.

Traces narrate phases as the run moves through them: preparing connector tools, working the routine with the configured model. Reading a trace now tells you where time went, not just what the model said.

And routines can search the web natively when their instructions call for it, without routing through a connector — useful for research, competitor monitoring, and any routine whose sources are public pages.

Self-serve billing now has four tiers. Starter covers a team putting its first paid routines to work. Scale sits above Pro for teams running many concurrent routines, and its API keys carry full write access — creating and updating routines from your own code no longer requires Pro specifically.

Plan changes project through Stripe's lifecycle events, so upgrades, downgrades, and cancellations all land in your billing settings with the timing Stripe reports. The pricing page has the current comparison.

Signed-in sessions now last thirty days instead of seven, and renew daily while you keep using the product. Setting up a routine, checking a run trace mid-week, and coming back after a quiet stretch no longer means re-entering a password.

Nothing about the security model changed: cookies stay HTTP-only and same-site, signing out still ends the session immediately, and a revoked session is rejected on the next request. The lifetime is enforced from the session record on our side, not from the cookie alone.

Routine finish notifications already delivered to any webhook URL. Discord incoming webhooks are now recognized specifically: the delivery is formatted as a message Discord renders cleanly, instead of a raw JSON body that Discord rejects or truncates.

Nothing changes for other webhook targets — signatures, retries with backoff, and the delivery trace behave exactly as before. Add a Discord channel webhook to a routine's notifications and the run result lands in the channel your team already reads.

A run's trace used to appear when the run finished. It now streams while the run executes: each model step, tool call, and tool result lands in the dashboard as it happens, and the page keeps itself current without a manual refresh.

Proving a new routine gets faster because of it — you can watch the first manual run work through its instructions, catch a wrong variable or an over-broad tool grant immediately, and cancel instead of waiting for a result you can already see going sideways.