assign the issue.
come back to a PR.

Yes, with no card required. Free is 1 task at a time, plus 1 queued, with no daily limit. On Free, each request runs for up to 60 minutes. If it needs longer, Sinatra stops, keeps the changes, and picks up when you reply. Paid plans are a flat monthly price for the whole workspace, however many people are in it: Pro $20 (3 tasks at a time, plus 10 queued), Team $99 (10 tasks at a time, plus 25 queued), Scale $249 (25 tasks at a time, plus 100 queued). Enterprise has custom running and queued limits on an annual contract. A workspace connects at most one GitHub organization or personal account. On every plan you can assign as many tickets as you want: the plan sets how many run at once, and the rest are queued and start on their own as soon as one finishes. Bring your own Claude or ChatGPT subscription, or an API key.

Connect a workspace Anthropic or OpenRouter API key, or your own Codex / ChatGPT or Claude subscription. Personal connections cover only the member who connects them; workspace keys are shared with authorized members. With nothing pinned, Sinatra picks based on your connections and posts the engine, model and credential it chose into the ticket. Pin a repository model in .sinatrarc.json when you want predictability; it needs compatible credentials. Sinatra never bills for model usage. That's between you and your provider. Token and cost diagnostics are estimates, not amounts owed to Sinatra, including when your subscription covers usage.

Yes. Install the CLI with npm i -g sinatra.dev, run sinatra login and approve it in your browser, then type sinatra "fix the flaky test" inside a checkout and follow the task from your terminal. Claude Code, Cursor, claude.ai and ChatGPT can start and follow tasks through Sinatra's MCP server by signing in with your Sinatra account, also with no token to paste (on ChatGPT, starting a task needs a Business, Enterprise or Edu workspace), and your own scripts can use the HTTP API with a personal access token from the dashboard's CLI & API page. A task started this way runs like any other: it gets its own sandbox, can open a pull request, shows up in the dashboard, and counts against your workspace's plan. It's on every plan. Setup is at docs.sinatra.dev/docs/cli-and-api.

Yes, on every plan. A workspace owner or admin connects Slack from the workspace's Settings and invites Sinatra to the channels you want to use. Then mention @Sinatra in a channel with what you want done and it works in that thread: it answers questions, asks back when the request is vague, and opens a pull request when it changes code, with its progress and answer posted in the thread. Reply in the thread to steer it; a reply that mentions Sinatra always reaches it, and one without a mention does when Sinatra judges it's meant for it. Add repo: owner/name to the message if your workspace has more than one repository. Each person needs to be a workspace member whose Slack account Sinatra can match, by email or with Sign in with Slack. Slack tasks count against your plan like any other. Direct messages aren't supported. Setup is at docs.sinatra.dev/docs/configuration/slack.

Sinatra works on branches and opens pull requests. Its workflow does not merge or deploy. Your repository scripts, tests, and supplied credentials determine which external services commands can attempt to use. Merging stays with you and your CI, exactly like a human teammate, so your usual branch protection and required reviews still gate everything. Each task runs in its own isolated, short-lived sandbox: Sinatra checks out your repository, does the work there, and shuts the sandbox down when the task is done; idle sandboxes stop after two hours and are archived an hour later. Any credentials or model keys you connect are stored encrypted and used only to run the task you assigned. And we don't use your code or content to train our own models, and we don't sell it.

In an isolated sandbox that only your workspace can use. Sinatra checks out your repository there, does the work, and stops the sandbox when the task ends; a sandbox left idle stops after two hours and is archived an hour after it stops. Sandboxes are never shared between workspaces: reusing one requires either a matching workspace label or a workspace-scoped name, and anything that can't be proven yours is treated as not found. We never copy your checkout into our database. We do keep repository metadata, the branch and pull request we opened, the commit we started from, per-run token and cost totals, and the raw webhook payloads GitHub, Linear and Slack send us, which carry issue, comment and message text and, on a review comment, the diff hunk it was left on. Sandbox traffic goes through an egress proxy we run: public hosts are reachable and audited, private and cloud metadata addresses are blocked, and credentials are only ever released to their approved hosts.

It does its best work on big codebases. Each task runs in its own sandbox with the full repo checked out, so the agent reads and searches across the whole codebase before it touches anything. For very large repos, .sinatrarc.json can switch the checkout to a blobless clone so the initial clone stays fast.

It's built to. The agent is told to add or update tests for behavior changes, and to read your existing tests first so the new ones match your conventions rather than inventing a second style. Every run finishes with a written record of what it actually verified and what risk it knowingly left behind. Point .sinatrarc.json at your test command and Sinatra runs it in the sandbox once the agent is done, re-running the agent to fix failures up to twice. Tests that still fail don't block anything: the pull request stays open with the failure reported on the ticket, because a red test you can see beats a run that quietly gave up. Sinatra also reviews its own diff before marking the PR ready, and thin assertions and uncovered branches are among the things it looks for.