Changelog

We tell you when a model declines a request under its provider's usage policy, without repeating the provider's raw refusal. You can rephrase the request or choose a different model, then reply in the same conversation to retry. This changes how we explain the failure; it does not override the provider's policy or guarantee that a retry will be accepted.

If a task's repository is archived, deleted, or removed from the GitHub app, we stop the turn rather than run it in another repository. The conversation now asks you to restore access and reply here to retry, without exposing internal repository details.

An upstream service can echo a credential into a sandbox file without giving it a recognizable token prefix. We now withhold cited files containing an exact repo-secret value from the task's workspace, while retaining the existing credential-pattern checks. Values shorter than eight characters are ignored to avoid false positives. This attachment check does not scan the agent's reply text or catch transformed or encoded secret values.

Our September 30 entry said such a task could resume on its own a couple of minutes after the reset. That stopped being true on October 2, when every task became a conversation: the work belongs to the message that started it, so we don't replay it without you. The failure message still names the reset time and tells you to reply after it, and the task keeps its agent session, so your reply continues where the agent stopped instead of starting over.

Each page lists the request and response fields and every error code that endpoint can return. That includes the ticket delegation refusals, which the old single-page guide left out. The spec is generated from the same code that serves the API, and our tests check the API's real responses against it, so the reference changes when the API does. Two limits: there's no "try it" panel, so you call the API from your own terminal or code, and there's no official SDK yet. The CLI, MCP and API guide is shorter now and links to the API reference for the per-endpoint detail.

On plans with room for more than 5, you're no longer stopped at 5 tasks from these surfaces. When the queue is full the start is refused right away with the dashboard's message, which links to the upgrade page on Free, and a start that billing would stop, for want of model access or a paid-up subscription, is refused up front too, with a link to fix it, instead of opening a task that stops at once. For scripts these are 409 capacity_full and 409 payment_required, with the message in reason; 429 too_many_running is gone. Until the next CLI release, the CLI shows only the code; MCP clients get the full message now.

Missing model access links to where you connect your own subscription or add a workspace API key, and a past-due subscription links to billing. The queue-full message's upgrade link now opens the billing section too. Before, the message on Linear, GitHub, MCP and the API named the fix but left you to find the settings page. The CLI prints these messages from its next release; until then it shows only the code.

Since the end of September the agent has cloned the repository itself, after the point where we installed the trailer hook. So commits from a task's first turn, and from the self-review right after it, went out without your trailer, and only later turns had it. An agent could also pick its own commit identity, and one did: it borrowed the repo owner's email from Cargo.toml, so GitHub credited that commit to them rather than to the Sinatra bot. Sinatra now sets the author and committer for the whole run, which git ranks above git -c user.email=… and any repo config. An explicit --author would still set the author, so the agent is also told not to use one; Sinatra stays the committer either way. Once a hook manager such as Husky sets core.hooksPath, commits still go out without the trailer.

We built it on the same task the CLI and MCP start, so it gets its own page where you can follow along and answer the agent's questions. It's also step 4 of onboarding: until now a new workspace with no open issues had nothing to start there.

If we can't run the task yet, the box tells you before anything starts: you haven't connected model access, the queue is full, or the repository has no commits, so there's no branch to open a pull request against.

That reply, answering our question about an empty repository, scored 84% likely to be an attack because the screen saw it without the question. On Linear the screen now reads a reply against the comments before it, a message sent mid-run is read against the request being worked on, and no single word such as ignore, stop or instead counts against a message. A reply from the person who started the task now needs 95% to be refused and everyone else's still needs 80%; that is a loosening, since an attack sent from their account needs a surer flag. One thing is stricter: code that runs a script fetched from an unexpected source is now flagged. On GitHub and Slack, a reply that starts a run is still read without the comments before it.

The model behind these checks was already served by such a provider. What's new is that every request now requires it, so a change of model or provider can't quietly send your text somewhere that keeps it. If no provider qualifies, the check fails instead of falling back, and a failed check behaves as it always has: the prompt-injection screen lets the run go ahead, as the security page says. Change summaries and repository descriptions are generated text, not decisions, and still run under the provider's standard terms, which allow keeping data for a limited time.

Linear drops an app's access when the app is removed or its access is revoked. Until now Sinatra kept showing Linear as Connected, and Linear tasks failed with "an internal error occurred". When Linear refuses Sinatra's token, Sinatra first refreshes it once, so a token that only needed refreshing keeps working. Only when Linear refuses the refresh as well does Settings ask for a reconnect, which an owner or admin does from Settings → Integrations. The email is an account notice, so it arrives even if you've turned off task alerts. Tasks that stopped don't resume by themselves: reply on the issue to run them again.

A Linear workspace connects to one Sinatra workspace. When someone started Connect Linear for it from another Sinatra workspace, we stopped there and dropped the new authorization. But approving Sinatra in Linear again replaces the old authorization, so the workspace that held the connection lost it. Its Linear tasks then failed with "an internal error occurred". Now the new authorization goes to that workspace, and if you're a member you land on its settings, where Linear shows as connected. If your Linear tasks have been failing since you connected Linear somewhere else, reconnect Linear from the workspace it belongs to.

Every call the code makes runs as you, with the same checks as calling that tool directly, so code can't do anything the tools themselves can't. The sandbox has no network or filesystem access, and each run is capped: 50 tool calls, 200 ms of computation, 30 seconds and a 50,000-character result. One trade-off to know: your MCP client asks you to approve a run_code call once for the whole script, not each tool call inside it, so read the code before you approve it. The existing tools are unchanged, so clients that call them one at a time keep working.

Claude Code, Cursor or a script can hand you the link as soon as a task starts, so you can follow it in the dashboard. get_task, follow_up, get_messages and stop_task now find the task's workspace from its id, so a client holding a task id no longer needs its workspace id. They only find tasks in workspaces you belong to, and workspace_id is still accepted.

Without GitHub, the only way in was an email link, which meant leaving a claude.ai or ChatGPT popup, or a phone's in-app browser, to find the email and come back. You choose a password on the page your sign-up link opens, or, for an account you already made by email, from Forgot password? on the sign-in page. It needs at least 12 characters, and we refuse one that appears in a public list of breached passwords. A reset signs you out of every other browser but leaves the CLI, Claude, ChatGPT and your tokens connected; disconnect those from the Access tokens page. Two limits for now: an account made with GitHub can't add a password yet, and there's no two-factor sign-in yet; GitHub's two-factor authentication covers only accounts made with GitHub. The email link keeps working either way.

A task stops waiting on its own after a long idle period, and a merge or close that came later was recorded but only announced on Linear tasks. GitHub issue and API tasks were silent. That line now goes to the task's own conversation, the same way it does while the task is still waiting. A failed task used to be marked cancelled when its PR closed after the idle period; it now stays failed, as it does when the close comes in sooner.

The clients are generated from the API's OpenAPI spec and released automatically when it changes. They read your token from SINATRA_TOKEN and retry a 429 or 503 with the same idempotency key, so a retry never starts a second task. Paged lists come back as iterators, and an error response arrives as one typed error carrying the status, the error code, a reason and the request id. A status or error code the API adds later doesn't break them. The SDKs page has a quick start for each language.

They are all 0.x. While a client is below 1.0, a breaking API change bumps its minor version, so pin the version you've tested. The Python client needs Python 3.11 or newer and is synchronous only: there's no async client yet. The Node.js client needs Node 20 or newer, and the Go client needs Go 1.24 or newer. Waiting for a reply still means polling, because the API has no streaming.

A workspace made with Start without GitHub has no repository for a task to work in. Before this, a task started there was created, then failed with "an internal error occurred". Now the start is refused with 409 github_not_connected and a link to Settings → Integrations, where a workspace owner or admin connects GitHub (for a suspended installation, its page on GitHub), and a task that runs after the connection is removed says so in its conversation.

Starting a task needs a custom MCP server with write actions, which OpenAI offers on ChatGPT Business, Enterprise and Edu workspaces, on the web. On Business, an admin or owner adds it. ChatGPT Pro can connect custom MCP servers for reading only, so it can't start a task. Add Sinatra as a custom MCP server from ChatGPT's Plugins page, choose OAuth, and approve ChatGPT on the Sinatra page that opens; the CLI, MCP and API docs walk through it. ChatGPT proves who it is with a signed key when it signs in, which Sinatra's sign-in didn't accept until now. Deleting the plugin in ChatGPT doesn't end Sinatra's access on its own: Disconnect it on the CLI & API page too.

Tokens still work: sinatra login --token asks for one, and a token piped in (sinatra login < token-file) is read as before, which is what scripts and CI should keep using. The browser has to be on the same computer as the CLI, so on a machine you reach over SSH, log in with a token instead. A logged-in CLI is listed as Sinatra CLI under Connected apps on the CLI & API page, where Disconnect signs it out at once, and it has to sign in again after 90 days, or after 30 days without use. It's in version 0.2.0 of the CLI; run npm i -g sinatra.dev to update.

Before, sinatra login < token-file read the token and then asked three times for a default workspace against input that had already ended. Now, if you belong to more than one workspace and pass no -w, it saves no default and prints one line saying how to set one. An id that isn't one of the token's workspaces is refused and nothing is saved, so a typo leaves your previous login in place. It's in version 0.1.1 of the CLI; run npm i -g sinatra.dev to update.

Until now the MCP server and API could only start a new task from a prompt. Delegating an existing issue meant assigning it in Linear, labeling it on GitHub, or using the dashboard. Search returns the picker's own list, narrowed by your text: your open issues first, then your team's unassigned ones, read through your own Linear account, so it shows only issues you can see. Delegation follows the dashboard's rules too. Closed issues and issues assigned to someone else are refused, and a full queue refuses the request before the issue is touched. The task then runs on the issue, so follow its progress there or with list_tasks. Linear search matches issue titles only.

Until now the MCP server took only a personal access token in a header, which left out claude.ai and Claude Desktop, whose connectors can't send one. Now the app opens a Sinatra page in your browser, you approve it, and from then on it acts as you in every workspace you belong to, with your role in each, the same reach a token has. Connected apps are listed on the CLI & API page, where Disconnect cuts one off at once; an app also has to sign in again after 90 days, or after 30 days without use. We've tested sign-in with Claude Code, Cursor and claude.ai, and Claude Desktop shares claude.ai's connectors; another MCP client may still need a token in a header. Removing the connector in claude.ai doesn't end Sinatra's access on its own: Disconnect it on the CLI & API page too. Tokens work everywhere they did, and the CLI and HTTP API still use one.

Clients such as Claude can use the hints to decide which calls need your approval. The four reading tools (whoami, list_tasks, get_task and get_messages) are marked read-only, and stop_task is marked as interrupting work in progress, possibly a teammate's. start_task and follow_up are marked as work that can push a branch or open a pull request. The tools and their arguments haven't changed. The docs also gained an Add to Cursor install link.

Slack was a preview for a handful of workspaces until now; any owner or admin can connect it today. Each thread is one task, with the same sandbox, billing and tasks-at-a-time limit as a task from Linear or GitHub, and a message sent while the agent runs reaches it the same way. A reply in the thread that mentions Sinatra always continues the task; one without a mention does only when Sinatra judges it's meant for it, so mention it to be certain. A thread doesn't name a repository, so add repo: owner/name when the workspace has more than one, or the agent picks from what you asked. There are no direct messages, no stop control inside Slack (stop a task from the dashboard or the CLI), and channels shared with other organizations stay off until an owner or admin allows them. Setup is at docs.sinatra.dev/docs/configuration/slack.

Create a token on the new CLI & API page in the dashboard, then install the CLI with npm i -g sinatra.dev or add Sinatra as an MCP server; the page shows the exact setup for each. A task started this way runs like any other: it gets a sandbox, can open a pull request, shows up on the dashboard, and counts against your plan's running and queued limits. Each person can have up to 5 of these tasks starting, running or queued at a time in a workspace; a sixth start is refused until one finishes its turn.

The MCP server takes the token as a bearer header and doesn't support OAuth yet, so Claude Desktop and claude.ai connectors can't connect to it; Claude Code and Cursor can. The conversation holds the agent's answers and questions, not its progress, and a message sent while a turn is running waits for the next turn instead of reaching the agent mid-run. You can also read and answer it on the task's page in the dashboard. The full reference is at docs.sinatra.dev/docs/cli-and-api.

Until now you needed a GitHub account just to sign in. The link we email works once and expires after 15 minutes, and asking for one creates nothing: the account is made only when someone opens the link from that inbox. When you're ready to install the GitHub App on your personal account, link GitHub from Settings or the setup page first. Once it's linked you can sign in either way, but the email link only ever goes to the address you signed up with, never one GitHub lists. An account you made with GitHub keeps signing in with GitHub only. We won't link a GitHub account that already belongs to another Sinatra account, and we won't merge two accounts for you. If you signed in with both before, you'll keep two separate accounts for now.

Deprecated models still run wherever a repository file or saved preference already names them, so nothing stops working today, but the settings dropdowns and the published .sinatrarc schema no longer list them. On claude-code the new names are opus-5-5 and sonnet-5-5, and the engine's default moves from sonnet (Sonnet 4.6) to opus-5-5. Unconfigured runs move too: a Codex subscription falls back to openai-codex/gpt-6.1-sol until we have your account's model list, and skips deprecated models on it, and a lone OpenRouter key now defaults to openrouter/anthropic/claude-opus-5.5 at medium effort.

Before, Codex sometimes refused a message that arrived while it was still generating a response. The turn then ended with "an internal error occurred", and the agent only picked up your message on the next attempt. The sandbox now runs oh-my-pi 18.10.4 instead of 18.4.4. When Codex refuses a mid-turn message, oh-my-pi retries the response on the same model, with your message included as ordinary input. A sandbox created before this update keeps the old runtime until it is recreated.

Until now we dropped those mentions without a word, so it looked as if we were ignoring the person. Our reply links to sign-in and nothing else: it names no workspace or task, starts no run and costs you nothing. Linking doesn't grant access either; their next request goes through the same membership check as everyone else's. We answer each person at most once a day per issue, so repeated mentions don't flood your issue's subscribers. We stay quiet for quoted mentions, bots and comments that don't mention Sinatra, and people who are already linked but not in your workspace still get an access request for the owners instead. We built the reply so a redelivered webhook shouldn't post it twice, but in rare cases where GitHub doesn't confirm a post, a person could see it twice or not at all.

Free is 1 task at a time, plus 1 queued. Pro is $20 a month for 3 tasks at a time, plus 10 queued; Team is $99 for 10 at a time, plus 25 queued; and Scale is $249 for 25 at a time, plus 100 queued. There is no daily limit any more: work past your running limit is queued and starts on its own, and once the queue is full Sinatra says so on the ticket instead of starting it.

This is a tightening on Free if you ran several tasks side by side: the day's five free tasks could all run together, and now the second waits for the first. On Free, each request also stops after 60 minutes, keeps its changes, and picks up when you reply.

Nobody is billed per member now, so inviting a reviewer no longer costs anything. You still bring your own Claude or ChatGPT subscription or an API key; Sinatra doesn't bill for model usage.

The dashboard shows each task as In progress, Queued, Needs your input or Idle, and lists every PR the task opened with its own status. Merging or closing a PR changes that PR, not the task: reply on the ticket and the same task carries on.

A message you send while a run is going now reaches Claude Code as well as oh-my-pi. Sinatra decides whether it changes the work in progress now, gets folded in before the run finishes, or runs as its own next turn, and tells you when it waits. A message from someone who can't spend the running agent's credentials becomes their own next turn instead of being refused.

A CI failure on the task's PR now runs as its own turn, after any work people asked for, and stops after the repository's ci.max_rework attempts in a row with a note on the PR.

Before, we treated ChatGPT's usual form of that rejection as a temporary error and retried every hour, so the connection looked fine until a task failed with a generic error. Now a task that hits it fails with the same message as a missing connection, which tells you to connect Codex in workspace settings. Reconnecting there fixes it. If ChatGPT rejects Sinatra's own app rather than your account, we keep your connection and retry instead.

Before this, a reply the screen flagged stopped the run and marked the task failed, so one false positive halted work mid-task. Now the flagged message gets a short refusal where it was sent, and the task carries on with whatever comes next. Flagged issue text, review feedback, and the message that starts a new task still stop it. On Linear the flagged comment stays on the issue: while it is among the issue's five most recent comments, later turns in the same run are refused too, and a fresh run that finds it, such as after a day idle, stops the task; delete or edit it to continue. A GitHub issue comment, Slack message or API reply that arrives after a task went idle is still screened as a new task would be and can still stop it; on Linear, the message that starts each run, whether it opens a task or wakes one up, is now also screened on its own, even when it isn't among the comments Sinatra reads back from the issue.

Before this, when the prompt-injection screen, or the check that Sinatra can read the issue from its sandbox, refused a follow-up on a task with no open pull request, the run ended there and any message waiting behind it was dropped without a word. Now each waiting message starts a fresh run, which runs the screen again as a new task would. On Linear that screen re-reads the issue's recent comments, so while the flagged comment is among them, expect the waiting message to be refused too, in its own session, rather than run. On GitHub the earlier comments aren't re-read, so the waiting message usually runs.

Update: a follow-up the prompt-injection screen flags no longer ends the run. It is refused on its own, the task keeps waiting, and the messages behind it run in the same run. On Linear they are still refused, each in its own session, while the flagged comment is among the issue's recent comments. The sandbox-check case above is unchanged.

Before this, the session only got the "Finishing what I'm working on first" note and then sat open until Linear marked it stale, with nothing to say the message had been dropped. Now it closes with a short reply asking you to send the message again if you still need it. A session with a newer message that will still run doesn't get the reply, because that message gets its own turn.

Successful refreshes still save their new tokens even when storage is slow. If an interrupted attempt never finishes, reconnect that subscription in Your credentials rather than wait for another automatic retry. We treat a timeout as an unknown outcome because the provider may already have rotated the token.

Anthropic answers a model your account can't use, such as one your organization has disabled, with a "not found" error. On the Claude Code engine we read that as a rejected credential and told you to re-add your API key, which wouldn't have helped. On oh-my-pi the task only said an internal error had occurred. Both now say which model was turned down and point you at your model settings. We don't switch models for you, and replying won't help until you pick one your account offers.

ChatGPT plans don't all offer the same Codex models. A free plan has no GPT-5.6 Sol, so until now every unconfigured task on one failed within seconds, and the ticket only said an internal error had occurred. We now check your account's model list with Codex once a day and pick its highest-ranked model that Sinatra supports. On plans that list newer models, that means your default moves off GPT-5.6 Sol too, for example to GPT-6 Astra. If Codex still turns a model down, the task stops and says your account doesn't offer it, and we check the list again. The message tells you whether replying will retry on another model your account offers, or whether you need to pick one. A model you chose yourself is never switched.

Before this, OpenRouter's "Key limit exceeded" answer was reported as rejected credentials, with advice to re-add the key. The key was fine, so following that advice only removed a working key. The message now says Sinatra kept the task and its agent session, and points you at the fix: raise the key's limit or add credits in OpenRouter, then reply on the task to continue. Sinatra won't resume these runs on its own. Any other 401 or 403 from OpenRouter still reads as a rejected key.

We no longer read reset times from the old usage limit reached|<epoch> text. Modern messages such as resets 3pm (UTC) and structural retry-after values still work. If an older CLI emits only the retired format, the quota failure remains a quota failure, but its reset time is unknown.

We stop waiting when either response headers or the response body takes too long. The timeout is a transient failure, not proof that your connection was revoked. This does not bound encryption or database persistence, and existing refresh serialization remains in place.

An ordinary reply, asking Sinatra to stop a test and report its last line, scored 54% likely to be an attack, and the run was stopped. Because every later reply on the issue re-checked that comment, the task then stayed stuck. Below 80%, a flag is now logged and the run goes ahead. That's a small loosening: an attack the classifier is only moderately sure about would get through, though every attack in our test set scored above 80%. A comment it is sure about still stops the run, and keeps stopping later replies until it's removed. The security page now lists this next to the existing case where a classifier error lets a run go ahead.

Update: within a run, a flagged reply no longer stops the run. It is refused on its own and the task keeps waiting. A GitHub, Slack or API reply that arrives after the run went idle still stops the task. On Linear the comment stays on the issue, so while it is among the issue's recent comments later requests are refused the same way, and a fresh run that finds it is still stopped, until it's edited or removed.

Until now the only sign was an error in the issue's agent session, and if you missed it the work never started. The email goes to the address on your Linear account, at most once a day per workspace, and only when nothing in the workspace links that account; a teammate who's linked but isn't a member yet needs an invite instead, and gets only the note in Linear. That note used to say "assign me again", which does nothing while the issue is still assigned to Sinatra. It now says to mention Sinatra in a comment, which does start the work.

Before, when we couldn't find the agent's own reply, we posted the answer ourselves, which could leave the same answer in the thread twice. This is a tightening: you now see an error saying the reply couldn't be verified, so check the issue or PR before you retry. A reply we can't check only because GitHub or Linear is briefly unavailable still counts as posted.

The lookup we used to read a newly opened PR asked GitHub's CLI for a field it doesn't offer, so it failed on every call and a task could miss its own pull request. We now read the PR through GitHub's API. Matching is also stricter: the ticket has to appear as a whole word in the branch or title, so sin-33 no longer matches sin-330, and a PR picked out of the agent's output has to come from the task's repository or one enabled for your workspace.

Linear opens a new agent session for every @mention, and three things went wrong with it. On an idle task, that session could arrive without your comment, so nothing ran. A reply under one of Sinatra's comments that also @mentioned it was handled twice. And while the agent was working, the mention could be folded into the running turn instead of answered where you asked. Now, if Sinatra is busy, the new session says right away "Finishing what I'm working on first, then I'll pick this up here." and your message runs as the next turn.

This was meant to happen already, but the check compared the wrong form of Sinatra's GitHub name, so those threads stayed open. A thread where someone else had the last word stays open, so a question you asked there doesn't disappear.

The portal records a cancellation in a way we weren't reading, so the card kept showing the subscription as renewing. Nothing about billing itself was wrong: the subscription still ended at the end of the period. A cancellation made before this fix only shows once Stripe next updates that subscription, which can be the day it ends.

Before, a review with no summary text, left on a task that had been idle for a day, woke the task with nothing to act on, so it sat waiting for another comment. And on oh-my-pi, a review sent while the agent was working reached it as plain text without the inline comments. That review now runs as the next turn, with its comments, and anything sent after it keeps its place behind it.

Completed-looking output can arrive before the agent process is killed. We now report that failure instead of accepting the output as a successful run. Temporary connection failures still retry, and RPC sessions and Claude Code keep their existing completion rules.

A long-running command can stay quiet while it works. We keep monitoring the agent and send one warning per quiet stretch; new output lets a later quiet stretch warn again. The existing maximum runtime and confirmed failure checks still apply.

Before this, a workspace whose only model access was Anthropic defaulted to Claude Code with Opus at high effort, and oh-my-pi runs without a model used Sonnet 4.6, which costs less per token than Opus on your API key. Workspace, repository, and personal settings still take priority, so set the engine and model there to keep the old pairing. Runs that don't set an effort now default to medium instead of high.

If your repository has an extensionless .sinatrarc, rename it to .sinatrarc.json without changing its contents and commit the rename on the default branch. Commit the same rename on any task branches you still use: existing PR checkouts read the configuration at their verified head commit. Model choices, test hooks, and sandbox settings stay in the renamed file. The repository configuration page links to .sinatrarc.json for editing or creation.

We still display recognized five-hour and weekly windows in either response position, even if another window cannot be classified. The usage panel calls the affected caps unavailable rather than claiming ChatGPT reported no windows. Automatic resets will not spend a credit without a recognized five-hour cap.

We keep the existing task, workflow, and selected code repository when the issue moves or its repository is renamed. We no longer adopt a historical task using its repository name and issue number alone: its permanent issue identity must be verified. The GitHub installation must still belong to your workspace.

We still resume a saved session when its recorded engine matches the current one. For older tasks without that record, the agent starts without the prior conversation context; the task's existing branch and PR are not reset. Implementation and self-review continue to use separate saved sessions.

Wallet top-ups and automatic recharge are no longer available. Every account needs its own model credentials; provider charges and subscription limits apply separately from Sinatra's seat fees. Token and cost diagnostics are estimates, not amounts owed to Sinatra, including when a personal subscription covers the usage. Seat checkout, the billing portal, and subscription invoice verification remain available.

You no longer need each teammate to save the same personal preference. Personal preferences and explicit repository settings still take priority, and each member still needs compatible personal credentials or a workspace API key. Changes apply to subsequent turns, not agents already running; reset the setting to return to automatic selection.

We keep verified workspace identities, including durable bindings that survive a personal token disappearing. Older connections without workspace identity proof need to reconnect from that workspace's settings before delegating or replying to a task thread. Conflicting identity claims are refused, and removing a member still removes their authority to run work.

We keep saved plans, requirements, and approved-plan review evidence when an old discussion resumes. Ask for a plan or discuss the requirements in the conversation; code work still requires task admission. Remove the old planning and brainstorm blocks when you next edit .sinatrarc. Current workers ignore them with warnings. Runs already pinned to an older worker keep their earlier behavior until they finish.

We ask for confirmation before stopping the current run, removing its sandbox and branch, and closing its old PR. This starts fresh; it does not resume the previous environment. The new run still needs valid access, model credentials, and billing eligibility. If the task has no recoverable source session, restart it from the original conversation instead.

We keep both phases in the same Agent Updates comment, but you can now see where implementation ends and self-review begins. Linear updates are unchanged.

We previously processed inline review feedback without showing that we had received it. An eyes reaction now tells you we saw the submitted review while the next step is being decided. The reaction acknowledges receipt, not that a new agent turn has started, and a GitHub reaction failure does not stop the feedback from being processed.

If you previously chose managed access, we keep the model step open until you connect a personal subscription or a workspace owner or admin adds an API key. Members without a connection now keep the setup prompt, even if they dismissed it before. Personal connection flows and workspace key permissions are unchanged.

Connect a personal model subscription or ask a workspace owner or admin to add an API key before starting another task. Workspace seat fees and free-task limits stay the same; model charges and subscription limits remain with your provider.

Repositories and personal preferences that select engine: "opencode" must switch to claude-code or oh-my-pi before running again. For Codex models on oh-my-pi, change the openai/ prefix to openai-codex/; Anthropic and OpenRouter models use their listed oh-my-pi slugs. Switching engines starts a fresh conversation because OpenCode sessions cannot be resumed by another engine. Historical usage and billing records remain readable.

We removed historical wallet balances from workspace billing. Seat checkout and the billing portal still work, and token/cost diagnostics remain available. Older paused tasks without a recorded reason offer credential and subscription settings instead of assuming a funding problem. After you resolve the block, reply on the source ticket to retry.

We already did this for a dropped connection, and it still needs a saved session to resume. A second failure stops the run, and an authentication or quota error is never retried this way, even when its message mentions DNS. Claude Code runs are unchanged.

This is what lets a conversation start before anyone has named a repository. When the repository is known as the sandbox is created, its pre_clone commands, snapshot_name and sandbox.env still apply then. post_clone no longer runs: the agent reads .sinatrarc.json, snapshot Dockerfiles and setup docs as hints, so if your setup depends on post_clone, describe it in your README or AGENTS.md too. A repository the agent picks later in the conversation doesn't get its sandbox.env values, on that turn or later ones.

A question that needs no code no longer waits on a repository at all. A single connected repository is still used automatically, and repo: owner/name still pins one. Otherwise the agent works from your repositories' names and descriptions and can ask which you mean. The sandbox's GitHub token now covers every repository connected to the workspace, not only the task's, so the agent can read across them. It still can't reach repositories you haven't connected.

A question gets an answer in the same thread, and only code work goes through task admission, so on the free tier a question doesn't use one of your daily tasks. Starting over now takes the literal command restart; "scrap this and start again" continues the conversation instead. With oh-my-pi, a reply sent while the agent works can reach the running agent, which stays warm for up to 45 minutes between turns.

We list the resets ChatGPT reports with their status and expiry, nearest expiry first. Use a reset spends one of your ChatGPT account's banked resets and refreshes your rate limits; the reset applies to the whole account, including usage outside this workspace. If ChatGPT doesn't return expiration details, the panel says they're unavailable.

We now recognize an explicit Codex usage-limit error even when the agent reports no HTTP status. Previously, that failure could appear as an internal error. The message tells you to wait for your connected ChatGPT subscription's limit to reset and reply to retry, or select a model with available usage in workspace settings. When the provider reports a reset time, we include an estimate.

When connecting your ChatGPT subscription, you can copy the approval link to open it in another browser. Clicking it still opens a new tab, and Sinatra keeps waiting for approval in the original dialog.

On GitHub issues, we previously folded the whole Agent Updates comment when a run ended, so you had to expand it to see why work stopped. The final update now sits below the collapsed thoughts. Plan and requirements comments keep their existing formatting.

A rate-limited search used to come back as no tickets, which read as having nothing open to delegate. Now the picker says it couldn't load tickets and to try again in a moment. The error replaces the whole list for that load, Linear tickets included, and we don't retry the search for you, so reload after a minute.

A confirmed PR merge now marks its workstream completed even when an issue is closed at the same time. Later merge deliveries and scheduled reconciliation can also correct a cancelled workstream that still has a PR attached.

Cancellation still stops and archives the sandbox. It no longer overwrites a confirmed merge with a cancelled outcome.

A plan-only reply could say that a document was written without delivering the document itself. Once the agent's reply is posted, we now attach the plan or requirements file it cites.

The skills also tell the agent to publish the full document as its answer, rather than stop at a sandbox file path. File-size, credential, and path checks still apply; a document that cannot be attached gets an explicit note instead.

A PR can merge while an agent is still working on a follow-up. We now report the branch and pushed commit that missed that merge, so you can open a follow-up PR instead of assuming the changes reached the base branch.

The check also handles squash merges. We do not open another PR automatically, and an unchanged or deleted branch does not produce a missing-commit warning.

Our sandboxes mix a command's warnings into its output, so a stray CLI notice could break the check that the agent can read the ticket, and the task stopped as if the ticket were unreadable. The same notice could also end up in the default-branch name we look up when a clone doesn't record one. Both lookups now ignore warnings; a command that actually fails is still treated as a failure.

We report missing promised behavior with repository evidence and keep post-deployment promises marked unverifiable until observed. Authorized scope changes can withdraw criteria; saved plan text without approval proof gets an explicit skip. Small follow-ups use a bounded acceptance pass, and public reviews withhold confidential details. This adds review coverage, not mandatory planning or another readiness or merge gate.

We leave the agent idle until the requester's GitHub identity and workspace membership pass the existing check. The public reply is the same for an unknown account and a known non-member; account-specific recovery stays behind sign-in. Passive reviews and unrelated comments stay silent, and repeating the same refused request uses the existing short comment-deduplication window.

Choose openai-codex/gpt-6.1-sol in your model preferences or .sinatrarc, with low, medium, high, xhigh, or max effort. It needs a Codex connection. The sandbox's oh-my-pi pin moved from 18.4.3, which doesn't list the model, to 18.4.4, so a sandbox created before the update keeps the old runtime and can't run it.

Choose anthropic/claude-sonnet-5-5 in your model preferences or .sinatrarc, with low, medium, high, xhigh, or max effort. Use a new workflow chain with an updated OMP sandbox; existing runtimes do not upgrade when you change model preferences. We kept Sonnet 4.6, existing Opus models, and the default aliases unchanged. The new option uses the existing Anthropic credential route and does not add managed model access.

The label only starts work on issues. We now leave one comment on the pull request with links to the repository's issues and the new-issue form, then take the label off the pull request. Other labels, and labels applied by bots, still get no reply.

You do not need to add another “build it” comment when the delegated ticket specifies implementation scope and acceptance criteria. We kept discussion, brainstorm, and plan-only tickets conversational. Ambiguous follow-ups still need clarification, and code changes still require task admission.

The first-PR email goes out when the pull request opens, before anyone knows whether it was worth merging, so this one waits for the merge. It is sent once per account, ever, and is never sent if you have started another task since the merged one, gone back to an older one, or reopened the merged one. It counts as a setup reminder, so turning those off stops it too. The link opens the picker on the merged repository's open GitHub issues when it has any; otherwise, or if that repository is no longer enabled, you get the usual list across every repository, and Linear issues are never narrowed.

This tightens the 26 September change that made setup wait for your repositories to sync: a sync that found none no longer counts. The GitHub step still shows as done once the app is installed, but you can't pick a ticket until at least one repository is enabled, and repositories you later remove on GitHub count as gone too. If the picker finds no open issues, the last step now offers "I don't have an open issue yet" to finish; otherwise you can skip it to pick a ticket later or to just look around.

We check the repository, branch, and head before running checkout-bound verification. If the checkout cannot be verified, we explain the skip rather than use another tree or an earlier test command. Test repairs on this path now commit and push the same PR branch before we verify it again. This tightens verification for the existing agent-owned rollout; it does not expand access or enable the rollout for more users.

Some of these failures used to give a rough "resets in about 2h"; now the message gives a clock time in UTC, and if the provider doesn't say when the quota resets, the message says so. The message also links to your credential settings so you can switch to a different subscription or API key and reply to retry right away. On a paid plan whose only connection is the exhausted subscription, and whose prepaid balance can cover a run, it explains how to run the task on managed credit instead. This entry first said a task could also pick itself back up a couple of minutes after the reset. That stopped on October 2: such a task now waits for your reply, as a later entry explains.

Before this, an agent could finish with "the report is in /tmp/report.md" and leave you with nothing to read, because the sandbox is private to the run. Small text files are now attached under the reply, up to five files, each under 20 KB and about 40 KB in all. Binary files, larger files, anything that looks like a credential, and symlinks that lead outside the sandbox's working folders are not attached, and the reply says which ones were left behind. Files tracked in the repository are left alone, including ones the agent edited but didn't push, so a summary that names the code it changed doesn't paste that code into the comment. PR descriptions and comments the agent posts itself while it works aren't checked; for those we rely on the agent's instructions, which now tell it to put documents in its reply or commit them.

Before, a run that ended with the agent explaining why it was blocked still counted as done, because it had written something back. Now the task is marked failed, and the agent's explanation is posted with the error so you can see what stopped it and try again. This only applies when the agent states the outcome in its final report. Answer-only turns that finish without a PR still complete normally.

We also stop retrying the dead agent once its diagnostics show that the sandbox is full, so the failure arrives sooner. You can reply to try the task again, though the same workload may hit the disk limit again.

Before this, same-day follow-ups on the managed task were free and unlimited, so one task could keep running on our keys all day. That is the loophole this closes, and if you relied on a fourth run you will notice: the task stops with the usual daily-limit message. Runs on your own API key or subscription, and every run on the Monthly plan, are not affected.

We match members using their verified email. If we cannot match you, connect your own Linear account from onboarding or the dashboard; workspace membership is still required before you can delegate.

Until now, a merge removed the PR from the task. The dashboard could show that the task merged, but not which PR shipped it. We have also restored the links on tasks that merged before this fix. If we can't match a task to a merged PR on GitHub, it stays unlinked.

Before, onboarding could count GitHub from one workspace and a model key from another, then send you to a workspace that couldn't run your first task. Now every step is checked against the same workspace. Right after you install the GitHub App, the ticket step now waits until we have finished syncing your repositories. If you belong to several workspaces and none has everything, onboarding shows the one closest to done and asks for the steps it's missing, even if you connected them in another workspace.

Before, every Linear task in a workspace borrowed a single member's read-only Linear grant, and if that member revoked it or reconnected from another Linear organization, Linear tasks stopped with auth_required until someone granted it again. That shared grant is gone, and the Linear settings card no longer shows a separate sandbox read-access line.

This is also a widening, so we say it plainly: the sandbox can now read whatever the Sinatra app can see in your Linear workspace, not only what one member could, and it can add comments and attachments to the task's own issue, and edit or reply to the comments Sinatra posted for this task. Tasks started from GitHub issues no longer get Linear access in their sandbox at all. Nothing else in Linear is writable from the sandbox. The person delegating still needs a linked or matched Linear identity and workspace membership.

Since 28 August a delegation from a Linear account that was never linked through Linear sign-in has been refused. We now try an email match first, when the Linear app is installed and again when an unmatched person delegates, and only a one-to-one match counts: an active Linear user, an email no other Linear user or Sinatra user shares, and a Sinatra account that is a member of this workspace. Anything ambiguous is skipped, and the person links their account by hand as before.

Owners can see every match under Linear in workspace settings, and members can see their own. An email match can be removed there, and we will not re-create it until that person connects their Linear account themselves. The dashboard's ticket list still needs your own Linear connection to show tickets assigned to you, and now offers a button for it in place of a pointer to Settings.

Before, delegating right after connecting GitHub could land before the repository list was ready, and Sinatra would reply that it couldn't tell which repository the issue was for. Now the session says the sync is still running and picks the issue up once it finishes, with no change to the issue needed. If the sync takes longer than 30 minutes, Sinatra stops waiting and asks you to reply in the session once it's done.

Until now this was only switched on for our own team. The trailer uses your GitHub noreply address, never your email, and only credits someone who is still a member of the workspace. If we can't match the delegator to a Sinatra account, for example a Linear user who never linked their identity, the commit goes out without it. Repos that set core.hooksPath (Husky, a tracked .githooks/) are left alone and get no trailer. There's no setting to turn it off yet.

In those organizations every delegated task stopped while Sinatra was still fetching the issue, and checking the issue for new comments during a run failed the same way, because both used the same query. We now fetch only the fields we use from each comment: its text, time, and author.

Before, the error only told you to add an exact Repo: owner/name line to the issue description and try again. Sinatra now lists up to ten of your connected repositories in the session and treats your reply as the answer when it guesses again, so "the api one" or a misspelled name can be enough. It is still a guess from what you wrote, so an exact Repo: owner/name, in the reply or in the issue description, is the way to be certain.

Since 19 September every repository was written to the list before the slower per-repository read, but one row at a time, so a task delegated in that moment could still see a partial list and pick the wrong repository. Until the sync finishes a task now sees no repositories at all; from 25 September it waits for the sync instead of asking which repository you meant. Repository descriptions still fill in after the list appears. The change has a cost: repositories are now tied to their GitHub repository ID, and personal repository settings saved in the dashboard before this change were set aside rather than carried over by name, so check the repositories you had customised and set them again.

When a finished Agent Session could no longer display an error, a rejected new task could look ignored. We now post that quota explanation on the issue itself, including how to submit the new task.

If the first attempt stopped early, for example because the issue could not be fetched, your reply was treated as a follow-up on a task that had never been set up. That skipped the step that records who started the task, so billing could not find your personal model connection, treated the run as one on the managed key, so it either used the workspace's daily managed task or stopped with a top-up request. The retry now finishes that setup first. Work that really does run on the managed key is billed as before.

They are spelled anthropic/claude-opus-5-5, openai-codex/gpt-6-luna, openai-codex/gpt-6-sol and openai-codex/gpt-6-astra, and they are not on claude-code or opencode yet. Opus 5.5 runs on your Anthropic key, or on ours for Monthly-plan tasks; the GPT-6 tiers need a Codex subscription. Nothing picks them by default: an unconfigured Codex subscription and free tasks stay on GPT-5.6 Sol. The sandbox's oh-my-pi pin moved from 18.1.8, which doesn't list them, to 18.2.10.

Before, a dropped socket mid-run ended the phase with a generic internal error, even after the agent had already done several turns of work. The resume picks the session back up where it stopped and posts a short note saying so. It happens once per agent run, and only once the session has started: a second drop still fails the task, and usage-limit and credential errors are handled as before. This covers the oh-my-pi and OpenCode engines, which is where these drops showed up.

Until now the ticket picker was switched on only for our own team. Setup ends on the same step: after GitHub, Linear and model access, you pick a first ticket or skip it, and you won't see it if you've already run a task. The picker only delegates open tickets that are unassigned or assigned to you, and Linear tickets are read through your own Linear connection, so they appear only once your Linear account is linked. After you delegate, the task list opens straight away with the ticket as a pending row, and the run takes it over once your tracker reports it back, usually within a few seconds.

Failures and waiting reviews were already posted to the Linear or GitHub thread; the email is for the hours you are not watching it. Task alerts go to whoever delegated the task, or to the workspace owner when we cannot match the delegator to a workspace member, and billing alerts always go to the owner. Setup reminders stop after two, or the moment you act, and nothing older than a few days is ever sent, so an account set up weeks ago hears nothing. Every email has an unsubscribe link in the footer that works without signing in, and the two categories, setup reminders and task alerts, can be turned off separately under your workspace settings. Task alerts are capped at five a day. Invitations are unchanged.

This is a tightening. Before, one Linear session could keep taking on unrelated work without any of it counting against the daily limit. We now classify each follow-up before the agent runs: fixes, review feedback, test failures, retries and refinements of the same objective carry on as before. New work starts only if you still have a free task left today, and a follow-up that mixes both or is unclear gets a reply asking you to send one request and say which it is. Runs on your own key or subscription, and paid runs on ours, are not affected.

The follow-up's final check looked for an open pull request on its branch, found none because you had just merged it, and posted a "no PR was found for that branch" error on the ticket. A task that already had a pull request now keeps it and completes normally. Anything the follow-up pushed after the merge stays on the branch rather than in your default branch. The error still appears when the agent pushes commits and no pull request ever existed.

Before, one long ticket title could widen the table past the window, so reaching a task's phase or pull request meant scrolling sideways. Narrower windows now switch to the stacked cards phones already used, at a wider breakpoint than before. The task detail page still shows the whole name.

Until 15 September an unconfigured Codex subscription ran opencode with gpt-5.5, and for the four days after that it ran GPT-5.6 Terra at high effort, the model free tasks had used since July. Medium is a lower reasoning effort than the high those runs had. On your own subscription, an agent.effort you set is kept when we pick the model, so setting high gets it back; setting an engine or model turns the automatic pick off entirely. Free tasks on our key always run this fixed model and effort, whatever your configuration says.

We store every repository name in lowercase, but GitHub reports it in the case you registered it with. The dashboard recorded who clicked under the lowercase name, and the webhook that GitHub sent back looked for it under the original case, so the two never matched. On a repository like Acme-Corp/Widget the issue got assigned and labelled and then nothing else happened: the spinner ran out and the task list stayed empty. Repositories whose names are already lowercase were unaffected.

Both sides now agree on one spelling. The same mismatch also kept an issue that was already running from being hidden in the picker, so it could be offered twice; that is fixed too.

When a sandbox or credential operation failed after a task reached review, the failure bookkeeping could raise a second error and obscure the cause that needed attention. We now leave the open pull request state intact and show the original safe failure message; internal details that are not approved for the ticket remain redacted.

Both phases used to be on by default, so a vague ticket paused for a requirements document and a well-specified one paused for a plan you had to approve. If your team relied on those pauses without ever setting them, they stopped on 19 September; turn them back on with planning.enabled or brainstorm.enabled in .sinatrarc, or in your personal settings for the repository. Configurations that already set either phase explicitly are unchanged. Approving a brainstorm still leads into planning, even when planning is off.

Your repository list was built from what GitHub told us at install time and kept up to date by webhooks. When one of those deliveries went missing, the catalog drifted: a repository you had removed from the grant stayed in the sidebar, and the settings card could read something impossible like "2 of 1 enabled". Uninstalling the app was worse, because nothing archived the repositories on the way out and there was no install left to compare against.

Settings now reconciles against the live grant every time you open it, and uninstalling archives the catalog. Two narrower repairs came with it: renaming a repository onto a name we still held used to fail and retry forever, and re-enabling a repository in the picker overwrote the description we had written for it. "Manage repos" in settings also goes straight to the GitHub install page now, since that is where the grant actually lives.

Installing the GitHub App is already where you pick repositories, so there was never a second place to choose them. What there was instead was a gap: we read each repository in turn to learn what it is, and until that finished the workspace looked empty and told you to manage repositories in Settings, which would not have helped. Two changes close it. Every repository now lands in the catalog up front, before the slower per-repository read, so a task delegated in those first seconds is much less likely to resolve against a half-built list. And the overview, the sidebar, and onboarding all show the progress while it runs. Workspaces without Linear also stop being told to assign a ticket in Linear — they now get the Sinatra label (sinatraai) instructions that actually apply to them.

Getting there is shorter too. Onboarding used to ask you to choose between a personal account and an organization before sending you to GitHub, which is the screen that asks the same question and is the only one that knows which organizations you can actually install on. That choice is now a single button, and the accounts you see are the ones GitHub offers you.

Some repositories gate merges on a commit status posted by whoever verified the branch rather than on a hosted CI run. Sinatra's own repository works that way, and until now an agent run could finish the whole verification suite inside the sandbox and still fail on the last step, because the installation token could read statuses but not write one.

Existing installations will see a request to approve the new permission. Nothing changes until you approve it, and nothing that worked before stops working if you never do — this only affects repositories whose merge gate is a commit status. Sinatra still does not merge your pull requests; the status it writes is the evidence, not the decision.

Before this, the dashboard applied the label or the delegate as Sinatra, and the tracker's webhook carried no human identity. The run then had no member to resolve, so it never reached your personal Codex or Claude connection and never picked up your per-repository overrides. It fell through to the workspace's managed key instead, and stopped if that had no balance.

The dashboard now records who clicked and hands that to the run, so your connection and your settings apply. Two things follow from that. Starting a Linear ticket needs your Linear identity linked in Settings first — we would otherwise have no member to attribute the run to, and refusing is better than starting work that silently stops. And a label applied directly in GitHub still runs as whoever applied it, which is deliberate: reading the actor off the assignee field would let one member spend another member's connection.

The picker read one page of GitHub search results per bucket and then filtered out pull requests, issues already labeled for Sinatra, and issues that already have a run. On busy repositories that left the list short or empty. It now requests further pages until it has ten available tickets or GitHub has no more results.

When this shipped, the picker was still switched on only for our own team. It opened to every workspace member on 23 September.

Previously, the picker searched GitHub's global issue index and then discarded results outside your connected repositories. The picker now searches those repositories directly. Issues already delegated to Sinatra still stay out of the list.

When this shipped, the picker was still switched on only for our own team. It opened to every workspace member on 23 September.

Linear requires two separate grants: one for the workspace integration and one for the person delegating work. We now chain those authorization screens behind a single onboarding action and verify the resulting read access before marking Linear complete. Linear remains optional, but choosing it no longer leaves the identity step hidden in Settings.

The picker ranked Linear and GitHub tickets as one list, and it stops adding team tickets once you already have three of your own. If Linear had three tickets assigned to you, every GitHub issue fell off the list — the GitHub tab never appeared.

Each tracker is now ranked on its own, so connected GitHub repos always contribute issues you can pick up.

When this shipped, the picker was still switched on only for our own team. It opened to every workspace member on 23 September.

We store repository names in lowercase, but the settings picker saved them in the case GitHub reports, so on a repository like Acme-Corp/Widget the save failed. Nothing told you: the spinner stopped and nothing said why. The picker also showed such repositories as not enabled even when they already were, which is usually what made people tick the box and save. Both are fixed, and if a save does fail, the dialog now stays open with your selection and shows the error.

This is a tightening. A Sinatra label applied by someone outside the workspace, or by a bot, used to start a run that then stalled asking for payment; it now stops straight away with a message saying only invited members can run tasks. Comments were gated on GitHub organization membership rather than Sinatra membership, so an org member you never invited could steer a run, and anyone able to reply on a Linear thread could do the same.

The check is now membership in the Sinatra workspace: on GitHub we match the commenter to the GitHub account they sign in to Sinatra with, and on Linear we match the replier's linked Linear account. That also means an outside collaborator you have invited can now drive a run from a comment. Someone with a Sinatra account who is not a member gets an access request filed for the workspace owners.

If you're an admin who needs those controls, the owner can transfer ownership to you from the Administration section of settings. Any other owner- or admin-only action that fails now names the role it needs instead of a generic error.

Before, we refused the mismatch and recorded nothing, but GitHub had already installed the app, so retrying only led to GitHub's "already installed" settings page and left you on an empty dashboard with no way forward. The organization is still subject to the usual access check: if it already belongs to someone else's Sinatra workspace, you are sent to request access rather than joined automatically. Installing on a different person's GitHub account is still refused.

The inbound screen was reading "enable this for user X" as privilege escalation and killing the run. Real override and secret-exfil attempts still stop the run.

Update: in a reply, a flagged attempt is now usually refused on its own rather than stopping the run (a GitHub, Slack or API reply after the run went idle still stops the task); in issue text it still stops the run.

The model is the same Claude Sonnet 4.6; only the harness around it changed. Connected API keys and subscriptions still pick their own default when you set neither engine nor model, so the runs that notice are mostly Monthly-plan tasks on our Anthropic key with nothing configured. One kind of config breaks: a .sinatrarc or personal override that names a bare Claude model such as sonnet, opus or haiku without an engine, for the agent or for planning and brainstorming, is now rejected, because those names only exist on claude-code. Add engine: claude-code to keep it running as before.

In a workspace with several people, the overview had become a list of other people's work. The Tasks page and the recent activity feed still cover the whole workspace, so a count on the overview can be smaller than the list it links to. A task counts as yours when you are the person who delegated, labeled, or mentioned it.

The old page undercounted what a workspace pays for: owners, admins, and members who only review work each count as a seat on Monthly, whether or not they start anything. Billing has counted seats this way since August 29; this fixed the description, not the bill.

The same pass corrected the free tier to one shared pool of five tasks a day with at most one managed, and fixed the setup steps, model defaults, sandbox retention, and the GitHub App permission list. It also stopped the docs implying that a ready PR means its tests and self-review passed.

Connected accounts no longer fall back to an unavailable-usage message when xAI returns its billing configuration inside the standard response envelope. Unified-billing accounts use their monthly included quota instead of an inferred empty weekly window.

Tasks you triggered were already running on your own subscription, so nothing was actually paused. Only the settings card was wrong: it worked out your credential tier without looking at who was signed in, saw no workspace key, and assumed the workspace was on Sinatra's managed key with a $0 wallet.

The card now uses the same inputs as task admission. Members without a personal connection and no workspace API key still see the wallet with Top up and Save card, because their tasks do run on managed credentials.

The first pass still posts leftover P0/P1 comments. Those stay on the PR. What changed is the check: a response that does not introduce new issues no longer leaves sinatra / review stuck red from the original findings.

This is dogfood, not a general launch: the Settings card only appears for allowlisted GitHub logins. Everyone else keeps the Claude and ChatGPT connect flows they already have.

A SuperGrok connection is personal to the member who linked it. It does not debit the workspace wallet, and it only works with oh-my-pi — not OpenCode or Claude Code.

Connect already lived on Settings; without the bars you only found out the pool was empty when a grok-4.5 or grok-4.6 run failed. Weekly credits include Chat, Grok Build, and API when the billing payload has them. Unified-billing accounts show monthly included instead.

A flaky billing read degrades to a note. It does not block connect or disconnect, and it does not send inference traffic to the billing host.

Clicking through from Slack used to land on a blank plan/requirements section, because those bodies lived only as Linear or GitHub comments and Slack has neither. New publishes and in-place refinements store the markdown on the workstream row; Linear and GitHub comments stay copies.

Threads that finished before this still have empty panels until the agent writes a plan or requirements again.

The step-by-step narration used to stay fully expanded above everything that came after it. A follow-up now starts a fresh Agent Updates comment rather than appending to the finished one. If GitHub rejects the collapse, we retry it the next time the task picks up work, and that follow-up waits on it: if the retry fails again, the follow-up does not run.

One rough edge remains: a failure message is posted into the same comment, so it ends up inside the collapsed section. Expand it to see why a run stopped.

A fork that you selected during GitHub setup was previously omitted from both the repository picker and the initial repository sync. We now include active forks in the picker, its repository count, and sync processing; archived repositories remain excluded.

Those bars used to live on the old workspace-level ChatGPT connection. When connect moved to a per-member setting they did not come along, so a connected subscription looked like a binary on/off.

Refresh still talks to ChatGPT, so a flaky read degrades to a note instead of blocking the rest of settings. Banked-reset redemption stays on the platform account, not on yours.

The check sits on the commit next to your CI, so you can glance at it or make it a required check. We ignore our own check when watching CI, so a failing review does not start a CI-fix loop.

It needs Checks write access on the GitHub App. Existing installations have to approve the updated permission; until they do, the check is skipped and the rest of the run carries on.

Settings had flagged these connections as deprecated since personal connections arrived on September 2, and this removed them outright. If your workspace still had one, tasks stopped using it, and each member who relied on it needs to connect their own subscription under Your credentials in Settings. A workspace-level connection no longer counts as model access during onboarding either.

Each comparison links its source material, states when it was checked, and calls out where the other product may be a better fit. The homepage table is shorter on purpose: it keeps the meaningful differences and links to the full definitions and sources when you need the detail.

Joined workspaces stay immediately accessible. The new overview message appears once per workspace, can be dismissed, and explains the credential setup before a member starts work.

It does not change which credential runs use; it makes the workspace's current setup visible and keeps the optional subscription flow in context.

Entries are grouped by month on one page, while individual noindex links make a specific change easy to share without competing with the index in search. This is a curated record of changes that affect your workspace, not a copy of the commit log.

The application asks for your company URL and team size, then sends the request to us for a manual decision. Approved teams still check out with a card, and the seat price returns to the regular rate after month 12.

Pinning a model that none of your credentials could serve already failed before any sandbox was created. It just failed after the run had been counted against your daily free allowance, so a typo in .sinatrarc cost you a task. The check now runs first.

The same change treats a workspace OpenRouter key as able to serve any model in the catalog, since it is a gateway. Workspaces on an OpenRouter key that were previously refused an Anthropic-credentialed model are not refused any more.

It is spelled fable-5-1 directly and claude-fable-5.1 through OpenRouter. The sandbox CLI pins moved up in the same change: opencode 1.18.27 and oh-my-pi 18.1.8 are the first pinned versions whose bundled model catalogs list it.

The two were counted independently before this, so a workspace could take five own-key tasks and a managed one on top.

The edge is sharper than "one of the five". Once anyone in the workspace has run a task on their own key or subscription, the managed slot is spent for the day, and a member with no credentials of their own gets nothing further even with slots left in the pool. If you were relying on the sixth task, you will notice.

The dashboard billing card shows the pool and what the signed-in member has left.

A member who reconnects the organization returns to the existing workspace without creating another installation. Everyone else gets the existing owner-approval path, so an organization cannot silently send its tasks to two workspaces.

A team where everyone already pays for a subscription no longer needs a shared key to get off the managed path. Model credentials were a workspace-level setting before this, so one key or one connection covered everybody.

A personal connection takes precedence over the workspace key and over our managed key for that member's tasks, and onboarding counts it as configured model access.

A join link is one forward away from being a link anyone can use. An invitation now expires after seven days and can only be redeemed by a signed-in user whose own verified GitHub address matches the one it was sent to.

Delivery took a second pass. The mail was built in August but was not actually being sent in production until 1 September, and it now comes from a named sender with a working reply-to. One gap we have not closed is that the invite list shows "Sent" even when a delivery was skipped or failed.

Repository configuration now leads with the defaults most teams change, rather than making you start in the config-file detail. Saving or clearing the visible preferences keeps advanced overrides that the compact form does not expose.

Once a workspace has a repository and credentials, its empty dashboard now points to the first task instead of stopping at setup. If you dismissed onboarding too early, a banner takes you to the missing GitHub or model-credential step; it does not interrupt work already in progress.

This broke handovers that used to work. Sinatra runs a task as the person who handed it over, using their Linear identity, and since 28 August it will not start when that Linear account has never been linked to a Sinatra user through Linear sign-in. Being a member of the workspace is not enough.

The run stops and Sinatra replies on the issue with a link to workspace settings; linking takes about half a minute. The first version of that reply told people to sign in, which was useless advice for anyone who already had an account, and it was corrected on 2 September.

A PR with no assignee sits in nobody's queue. Assignment is best-effort: if the person cannot be resolved to a GitHub account, or that account has no access to the repository, the PR opens unassigned rather than the run failing.

Stop was wired to the same terminal signal as cancelling a task, so it took the whole workstream down and archived the sandbox, queued follow-ups included. The running turn is now interrupted within a few seconds and no pull request is opened for it.

Anything the agent had already pushed stays on the branch. Anything it had only committed inside the sandbox goes with the sandbox.

Installing Sinatra on a GitHub or Linear org that already has a workspace used to dead-end, with nothing you could do about it from either side. That attempt now files a request an owner picks up in settings. Removing a member takes effect on their next request.

There is still no way to ask for access from inside the product. The request has to come from an install attempt.

Every task gets its own sandbox with your repository in it. It stops when the task ends and is archived a day later, and until now nothing removed it after that. The clock runs on activity rather than on archiving, so in practice a sandbox sits archived for about 29 days before the sweep takes it.

oh-my-pi was already in the catalog as hidden plumbing. Free-tier managed runs have been executing on it since July, so unhiding it changes what you can pick rather than what the product could already do. It carries the openai-codex/gpt-5.6-* tiers, which no other engine exposes; the other Codex-backed models are reachable through opencode too.