FAQ

Does Syrus compete with coding agents?

No. We don't compete with coding agents, we orchestrate them.

Coding agents -- single-purpose tools that take a prompt and try to produce a change -- are engines that execute a task. They read a prompt, work in a repository, and try to produce a change.

Syrus is the orchestration layer around that work. It decides what runs, in what order, against which repository, through which checks and review gates, and under which landing policy. Claude, Codex, Muse, and Antigravity are interchangeable provider plugins under that workflow instead of the workflow boundary itself.

The question is not "which agent wins?" It is who owns the queue, credentials, transcripts, retries, review policy, and final merge path.

How is Syrus different from Devin?

Devin is a hosted coding-agent product. Syrus is self-hosted, MIT-licensed, and bring-your-own-key. You run it on your infrastructure, store the credentials, keep the audit trail, and decide which model provider each user or repository uses.

That makes Syrus less polished than a managed SaaS, but much easier to reason about if your main questions are "where does my code go?" and "who can see the transcript?"

How is Syrus different from OpenHands?

OpenHands is a full agent environment with its own agent loop. Syrus is a thin orchestrator around existing coding CLIs such as claude-code and Codex. Syrus owns the deterministic parts: polling, cloning, branches, Workflows, PRs, cleanup, transcripts, and retries.

Syrus is also multi-tenant from day one. Users bring their own GitHub and agent credentials, and one deployment can coordinate work across many repositories without becoming a single-user desktop tool.

How is Syrus different from Anthropic's claude-code-action?

claude-code-action is a GitHub Action installed per repository. It is a good fit when one repo needs a lightweight @claude flow.

Syrus centralizes state outside GitHub Actions. It polls GitHub instead of receiving inbound callbacks, works across repositories from one deployment, keeps Job and Run history in its own database, supports scheduled and ad-hoc Jobs, and does not require installing a workflow file in every repo.

How is Syrus different from GitHub Copilot Coding Agent?

Copilot Coding Agent is GitHub-hosted and tied to GitHub's product, identity, billing, and model choices. Syrus is self-hostable and BYOK. You can run it against GitHub repositories today without handing the orchestration layer to github.com.

Syrus is not trying to beat GitHub on native platform integration. It is for teams that want the issue-to-PR loop while still owning deployment, credentials, data retention, and model choice.

How is Syrus different from OpenAI Codex cloud?

OpenAI describes Codex Cloud as coding tasks running on OpenAI-managed computers. Syrus can use Codex as one provider, but Syrus itself is the orchestration layer: it polls issues and PRs, creates Jobs and Workflows, owns branches and retries, records transcripts and diffs, and can route work to Claude Code, Codex, Muse Code, or Antigravity.

Choose Codex cloud when you want OpenAI to run the agent environment for you. Choose Syrus when you want self-hosted control over the workflow engine, credentials, audit trail, provider selection, and merge-train policy.

How is Syrus different from Google Jules?

Google describes Jules as an autonomous coding agent that integrates with GitHub and works on tasks asynchronously. Jules is the agent product. Syrus is the harness around agent products: it keeps the durable Job, Workflow, Step, and Run records, handles issue polling, PR feedback, CI-failure follow-up, scheduled work, rebases, and merge trains.

Syrus is a better fit when the important decision is not only which agent writes the patch, but who owns the queue, branch lifecycle, transcript retention, retry behavior, and landing policy. Jules may be the simpler choice when you specifically want Google's hosted coding-agent workflow.

How is Syrus different from Factory Droids?

Factory describes Droids as AI assistants and cloud sessions for development workflows such as triage, code review, QA, documentation, and incident response. Syrus is narrower and more infrastructure-shaped: it is an open-source, self-hosted issue-to-PR harness for repositories, with deterministic workflow records, provider adapters, PR follow-up, and merge trains.

Factory is aimed at a broad hosted agent-native development platform. Syrus is aimed at operators who want to run the automation themselves, keep GitHub as the review system of record, and make agent choice a replaceable adapter rather than the platform boundary.

What does Syrus cost?

Syrus itself is free and MIT-licensed. Your real cost is the model bill: the provider charges for Claude Code, Codex, Muse Code, Antigravity, or whichever agent-provider plugin you configure.

You also pay your own infrastructure cost. For a small team, that can be a Docker Compose box. For a production deployment, it is your database, worker, web process, and persistent clone/workspace storage.

Syrus records provider-reported run cost when the provider returns enough usage data to compute a dollar amount. Subscription-based or token-only tools may not expose reliable per-run USD cost; those runs still keep their transcripts, diffs, provider metadata, and workflow state, but cost charts can only show what the provider reports.

Is the agent safe to give my repo access?

Treat it like giving a powerful developer access to the repo and a shell. Syrus creates per-Workflow workspaces outside the application checkout and pushes through your GitHub token, but the current agent invocation is intentionally capable: it can read and edit the checkout and run commands needed to complete the task. The MVP assumes trusted users and trusted repositories; the workspace is not a hardened untrusted-code sandbox.

The roadmap includes stronger sandboxing and policy controls, including disposable containers per Run and tighter boundaries around what the agent can reach. Until those land, run Syrus in infrastructure you trust, use scoped GitHub tokens, keep secrets out of repositories, and review PRs like you would review work from a human contributor.

Can I use a model other than Claude?

Yes. Syrus has plugin-backed provider adapters for Claude Code, Codex, Muse Code, and Antigravity. Users choose a default provider for Jobs and future chats; repositories can override Job provider selection, and retry actions can use any provider the user has configured.

Community providers are possible as long as they can fit the same shape: run in a workspace, stream logs, return a result, and let Syrus capture the transcript and diff.

Do you offer a hosted version?

No. Syrus is an open-source self-hosted project, not a hosted product. Offering hosted Syrus would change the trust model: the operator would hold user code, model credentials, transcripts, and GitHub tokens. That is not the project this is trying to be.

Why polling instead of inbound callbacks?

Polling is less fashionable and much easier to operate. Syrus does not need a public ingress endpoint, callback secret rotation, delivery replay handling, or per-repo callback installation. The worker asks GitHub what changed and records what it did.

The trade-off is latency. Most automation runs on the next poll tick instead of instantly. For this kind of background coding work, that is usually the right trade.

Does Syrus work without GitHub?

Not today. The current product is GitHub-native: issues, labels, PRs, reviews, checks, and branches all flow through GitHub APIs.

The internal model is not inherently GitHub-only, but other forges would need adapters for repository registration, issue ingestion, comments, checks, and PR creation.

Can Syrus run scheduled maintenance?

Yes. Scheduled tasks can run recurring cron prompts or one-shot prompts against a repository. They use the same Job, Workflow, Step, and Run pipeline as issue-driven work.

Scheduled prompts should be conservative. Ask the agent to inspect a specific area and explicitly allow "no changes" as a successful result.

Can Syrus respond to PR feedback and failing CI?

Yes. For PRs attached to open Syrus Jobs, Syrus polls for new review comments and failed GitHub Checks. Review feedback creates a pr_comment Workflow; failed checks create a ci_failure Workflow. Both push follow-up commits to the same branch.

What happens when the agent makes no change?

For issue Jobs, no diff usually means no PR opens. The transcript should explain whether the agent found nothing to do, hit a setup problem, or failed to understand the prompt.

For scheduled Jobs, no diff can be the expected happy path. Syrus treats "no useful change today" as a valid outcome when the agent reports that clearly.

Where did the name come from?

See About. Short version: the name points at Publilius Syrus, whose "quick help counts twice" line fits an issue-to-PR automation tool well enough that the joke became load-bearing.