FAQ
Every question, in full
The five that decide it are on the homepage. These are the same answers without the trimming. Anything missing, write to us.
- How is this different from Cursor, Claude Code or Devin?
Cursor and Claude Code work while a developer is at the keyboard, and Marlow does not replace them. Its input is a ticket, so it works the queue when nobody is there.
Because a run reviews itself, runs your tests, reads the CI verdict and produces a risk assessment before asking for you, it is meant to be left running rather than watched.
Devin is the closest comparison. The differences that tend to matter: Marlow runs on your own infrastructure if it has to, takes your own provider keys, prices per run with tokens passed through at cost, and logs every decision.
- What happens if a ticket is too vague to work on?
Marlow checks a ticket before spending anything trying to run it: is there a repo, a test command, enough detail to act on. A vague one is refused with a clarifying question, posted back to the ticket's own source instead of burned as a run.
Readiness and any duplicate or already-fixed prior run are checked before dispatch, not after a failed attempt. Devin's own pricing FAQ tells a user to control the size of their prompts; Marlow tells you the ticket will not work, before it spends anything finding out.
Answer the clarifying question where the ticket came from — Linear, Jira, GitHub or the Slack thread that raised it — and the run picks up from where it paused, with no new dispatch.
- What happens to a ticket too big for one pull request?
Nothing starts. Marlow posts a proposed split into two to eight child tickets back to the ticket, and creates none of them until someone replies approve. A child ticket is never split again.
It works where Marlow can create tickets: Linear, Jira and GitHub issues. A Jira epic counts as too big by its type alone; anything else is judged by the same readiness check that catches a vague ticket.
Reply with changes instead and the plan is revised. After two revisions without an approval it stops and waits for a person, having created nothing.
- Do I need an existing repository?
Yes. Setup clones your repository and verifies it builds in a fresh sandbox before any ticket lands. Marlow creates no repositories and hosts nothing.
It works on code you already have and hands changes back as pull requests against it. If you are starting from nothing, start somewhere else and bring Marlow in once there is a repository and a test command.
- What does it cost right now?
Prices are per run rather than per seat — $0 for 50 runs a month on Free, $49 for 100 on Starter, $99 for 500 on Team, $499 for 3,000 on Scale. Free fits a team of three and every paid tier is unlimited. Free needs no card; paid plans are bought, changed and cancelled from the console's billing page.
- Can I bring my own provider keys?
Yes — that is the model: you bring the keys, Marlow runs the harness. Keys are set per organisation and per provider — Anthropic, OpenAI, Google, xAI, OpenRouter or Amazon Bedrock — so calls go out on your account and your provider bills you directly.
Keys are encrypted at rest and never shown again.
If a key stops working the run fails and names the provider, rather than quietly falling back to our account and billing you through Marlow.
Every stored key is checked against its provider daily, so a revoked key or an expired session token turns up on the settings screen instead of in a failed run.
- Can we run it on our own infrastructure?
That is what the Helm chart and the compose file are for. If your code cannot leave your network, this is the option to ask us about.
- How isolated is a run, really?
Agent code runs in its own container, with its own filesystem and its own CPU and memory ceiling. It does not execute inside the layer that does ingestion, triage and scheduling.
The sandbox image is set per project. The working volume is created for a single run and destroyed with it, so a run for one repository cannot see another's working tree.
- How does Marlow decide which workflow a ticket runs?
Labels first. A project declares the workflows it runs, and a ticket tagged with one of their names runs exactly that, with no model call involved.
Only an unlabelled ticket reaches the classifier, and when it does it records which workflow it picked and why.
Switch triage off and unlabelled tickets fall to the project's default workflow instead of being guessed at. You can also skip the whole path and dispatch a ticket to a model you pick.
- Which models can I use?
Claude Opus 4.8 and 4.7, Sonnet 4.6 and Haiku 4.5, the GPT-5.6 family and GPT-5, Gemini 2.5 Pro and Flash, Grok, GLM, Qwen and Perplexity Sonar.
Through Amazon Bedrock, Sonnet 4.5 and Haiku 4.5 run inside your own AWS account. Tokens are billed through at the provider's own list price, with no markup added.
- What does the audit ledger actually record?
One append-only row for every mutation and every dispatch, holding the organisation, the acting user, the action, the object it acted on, a JSON payload, and the time.
It is indexed by organisation and by target, so you can ask what happened to one project last quarter without reading the whole table. Rows are never edited or deleted.
- Can I write my own agents?
Yes, in the console. An agent is a model, a set of tools, any MCP servers it should reach, and your own standing instructions. There is nothing to build or upload.
Those layer over the role template for the job it is doing, and over the target repository's own AGENTS.md or CLAUDE.md, so an agent inherits your repo's conventions without you restating them.
Start on Free
Start with one boring ticket.
Connect a repository and send it something you have been putting off. Set the gate to “open a pull request and stop” — the worst case is a branch you close.
No card required · nothing to cancel · read the FAQ