Most coding tools ask you to stay. Ralph Workflow is built so you can leave.

Use the agents directly when you want an interactive copilot session. Use Ralph Workflow when you want to hand off a bounded spec and stop being the runtime. Ralph Workflow runs the coding agents you already use through a controlled plan → build → verify → fix → commit loop, with defaults that work before you configure skills. It is not a replacement for Claude Code, Codex, or OpenCode; it is the autopilot that flies them unattended and leaves you with runnable, tested software you can try against the spec.

A copilot is interactive — you stay in the seat, hands on, prompting in real time. Cursor, GitHub Copilot, and interactive Claude Code are copilots. An autopilot flies the leg unattended: you set the course, step away, and it runs the controlled plan → build → verify → fix → commit loop without you in the loop. Ralph Workflow is the autopilot that commands your coding agents. The choice is your mode of operation, not which tool wins.

Yes. Keep your interactive copilot for daytime work — drafting, exploring, debugging with a partner at the keyboard. Hand Ralph Workflow the bounded, well-scoped tasks you would otherwise start before bed: the spec is the boundary, the loop is the runner. You stay in charge of the workflow shape; Ralph Workflow handles the phases between your prompts.

No. Ralph Workflow is agent-flexible. It runs Claude Code, Codex CLI, or OpenCode and does not lock your process to one vendor's agent UX. The point is to avoid tying your workflow to a single vendor's tool while keeping the work local-first on your own machine. If your preferred agent changes, your Ralph Workflow run shape stays the same.

Your Ralph Workflow runs stay the same. The loop shape, the spec format, the phase ordering, the finish receipts, and the commit discipline are owned by Ralph Workflow, not by any single agent. Switch from Claude Code to Codex CLI or OpenCode between runs and your unattended workflow shape continues. You are not tied to a vendor's agent UX or model pricing.

No. The first-run mental model is: write the spec, run `ralph`, walk away. Ralph Workflow ships with practical defaults that work before you configure skills, so the first run is bounded and reviewable without any optional configuration. Advanced skill configuration exists lower down, but you never have to assemble a framework to get value.

Write a short spec for one bounded task. Run `ralph`. The plan → build → verify → fix → commit loop runs unattended, your test suite executes, failures get fixed by the agent inside the loop, and you get back a finish receipt plus a commit history. Then you run the result yourself, compile it, test the program against the spec, and decide whether to merge, sharpen the spec, or iterate.

Yes. Ralph Workflow's defaults are the floor; skill configuration is the ceiling. Add project-specific skills, custom verification commands, or specialised prompt templates as your workflow matures. The first-run defaults stay available as a safe baseline so a new contributor can install, run, and get value without reading the entire advanced configuration surface.

Autopilot, not self-driving. Ralph Workflow follows your spec through a bounded, phase-gated plan → build → verify → fix → commit loop. It does not invent goals, roam the repo, spawn an unmanaged swarm, or keep one endless agent thread alive on a giant feature. You hand it a bounded spec, it flies the loop, and it hands back. You stay the pilot in command.

No. Ralph Workflow does not invent goals, roam the repo, or pick the next feature for you. The spec is the destination; the loop is the flight plan. If the spec says add a CLI flag for verbose output, that is what gets planned, built, verified, fixed, and committed. Goals live with the developer, not the agent.

No. The plan → build → verify → fix → commit loop is bounded by your spec and your verification gates. Ralph Workflow does not spawn an unmanaged swarm, does not keep one endless agent thread alive on a giant feature, and does not refactor code outside the spec. The loop closes when your checks pass, the commit lands, or you decide to stop it.

The models are probabilistic, but the workflow shape is deterministic: same phase order, explicit checks, bounded handoffs, finish receipts, and commits. The probabilistic piece is what each agent writes inside the loop; the deterministic piece is how Ralph Workflow plans, builds, verifies, fixes, and commits that work. Same shape every run, with the model's output varied inside it.

Not bit-identical code, but bit-identical shape. The plan, the verification gates, the phase order, the handoff receipts, and the commit discipline are deterministic. The model's output inside each phase is probabilistic — different wording, different variable names, different helper structure. The same shape every run is the design goal; identical code is not.

Ralph Workflow has already driven the agents through coding, checks, fixes, and review-oriented artifacts. Your responsibility is to run the result, compile it, test the program, and decide whether the finished behavior satisfies the spec before accepting, merging, or shipping. The owner does not babysit or manually redo the agent's code review as the primary value proposition — the value is software you can actually try against the spec.

You are the pilot in command, so yes — but the review is the landing, not the babysitting. Ralph Workflow has already driven the agents through coding, checks, fixes, and review-oriented artifacts, so the work you do on landing is compile-and-test: run the program, exercise the change against your spec, decide whether the behavior satisfies the brief before accepting, merging, or shipping. That is the landing the autopilot framing predicts.

Run the program. Compile it. Test it against your spec. The morning-after question that matters is still: would I merge this? If yes, merge. If the spec was satisfied but the result is rough, sharpen the spec and re-run. If the spec was wrong, write a better spec. The loop keeps the work disciplined; the judgment stays with you.

Ralph Workflow runs on your own machine and is free and open-source. It does not require a hosted SaaS, cloud execution, or hidden remote control. Your code never leaves your laptop unless you push it yourself, and the only cost is your AI provider's API fees (Claude Code, Codex CLI, or OpenCode), paid directly between your machine and that provider.

Your code stays on your machine. Ralph Workflow runs against your local git repository; commits land in your local branch; the loop reads files from your filesystem. Nothing is uploaded to a hosted SaaS, nothing leaves your laptop unless you push it yourself. The only network calls are the AI provider's API requests for the agent that is running the loop.

Overnight while you sleep is the most vivid use case image, but Ralph Workflow works in any unattended window: during the day while you are on another branch, across multiple repos simultaneously, in the background while you do other work. The product is unattended coding, not "the overnight thing." Use overnight as the concrete story, then immediately see the broader picture.

Yes. Run one Ralph Workflow session per repo, each with its own spec, and they execute in parallel unattended. You come back to a stack of finish receipts and commit histories, one per repo, and triage them against your spec the next morning. Cross-repo work stays under your control — Ralph Workflow does not coordinate agents between repos on its own.

No. Ralph Workflow commands your coding agents; it does not replace them. The comparison is mode-of-operation, not model-vs-model or IDE-vs-IDE. Hand it a spec, run `ralph`, and Ralph Workflow flies the plan → build → verify → fix → commit loop while you step away. Use the agents directly for interactive copilot sessions; use Ralph Workflow as the autopilot when you want to leave the prompt-by-prompt loop behind.

Yes. Use your coding agents directly for interactive copilot sessions — drafting, exploring, debugging with a partner at the keyboard. Use Ralph Workflow as the autopilot when you want to hand off a bounded spec and step away from the prompt-by-prompt loop. The agents are the engines; Ralph Workflow is the autopilot system that flies them unattended.