Warp Factories Explained: Oz, Pricing, and How It Compares With Factory and Starko
Open three homepages this month and you'll read the same two words. Factory's says "Build Your Software Factory." Warp's says "Open infrastructure for cloud software factories." Ours says Starko is a software factory too. If you're trying to pick one, the shared label is no help at all.
So here's the useful version. Warp Factories, Factory and Starko all run coding agents that end in a pull request. They disagree about where the factory starts, who writes the work order, and what you get billed for. Those three choices decide which one fits your team, and they matter more than whichever model sits underneath.
Key takeaways
- Warp Factories is infrastructure: you define agent pipelines in code (
factory.yaml) and trigger them from issues, Slack, schedules or webhooks. Early access, billed as a plan plus usage. - Factory is a delegation platform: your engineers hand tasks to Droids from Slack, Jira, Linear, the CLI or CI. Billed by subscription tier and seats.
- Starko starts upstream, from customer evidence: support conversations, session replays and page errors become tickets its coding agent can fix.
- In September 2026, more than 40% of GitHub pull requests started from an agent's draft (). Choosing the input now matters more than choosing the agent.
What does "software factory" mean in 2026?
A software factory, in the 2026 sense, is a system where coding agents take work from a trigger to a reviewable pull request with people approving at set gates instead of doing each step by hand. Warp Factories, Factory and Starko all fit that definition. What separates them is the trigger, the gates and the unit you pay for.
The term spread fast because the volume is real. GitHub's Octoverse 2026 report counted about 110 million agent-started pull requests in September alone, roughly six times March's volume, and GitHub calls its own detection "a floor" (). Writing code is no longer the scarce part. Deciding what to write, and checking it, is.
We wrote a longer piece on . This post sticks to the three products.
Four questions that separate the three
Skip the feature grids for a moment. Four questions do most of the sorting.
First, where does work start? A label on a GitHub issue, a message in Slack, a cron schedule, or a customer who got stuck in your product. Second, who writes the spec? An engineer, a triage agent working from an issue someone filed, or an agent reading a session replay and a support thread.
Third, where does the agent run, and whose agent is it? Hosted, self-hosted, your model or theirs. Fourth, what do you pay for? Seats, runs, usage, or outcomes.
That last one sounds like procurement trivia. It isn't. Faros AI's telemetry from more than 10,000 developers found that teams with high AI adoption merged 98% more pull requests, while PR review time rose 91% (). When review is the bottleneck, the honest price comparison is total cost divided by merged pull requests, not the price of a run.
What is Warp Factories?
Warp Factories is Warp's infrastructure for building your own software factory: a fleet of agents wired into your development process, defined in a versioned factory.yaml plus agent files, and run on Warp's cloud or on your own workers. Warp describes it as "open infrastructure for teams to build measurable, self-improving software factories" ().
The flexibility is the selling point. Triggers include GitHub and GitLab issues, Slack and Teams events, Linear and Jira issues, push and PR events, and a cron scheduler. The agent can be Warp's own, Claude Code or Codex (the config accepts oz, claude, codex or claude-code as the harness), and you can pick the model per pipeline stage. The default stages are Triage, Spec, Code and Review. Warp's issue implementation guide shows the shape: a maintainer applies a factory-ready label, a foreman agent delegates to an implementation agent, an independent review agent checks the work, and the instructions say "Never merge" ().
Pricing sits on top of usage. The pay-as-you-go tier is $0 a month with usage at 20% above API rates, Build is $20 a month at API rates, Business is $50 per user per month, and Enterprise adds self-hosted workers and compute ().
Where it falls down is mostly a matter of timing and effort. Warp launched Factories on August 18, 2026 as a closed beta (), and the docs still say it "is in Early Access and enabled per team." It is also a kit. Someone on your team has to design the stages, write the agent files and own the pipeline.
What is Warp Oz, and how does it relate to Warp Factories?
Warp Oz is the cloud agent platform Warp launched on February 10, 2026, described as "a cloud-based platform for running, managing and orchestrating coding agents at scale" (). Warp Factories, launched six months later, is the team product built on the same execution layer.
Warp's docs now call that layer the Automation Platform: it "provides shared execution, configuration, and APIs for Warp Factories and standalone cloud agents," and "every agent run in a factory is an ordinary cloud agent run" on it (). A "Transitioning from Oz" guide says Factories "is the web experience for team development workflows," while standalone cloud-agent workflows "still use the Oz web app, CLI, SDKs, and API" ().
So Oz wasn't simply renamed. If you run one-off cloud agents, Oz's tools are still there. If you want a pipeline of agents with triggers and gates that your team owns, that's Factories, and inside a factory.yaml the harness type for Warp's own agent is still called oz.
Factory's Droids are built for engineers who delegate
Factory, which now lives at factory.com, sells an "agent-native software development platform" for planning, building, reviewing, testing and shipping code (). Its agents, called Droids, are reachable from the command line, desktop, web, mobile, Slack, Microsoft Teams, Jira, Linear and CI.
The model is delegation. An engineer picks a backlog item, an incident, a test gap or a docs chore and hands it to a Droid. Factory says you can "point Droids at Linear, Jira, or GitHub issues and get working PRs back," with Droids creating branches and opening pull requests in your repositories (). Enterprise buyers get the things they ask for: zero data retention, SSO, audit logs, dedicated compute and on-premise options.
Pricing follows the seat-and-tier pattern ():
The weakness is the flip side of the strength. Factory makes an engineer faster at work the engineer already chose. It doesn't decide what's worth doing, and you pay for capacity whether or not the output merges.
Where does Starko put the factory?
Starko puts the factory upstream of the ticket: it collects customer evidence from support conversations, session replays and page errors, turns repeated friction into recommendations, and has a coding agent build the ones a person accepts. The same product runs your support inbox, so the customer's report and the fix live on one ticket.
The input is the difference. The chat widget records the session around a problem and uploads only when something goes wrong, such as a JavaScript error, a failed request, a rage click or the visitor opening a conversation. Starko reads the replay, and when it finds confident friction it files a recommendation on the . Ten confused visitors make one recommendation with ten sightings, not ten tickets.
A person accepts the recommendation or mentions @starko on the ticket, unless the project's policy lets complete bug reports start on their own. Then Starko AI reproduces the problem in a sandbox, fixes it, and opens a draft pull request with Problem, Reproduction, Fix, Verification and Risk sections. Starko re-runs your test commands after the agent finishes, and a reviewer agent and your CI weigh in before you do.
Starko is narrower than the other two, and you should know that before you pick it. There's no factory.yaml for designing your own stages, no per-stage model routing, and it connects to repositories through a GitHub App, so GitLab teams are out. If what you want is a programmable agent platform or a general-purpose engineering agent, Warp or Factory fits better.
One bug report, three factories
Picture a six-person SaaS team. On Tuesday at 9:40, a customer writes on WhatsApp: "The CSV export gives me an empty file since yesterday." Three other people hit the same button that morning without saying anything.
With Warp Factories, nothing happens until the complaint becomes an issue. Someone files it in Linear, moves it to Ready for Engineering, and the factory's foreman picks it up. If your team built a triage stage, an agent might ask for missing details first. The pull request arrives with validation results and a review report. It's an excellent pipeline, as long as someone carries the WhatsApp message into Linear.
With Factory, an engineer reads the complaint, opens a session from Slack or the CLI, and delegates the fix to a Droid. If the engineer is good at writing the task, the Droid is good at doing it. The three silent customers never enter the picture.
With Starko, the WhatsApp message lands in the same inbox as the widget. Starko AI replies to the customer first, and in a project linked to a repository the ticket is classified as a bug. If the report is missing what a fix needs, an internal note lists exactly what. The three silent visitors count too: a failed request triggers a recording, and when Starko reads friction in those sessions, the repeats pile onto one recommendation instead of three tickets.
Someone on the team mentions @starko on the ticket or accepts the recommendation, and Starko AI reproduces the bug in a sandbox before touching code. The draft pull request says whether it reproduced, what changed and how it was verified. If the team merges it, the ticket moves to done.
None of the three is wrong here. They just start in different rooms.
Head-to-head comparison
Prices and availability were checked on each vendor's site on November 3, 2026.
Which one should you pick?
Pick by the problem you actually have, not by the label on the homepage.
- Pick Warp Factories if you have a platform team that wants to own the pipeline: custom stages, your own models, scheduled jobs, self-hosted runners and a factory definition that lives in version control.
- Pick Factory if your engineers already know what to build and want to hand off more of it, across many surfaces, with enterprise controls and predictable seat pricing.
- Pick Starko if your bottleneck is knowing what to fix, your customers report problems in chat, WhatsApp or by quietly giving up, and you want every fix to start from the customer's own report.
Some teams will run two of these. A Factory or Warp setup for planned engineering work sits fine next to Starko handling the stream of customer-reported fixes.
Verdict: the input decides
Agents are converging. Warp lets you plug in Claude Code or Codex, the model behind the curtain changes every quarter, and the pull requests look more alike every month. What doesn't converge is the input.
Stack Overflow's 2026 survey found that 48% of developers trust AI output when they can easily validate it (). A pull request that carries the customer's session, the failed request and a reproduction is easy to validate. A pull request that started from a one-line Slack message usually isn't.
Our view, as the people building one of the three: if your team already writes great tickets, buy the best agent pipeline you can. If your best tickets are sitting unwritten in your support inbox, start the factory there. The walks through the whole loop, and our and posts cover the wider field.
Frequently Asked Questions
What is Warp Factories?
Warp Factories is Warp's infrastructure for building cloud software factories: fleets of coding agents defined in a versioned factory.yaml, triggered by issues, Slack, schedules or webhooks, and run on Warp's cloud or self-hosted workers. It runs Warp's own agent, Claude Code or Codex, launched on August 18, 2026, and is in early access as of November 2026.
How much does Warp Factories cost?
Warp Factories bills a plan plus usage. The pay-as-you-go plan is $0 a month with usage at 20% above API rates, Build is $20 a month with usage at API rates, Business is $50 per user per month, and Enterprise is custom with self-hosted workers. Usage covers inference, compute and agent runs ().
What is the difference between Warp Factories and Factory?
Warp Factories is infrastructure: you design the agent pipeline, its stages and its triggers in code. Factory is a ready-made agent platform: engineers delegate tasks to Factory's Droids from Slack, Jira, Linear, the CLI or CI, and pay by subscription tier and seats. Warp suits platform teams; Factory suits engineers who want to hand work off.
Is Warp Oz the same as Warp Factories?
No. Warp Oz is Warp's cloud agent platform, launched in February 2026, and Warp Factories is the team product built on the same execution layer, launched in August 2026. Warp's docs say standalone cloud-agent workflows still use the Oz web app, CLI and SDKs, while Factories is the web experience for team workflows.
How is Starko different from Warp Factories and Factory?
Starko starts from customer evidence instead of a ticket someone wrote. It reads support conversations, session replays and page errors, proposes fixes, and has its coding agent build the ones a person accepts. It also runs the support inbox the evidence comes from. It's narrower: no custom pipelines and GitHub only.
Starko's free plan lets you connect a repository and see what your customers would have your factory build. .
