DEV Community: Daniel Kim

Cursor Launched a GitHub Rival on GitHub's Worst Outage Day in Years — Three Days After SpaceX's $60B Buyout Closed

Daniel Kim — Fri, 21 Aug 2026 00:15:25 +0000

On August 17, 2026, GitHub went down. Not "some features degraded" down — a global, multi-hour outage that took out github.com, authentication, Actions, the API, pull requests, issues, and Copilot, starting when traffic hit a new peak and a critical piece of infrastructure in GitHub's Central US datacenter failed to scale with it. Error rates on web and API traffic hit roughly 20% at peak; archive and raw-content downloads got hit even harder, around 50%. The outage ran 13:28 to 21:15 UTC — seven hours and forty-seven minutes — with Actions staying degraded until about 18:03 and the Copilot token service not fully recovering until 21:02.

On the same day, Cursor shipped the early beta of Origin, its own git hosting platform — repos, pull requests, code browsing, GitHub sync, all built to be operated by AI agents as much as by humans. Three days earlier, SpaceX had closed its $60 billion all-stock acquisition of Anysphere, Cursor's parent company, a deal first announced about two months prior. The internet did what the internet does and called the timing suspicious. It probably was intentional — but the more interesting story isn't the timing, it's what Origin actually is, and what it means that the company building the most popular AI coding agent now also owns the pipe that agent's code flows through.

What actually shipped

Origin is not, today, a general-purpose GitHub replacement. It's in early beta, gated to Cursor's Pro, Teams, and Enterprise plans, and the feature set is deliberately narrow: create a repository from the web UI or by asking a Cursor agent to make one for you, clone it and push with git like normal, mirror or sync an existing GitHub repo into Origin, browse and search code in the browser, open and merge pull requests, and share access across a Cursor team. There's a CLI, and there's a public REST API covering repositories, commits, checks, pull requests, and app installations.

None of that is novel in isolation — GitLab, Gitea, Forgejo, and Sourcehut have offered git hosting plus review workflows for years, some of it for over a decade. What's different is the design center: Origin is built for what Cursor calls "agent scale," and the concrete expression of that is deep integration with Cursor Automations and Cursor's cloud agents. An agent can be handed a task, write code, push it, open a PR, and merge it against Origin without a human ever routing through a browser tab. The API surface — checks, commits, PR state — exists specifically so an agent loop can poll status and act on it programmatically, not so a human dashboard can render a pretty chart.

That's the actual pitch: not "GitHub but nicer," but "git hosting where the primary client was assumed, from day one, to be a non-human actor operating continuously rather than a person checking in a few times a day."

Why that's a different engineering problem than it sounds

GitHub's architecture — webhooks, a marketplace of Actions, branch protection rules built around human review gates, an API rate-limited for occasional polling — was designed for a world where a commit is followed by a human clicking "merge." Agent-driven development inverts the traffic pattern: instead of a handful of humans pushing a few times a day, you get one or many agents making rapid, small commits, opening PRs continuously, and needing to read CI/check status in a tight loop to decide whether to keep iterating or hand control back. That's a fundamentally different load shape, and it's a plausible reason GitHub's own infrastructure — built and hardened for the human cadence — is starting to show strain in ways that make headlines. One analysis published the day after the outage argued that GitHub Actions had, over the trailing year, burned through its entire annual downtime budget in this single incident if measured against a "three nines" (99.9%) reliability target — a claim worth treating as directional rather than gospel, but it lines up with what the outage postmortem describes: a system caught off guard by a new traffic peak.

Whether or not agentic workloads specifically caused that peak, the framing is convenient for Cursor, and it's not wrong that the two trends — more autonomous coding agents, and visible cracks in the incumbent git host's reliability — are colliding at the same moment Cursor happens to have a war chest and a new git host to sell.

The stack getting assembled underneath this

Set Origin aside for a second and look at what SpaceX buying Anysphere actually does. Reporting on the deal describes an expectation that Cursor's coding agents get paired with compute from xAI's Colossus supercluster in Memphis, plus tighter integration with Grok, xAI's model family. Elon Musk controls SpaceX, xAI, and now — through this acquisition — a controlling stake in the company behind the most-used AI-native code editor. That's editor, agent runtime, compute, model, and now git hosting, converging under one ownership umbrella in the space of about ten weeks.

Compare that to where the rest of the market sits. Anthropic's Claude Code and OpenAI's Codex both operate as agents that sit on top of whatever git host and whatever hosting infrastructure a team already has — they're vendor-agnostic by construction, because Anthropic and OpenAI don't own a git forge or a cloud compute fabric at Colossus's scale. Cursor, post-acquisition, is moving toward being able to offer the entire vertical stack from one company: write the code with a Cursor agent running on xAI compute, informed by Grok, stored in Origin, reviewed and merged by another Cursor agent, with the whole loop never touching a third party. That's either the most efficient agentic dev loop on the market, or the tightest single-vendor lock-in story in developer tooling since the mainframe era, depending on which incentives you trust more.

What the coverage is skipping past

A few things got glossed over in the initial wave of "Cursor launches GitHub rival" headlines that matter more to a working engineering team than the SpaceX drama does:

Origin is early beta with no stated CI/CD story. Pushing, mirroring, PRs, and an API are not the same as Actions — there's no announced equivalent for arbitrary build/test/deploy pipelines, which for most teams is the actual reason they can't leave GitHub regardless of how good the git hosting part is. Teams don't just store code on GitHub; they run their entire delivery pipeline through Actions, and there's no migration story for that yet.

GitHub sync direction is unclear from public docs. "Sync from GitHub" is described as copying a repository into Origin, but whether Origin then stays live-mirrored, one-way, or requires manual re-sync isn't spelled out in what Cursor has published so far. That distinction matters enormously if you're trying to run a hybrid setup during evaluation rather than a hard cutover.

Network effects don't transfer. GitHub's actual moat was never git hosting — plenty of alternatives have existed for years — it's the ecosystem: the Actions marketplace, the issue trackers wired into everyone's project management, Dependabot, the sheer discoverability of being where fifteen years of open source already lives. Origin inherits none of that on day one, and "we sync from GitHub" is an admission of that, not a workaround for it.

Compliance and audit posture is unaddressed. No SOC 2, no stated data residency options, no mention of the certifications that get a platform onto an enterprise's approved-vendor list — which is table stakes for GitHub Enterprise or GitLab customers evaluating a switch, and conspicuously absent from what's been published about Origin's early beta.

The ownership concentration cuts both ways as a risk, not just an efficiency story. If your code, your agent, your compute, and your model all come from companies under one controlling shareholder, you've traded "GitHub had a bad day" risk for "one entity now has visibility into your entire development pipeline, and no external check exists on how it prioritizes your data, your uptime, or your pricing." That's not a hypothetical — it's the direct consequence of the vertical integration being marketed as a feature.

The cost and lock-in math nobody's published yet

Pricing details for Origin haven't been broken out separately from Cursor's existing Pro/Teams/Enterprise tiers, which itself is a signal: this isn't being sold as a standalone product with its own P&L, it's being bundled as a retention feature for the editor subscription you're presumably already paying for. That's a reasonable go-to-market move, but it also means the real cost isn't the sticker price — it's the switching cost you accumulate the longer you keep code, PR history, and agent-run telemetry inside a platform that only exists as an appendage to one vendor's editor. GitHub's pricing is public, competitive, and — crucially — decoupled from any single IDE; you can leave VS Code for Cursor, or Cursor for something else entirely, without touching your git host. Origin collapses that separation on purpose. If the editor and the git host are sold as one bundle, "should we switch editors" and "should we migrate our repos" stop being two separate decisions with two separate cost structures, and become one much larger, much scarier decision. That's a meaningful DX regression dressed up as a convenience win, and it's worth pricing out explicitly before a team leans on Origin for anything beyond a sandbox.

There's a security dimension here too that the "agent-native" framing tends to paper over. An agent that can push, open PRs, and merge without a human in the loop needs credentials scoped to do all of that — and Origin's whole value proposition depends on agents holding broader, more persistent access to your codebase than a human contributor typically would. Centralizing that access inside the same company that also runs the model doing the reasoning is a different risk profile than the current default, where your git host (GitHub), your agent vendor (Anthropic, OpenAI), and your compute (AWS, GCP, Azure) are usually three separate companies with three separate incentives to keep each other honest. Collapse those into one vertically integrated stack and you've removed a natural set of checks in exchange for a smoother agent loop. That might be a trade worth making for a two-person startup optimizing for velocity. It's a much harder sell for anyone with actual IP to protect or a security team that asks pointed questions about blast radius.

Practical use cases worth actually trying

Setting the strategic questions aside, there are a handful of concrete situations where Origin's early beta is worth spinning up today rather than waiting for GA:

Greenfield prototypes built almost entirely by Cursor's cloud agents, where there's no existing Actions pipeline to migrate and the main friction you're trying to remove is the browser hop between "agent finishes a PR" and "agent (or you) merges it."
Fast internal tools and scripts that don't need compliance sign-off, where the appeal of an agent that can go from a Slack-style prompt to a merged PR without a human clicking through GitHub's UI is a genuine time saver, not a liability.
Evaluating agent-loop latency claims for yourself. The most defensible reason to try Origin right now isn't "replace GitHub," it's benchmarking whether removing the host round-trip meaningfully changes how fast an autonomous coding session actually completes a task — that's an empirical question you can answer in an afternoon on a throwaway repo.

What it's not yet suited for: anything touching regulated data, anything with an existing CI/CD investment measured in hundreds of workflow files, and anything where "who has access to merge to main" needs to survive an audit.

The competitive scoreboard everyone else is watching

GitHub's response to its own outage matters as much as Cursor's launch. A platform that just burned through a year's reliability budget in one incident, per the "three-nines" analysis floating around in the aftermath, is going to face pressure — from Microsoft's leadership as much as from customers — to over-invest in resilience for the next few quarters, which historically tends to produce real infrastructure improvements even if the marketing cycle around them is loud. Meanwhile GitLab, which has spent the last two years building its own agentic tooling (Duo Workflow and related agent features) on top of an already-mature CI/CD and compliance stack, arguably has a stronger near-term claim to "agent-native git hosting that's also enterprise-ready" than Cursor does today, precisely because it isn't starting from zero on the parts Origin is missing. And the open forges — Gitea, Forgejo, and the more experimental likes of Radicle — remain the answer for anyone who reads "one vendor owns your editor, your compute, your model, and your git host" as a five-alarm fire rather than a feature.

None of that makes Origin uninteresting. It makes it one entrant in a field that's about to get much more crowded, at exactly the moment the incumbent looked most vulnerable — which is either very good timing or very good luck, and from the outside it's hard to tell which.

The independent read

The timing was almost certainly opportunistic marketing, not malice — Origin had presumably been in development for weeks or months, and shipping the beta on the day of a historic outage is the kind of gift a comms team doesn't turn down, whether or not it's fully organic. That's fine; it's also not the story. The real story is that "agent-native git hosting" is a genuinely distinct product category from "another GitHub clone," because the traffic pattern an autonomous agent generates — rapid small commits, continuous status polling, PR cycles measured in minutes rather than days — is different enough from human-cadence development that purpose-built infrastructure has a real argument for existing.

But a single bad afternoon for GitHub, however dramatic the numbers, does not erase fifteen-plus years of ecosystem lock-in, and Origin in its current state — no CI/CD equivalent, no compliance story, unclear sync semantics — is not close to being a drop-in replacement for any team beyond "solo developer or small team already living entirely inside Cursor's cloud agents." The more consequential long-term question isn't whether Origin's UI is nice; it's whether the market wants its entire agentic development stack sourced from one vertically integrated vendor with a rocket company's balance sheet behind it, or whether it wants agent-native workflows built on top of infrastructure that stays open and swappable. GitLab has been making agent-native noises of its own, and the open forges (Gitea, Forgejo) aren't standing still either — this isn't a two-horse race yet, it just looks that way this week because of how the news landed.

Who should actually do something about this

Try it now: individual developers or small teams already running most of their work through Cursor's cloud agents and Automations, on side projects or greenfield repos where you're not dependent on an existing Actions pipeline. The agent-loop latency improvement from not round-tripping through a browser is real and worth feeling firsthand.

Wait and watch: any team with an existing CI/CD investment in GitHub Actions, compliance requirements, or dependencies on GitHub's ecosystem (Dependabot, the Marketplace, issue-tracker integrations). There's nothing to migrate to yet — watch for a stated CI/CD story and actual compliance certifications before this is a serious evaluation candidate.

Ignore for now: teams not already using Cursor as their primary agent runtime. Origin isn't a general-purpose GitHub alternative you'd adopt independent of the editor — it's a companion product to Cursor's agent stack, and evaluating it outside that context is evaluating a different, much earlier-stage product than the "GitHub rival" framing suggests.

The GitHub outage is the more durable story here, honestly — a platform serving that much of the world's software development infrastructure just had a very bad, very public day, and "three-nines-in-one-incident" is the kind of number that should make every engineering org quietly re-examine what happens to their delivery pipeline the next time it happens, Cursor or no Cursor.

What's your actual switching cost — not the marketing kind, the real one — if your primary git host disappeared for eight hours tomorrow, and does a vertically-integrated, single-vendor alternative like Origin reduce that risk or just relocate it?

Sources:

Clerk Wrote the 'Real Cost of Enterprise SSO' Benchmark Everyone Cites. Clerk Also Wins It.

Daniel Kim — Thu, 20 Aug 2026 12:20:01 +0000

Your startup just closed its first six-figure enterprise deal. The champion on the buyer's side is thrilled. Then procurement sends over a security questionnaire, and line one says: "Must support SSO via SAML or OIDC, with SCIM provisioning, before contract signature."

You now have 30 days to bolt enterprise identity onto a product that was built for self-serve signups. This is one of the most common forcing functions in B2B software, and in 2026 there are more ways to solve it than ever — Clerk, WorkOS, Auth0 (owned by Okta), and Supabase Auth all now sell some version of "enterprise SSO in an afternoon." What almost nobody writes about is that these four products don't just differ in features — they meter the exact same capability (one SAML connection, one directory sync) using four structurally different pricing models, and the gap between them compounds fast once you're not selling to one enterprise customer but ten.

That's the actual decision point. Not "which auth provider is best," which is a question with no stable answer, but "which pricing architecture matches how my enterprise pipeline is going to grow" — a question you can actually reason about with real numbers.

Why this is a live decision right now

Three of these four vendors changed their enterprise pricing in 2026. Clerk ran a full B2B pricing overhaul in February. WorkOS shipped Directory Sync (its SCIM product) to general availability and kept iterating its per-connection ladder. Auth0, under Okta, has been pushing customers who outgrow its free tier into what several third-party analyses now call a "B2B premium" — a multiplier on the base price rather than a flat per-connection fee. Supabase, meanwhile, folded SAML SSO into its existing plan structure rather than shipping it as a separate product, which sounds simpler until you look at how it's actually metered.

None of this is settled. If you're picking an auth vendor this quarter, you're picking during an active repricing cycle across the entire category, which means the marketing pages you're reading right now may already be stale by the time you're negotiating a contract at scale.

What each platform actually sells

Clerk is a vertically integrated auth product: prebuilt sign-in/sign-up UI components, session management, organizations/multi-tenancy, and — as of its 2026 overhaul — enterprise SSO and SCIM bundled into the same connection object. You drop in their React/Next.js/etc. components and get a working enterprise login flow with comparatively little custom UI work.

WorkOS is explicitly API-first and headless. Its free product, AuthKit, covers email/password, social login, MFA, and user management up to a very large user count. Enterprise SSO and Directory Sync (its SCIM offering) are separate, paid, metered-per-connection products layered on top. You write your own UI; WorkOS gives you the protocol plumbing.

Auth0, now part of Okta, is the incumbent enterprise identity platform — the one most likely to already be evaluated by a buyer's security team, because it's been through the most compliance audits and supports the longest tail of identity providers and edge-case SAML/OIDC configurations. It's also the most opaque on pricing once you cross a modest user threshold.

Supabase Auth is GoTrue, Supabase's open-source auth server, sold as one feature of a broader backend-as-a-service platform that also includes Postgres, storage, and edge functions. SAML SSO is a checkbox you enable on an existing Supabase project rather than a separate product you integrate.

How they're built, and why that shapes the cost

The architectural split roughly tracks the pricing split.

Clerk and Supabase are both "your app talks to our hosted service, we hand you sessions and UI primitives" — the difference being that Clerk is a single-purpose auth vendor while Supabase auth is one module of a full backend platform. That coupling is exactly why Supabase's SSO pricing looks different from everyone else's: it's not priced as "here's a new product," it's priced as "here's a new usage dimension on your existing project" — a per-MAU meter for SSO-authenticated users, layered on top of your regular Postgres/API/storage bill.

WorkOS is closer to a headless identity broker: it normalizes SAML, OIDC, and SCIM into one clean API and lets you keep full control of your UI and session logic. That's the reason engineering-led teams gravitate to it — but "headless" also means every enterprise connection is priced as a discrete, metered object, because WorkOS isn't selling you a UI or a user database, just the identity federation layer itself.

Auth0/Okta is the oldest and most feature-complete of the four, built up over more than a decade of enterprise identity edge cases — legacy SAML quirks, unusual IdP behaviors, unusual claim mappings. That maturity is real, and it's also why its pricing doesn't fit neatly into a per-connection ladder: Auth0 sells tiers (Essentials, Professional, Enterprise) that bundle a basket of enterprise features together, so what you're really paying for is tier access, not a specific connection count.

What changed in 2026, concretely

Clerk, following its February 2026 B2B pricing overhaul, now includes on its free tier: 25,000 MAU, one enterprise connection, self-service SSO, and SCIM. SCIM (branded Directory Sync equivalent) reached general availability on April 16, 2026, and group-to-role mapping plus custom attribute mapping followed on May 21, 2026. On the paid Pro tier ($25/mo base), additional connections are billed at $75/mo for connections 2–15, $60/mo for 16–100, $30/mo for 101–500, and $15/mo above that — with SCIM bundled free onto every connection at every tier, not charged separately.
WorkOS kept AuthKit (its base auth product: email/password, social login, MFA, user management) free up to 1,000,000 MAU. But SSO is priced on its own ladder: $125/mo per connection for the first 15, stepping down to $100 (16–30), $80 (31–50), $65 (51–100), and $50 (101–200), with custom pricing above that. Directory Sync (SCIM) runs on the same ladder as a separate line item — so a single enterprise customer that needs both SSO and provisioning is billed twice at the entry tier: $125 + $125 = $250/mo for one customer.
Auth0 doesn't publish a per-connection price at all in its public materials. Its free plan reportedly includes SSO and SCIM for a small number of connections under a 25,000 MAU ceiling, but once you need a paid B2B tier, you're paying a broad multiplier over the equivalent consumer-auth plan rather than a line-item connection fee — and above roughly 20,000 MAU, Auth0 pricing goes fully custom, meaning you're on the phone with sales to get a number at all.
Supabase offers SAML 2.0 SSO starting on its Pro plan ($25/mo base) and above, but meters SSO-authenticated users separately from regular MAU: $0.015 per SSO MAU above your plan's included quota. Its docs also list an Advanced MFA add-on (roughly $75/mo per project) as a related but distinct line item. Supabase doesn't publish enterprise-scale pricing at all — like Auth0, it goes to negotiated contracts once you're a serious enterprise seller.

Modeling the actual cost, not the sticker price

The number that matters isn't "what does one connection cost" — it's "what does my cost curve look like as my enterprise logo count grows," because that's the variable most B2B startups actually control least well (enterprise sales cycles are lumpy, and you'll sign five customers in a quarter you didn't plan for, or none).

Run Clerk's own published ladder out to 100 total connections: connection 1 is free, connections 2–15 (14 of them) cost $75/mo each ($1,050/mo), and connections 16–100 (85 of them) cost $60/mo each ($5,100/mo). That's $6,150/mo, plus the $25/mo Pro base — roughly $6,175/mo for 100 enterprise connections, SCIM included, based on arithmetic against Clerk's public pricing table.

WorkOS, at the same 100-connection mark, is reported to run roughly $6,500/mo for SSO alone, and roughly $13,000/mo once you add Directory Sync/SCIM on every connection — because SCIM is billed as a second, separate metered product rather than bundled. At that scale WorkOS is somewhere between roughly the same as Clerk (SSO only) and more than double Clerk's cost (SSO + provisioning), depending on how many of your enterprise customers actually need directory sync versus just SSO.

Third-party procurement data adds useful ground truth here: Vendr's 2026 buyer-side benchmarks put the average WorkOS contract at roughly $21,292/year, with Spendhound's enterprise-tier average closer to $86,580/year — numbers that reflect real negotiated contracts rather than list-price ladders, and that tend to run higher than the sticker math because enterprise buyers rarely stay at exactly the published tier boundaries.

Auth0 and Supabase are harder to model this way precisely because they don't expose a clean per-connection or per-customer unit past a certain scale — which is itself informative. If you can't build a spreadsheet from public pricing, that's not a neutral fact, it's a signal that the vendor wants your first real conversation about enterprise pricing to happen inside a sales call, where anchoring and discount tactics work in their favor rather than yours.

Where these benchmark numbers actually come from

Here's the part worth sitting with before you trust any comparison, including this one. Searching for "Clerk enterprise SSO pricing 2026" surfaces almost entirely — page after page — content published directly on clerk.com/articles: titles like "Auth Platforms With SSO and SCIM in the Base Tier," "The real cost of enterprise SSO: per-connection vs per-MAU pricing," and "OIDC vs SAML for Enterprise SSO: A 2026 Decision Guide." These are competitive content-marketing pieces, written by Clerk, comparing Clerk favorably to WorkOS and Auth0 on the exact metric — per-connection cost at scale — where Clerk's newer, bundled-SCIM pricing structure wins.

That doesn't make the underlying numbers false. Clerk's pricing ladder is public and independently verifiable; WorkOS's is too. But it does mean that if your primary source for "here's what enterprise SSO really costs across vendors" is a vendor's own comparison page, you're reading a brief written by one side's lawyer, not a court transcript.

The most useful independent check found during this research is a third-party dev.to piece by a smaller identity-infrastructure vendor, comparing SAML costs across Auth0, WorkOS, and Clerk, which — while also not a neutral party, since its author sells a competing product — used its own modeling and arrived at directionally similar conclusions with different absolute numbers: at 10,000 MAU with 3 SAML connections issued over a year, it puts WorkOS at roughly $9,000 against Clerk's roughly $2,100, with Auth0 unquotable because it's custom-priced. At 50,000 MAU with 10 connections, the same analysis puts WorkOS at roughly $30,000 against Clerk's roughly $8,400. Two differently motivated sources landing on "WorkOS is meaningfully more expensive per connection at scale, Auth0 is opaque" is a stronger signal than either piece alone — but it's still not the same as an auditor's numbers, and you should run your own math against your actual expected connection count before believing any of it, including this article.

What each vendor's pricing page doesn't say

Clerk's "SCIM is free" claim is true only in the narrow sense that SCIM isn't billed as a separate line item — you're still paying the same per-connection fee whether that connection uses SSO alone or SSO plus provisioning. The marketing framing ("free SCIM") obscures that you're not getting provisioning at zero incremental cost so much as you're not being charged twice for one customer relationship, which is a real and meaningful difference from WorkOS but not literally "free."

WorkOS's "free to 1,000,000 MAU" headline describes AuthKit — email/password, social login, basic MFA, user management. It says nothing about enterprise SSO or SCIM, which is the feature that actually triggers when a security questionnaire lands on your desk. A startup that reads the "1M MAU free" number and assumes enterprise auth is covered will be surprised by the first $125/mo connection invoice.

Auth0's custom pricing above ~20,000 MAU means the number you'd use to compare it against the other three in a spreadsheet simply doesn't exist publicly. That's not a neutral omission — opaque, negotiated pricing structurally favors the seller, who knows your alternatives and your urgency, over the buyer, who's often evaluating this decision under a signed-deal deadline and limited leverage.

Supabase's SSO-MAU metering is easy to miss if you're already budgeting Supabase as "the Postgres bill" — it's a genuinely separate usage dimension from your regular MAU count and your database compute, and it's not prominently modeled in most Supabase cost calculators floating around online, which tend to focus on database size and bandwidth.

None of the four vendors' marketing pages will proactively tell you "the number you're looking at doesn't include what you actually need." You have to build the model yourself.

Comparison table

Dimension	Clerk	WorkOS	Auth0 (Okta)	Supabase Auth
Base free tier	25,000 MAU, includes core auth	AuthKit free to 1,000,000 MAU (no enterprise features)	Free tier available, low MAU ceiling	No free SSO tier; requires Pro plan ($25/mo)
First enterprise (SSO) connection	Free (1 included)	Not included free — priced from connection 1	Reportedly free at low tier, unclear at scale	Bundled into plan access, metered per SSO-MAU
SSO pricing unit	Per connection, tiered ladder	Per connection, tiered ladder	Tier/plan premium, not per-connection	Per SSO-authenticated MAU ($0.015 above quota)
Entry-tier SSO cost	$75/mo (2nd–15th connection)	$125/mo (1st–15th connection)	~$150/mo B2B "Essentials" tier	Included in $25/mo Pro base + usage
SCIM/provisioning cost	Bundled free with every connection	Separate metered product, same ladder as SSO	Bundled at low tier, unclear at scale	Not clearly self-serve; enterprise negotiation
Est. cost at 100 connections	~$6,150–6,175/mo (SSO + SCIM)	~$6,500/mo SSO-only; ~$13,000/mo w/ SCIM	Custom quote required	Not directly comparable (per-MAU, not per-connection)
Architecture	Vertically integrated, prebuilt UI	Headless, API-first, bring-your-own-UI	Mature standalone IAM platform	Open-source GoTrue, bundled into backend platform
Vendor lock-in shape	Higher — UI + session model tied to Clerk	Lower — swappable identity layer only	Medium — gravity toward Okta ecosystem	Higher if already dependent on Supabase backend
Publicly modelable at scale	Yes	Yes, up to 200 connections	No (opaque above ~20k MAU)	Partially (per-unit rate published, totals aren't)
Best-fit team	Product-led SaaS moving upmarket fast	Engineering-led teams wanting control + own UI	Orgs needing deepest IdP coverage / Okta shops	Teams already all-in on Supabase for backend

Security, maintainability, and lock-in

On raw identity-provider compatibility and enterprise compliance maturity, Auth0 still has the longest track record — it's been the default "safe choice" for enterprise buyers' security teams for the better part of a decade, and that history is worth real money if your sales cycles keep stalling on security review. Clerk and WorkOS are both newer but have shipped SAML/OIDC/SCIM support that covers the vast majority of real-world IdP configurations (Entra ID, Okta Workforce, Google Workspace) that a typical B2B startup will actually encounter; you're more likely to hit an edge case with a long-tail legacy IdP on Auth0's list than on theirs, but you're also less likely to need that edge case than you think.

Lock-in runs in the opposite direction from what the marketing implies. Clerk's biggest strength — prebuilt UI components and deep session integration — is also what makes it the hardest of the four to rip out later, because you didn't just buy an identity API, you built your login and account-management UI on top of Clerk's abstractions. WorkOS is deliberately the opposite: because it's headless, swapping it for a competitor later mostly means changing API calls behind a UI you already own. Supabase's auth is technically open source (you can self-host GoTrue), which sounds like an escape hatch, but in practice almost nobody self-hosts it separately from the rest of their Supabase project, so the real-world lock-in looks a lot more like Clerk's than the "open source" label suggests.

Developer experience and the migration question nobody prices in

The four also diverge sharply on time-to-first-working-login, which is a real cost even though none of the vendors put a dollar figure on it. Clerk's prebuilt components mean a working enterprise sign-in page can genuinely ship in an afternoon, because you're wiring up a component rather than hand-building a SAML redirect flow and session cookie logic. WorkOS gets you the same protocol correctness — its SDKs handle the SAML assertion parsing and OIDC token exchange — but you still own the login page, the loading states, the error handling for a misconfigured IdP, and the session store. That's more work up front and more flexibility later, and which one of those you want depends entirely on whether your team already has an opinionated design system it doesn't want a vendor overriding.

Auth0's SDKs are the most battle-tested against unusual identity provider behavior, which mostly shows up as an invisible cost: fewer late-night pages from a customer's IT department because their specific ADFS configuration doesn't match the SAML spec exactly. That reliability under edge cases is real, but it's also the hardest of the four benefits to verify before you've signed a contract and started onboarding actual enterprise customers, because you don't know which edge cases you'll hit until you hit them.

Latency and data residency rarely show up in these comparisons at all, and they should. WorkOS and Auth0 both operate in multiple regions and can meet data-residency requirements that show up in EU or regulated-industry security questionnaires; Clerk's regional footprint has historically been narrower, though it's expanded this alongside its 2026 pricing changes. Supabase inherits whatever region your underlying Postgres project lives in, which is convenient if you already picked a compliant region for your database and a problem if you didn't think about auth residency separately when you provisioned it.

On migration cost specifically — the question worth asking before you sign with any of the four — moving between them later is never free, but the size of the bill differs by architecture in a way that maps back to the lock-in discussion above. Leaving WorkOS mostly means re-pointing API calls behind a UI you already built, which is a few weeks of engineering work for a mid-sized user base. Leaving Clerk means rebuilding the login, sign-up, and account-management UI you didn't build yourself the first time, on top of migrating session state — a materially bigger project, and one teams tend to underestimate until they're mid-migration. Leaving Supabase Auth means migrating both your identity data and, likely, deciding what to do about the rest of your Supabase-hosted backend at the same time, which is rarely a decision made in isolation.

Which reader should pick which option

You're pre-enterprise, closing your first SSO-gated deal, and need this working in weeks, not a quarter: Clerk's free first connection and bundled SCIM make the initial deal essentially free to unlock, and the UI components save real engineering time you don't have. The tradeoff you're accepting is UI lock-in you'll feel later if you ever want to fully own your auth surface.

You're an engineering-led team that already owns its UI, expects to sign enterprise customers steadily rather than in one lump, and wants to negotiate volume pricing later: WorkOS's headless model keeps you in control, and its ladder is genuinely competitive if most of your customers need SSO but not SCIM (skip the doubled cost). Budget carefully once you cross roughly 20–30 simultaneous enterprise connections, where the gap versus Clerk widens.

You're selling into large enterprises with mature security teams, possibly already inside the Okta ecosystem, and identity-provider edge cases are a real risk to your sales cycle, not a hypothetical: Auth0 is still the safest default on compatibility and compliance pedigree, but go in expecting an opaque, negotiated number rather than a spreadsheet you can build yourself — get multiple quotes and don't accept the first one.

You're already running your backend on Supabase and don't want a second vendor relationship for auth: Supabase Auth's SSO support is genuinely convenient if you're already there, but model the per-SSO-MAU metering explicitly against your expected enterprise user counts before you assume it's cheaper than a dedicated product — it's a different cost curve, not automatically a lower one.

The independent read

Every vendor in this category has converged on the same underlying move: charge close to nothing for consumer-style auth to win developer adoption, then meter enterprise features — the ones that show up the moment a real B2B deal requires them — as a distinct, higher-margin product line. That's not a criticism unique to any one of these four; it's the economically rational structure of the whole category, because enterprise buyers have budget and self-serve users don't. The mistake is treating any single vendor's free tier as evidence that enterprise auth is cheap. It isn't, anywhere, and the "real cost of SSO" comparisons circulating right now are disproportionately funded and published by the vendor that wins them. Build your own model from the public tier tables, run it against your actual expected connection count over the next 12 months — not today's count — and treat any number above roughly 20,000 MAU or 20 connections as a starting point for a negotiation, not a quote.

Discussion: if you've actually priced out enterprise SSO for a real deal — not a hypothetical — which model burned you more: getting nickel-and-dimed per connection as you scaled, or hitting an opaque "contact sales" wall right when you had the least negotiating leverage? And did switching providers later (if you did) actually save what the spreadsheet promised once migration effort was factored in?

Sources:

Polygres Says You Don't Need a Vector Database, a Graph Database, or a Memory Layer — Just Two Postgres Extensions

Daniel Kim — Thu, 20 Aug 2026 09:09:30 +0000

Every few weeks another Product Hunt launch promises to fix "AI memory." Most of them ship the same architecture: pull your data out of wherever it lives, push it into a purpose-built vector store, stand up a sync job to keep the copy fresh, and hope the copy never drifts from the source of truth. Mem0, Zep, and Letta all took that shape, and they disagree with each other mostly on policy — what to keep, what to forget, how to summarize. What none of them touched was the more boring possibility: that the "new database for AI context" step was never necessary in the first place.

That's the bet behind Polygres, a managed PostgreSQL service from a small team called Evokoa that launched on Product Hunt with the tagline "turn your entire database into a context window for AI." Strip away the marketing framing and the actual product is two open-source Postgres extensions — pgGraph and pgContext — plus a hosted layer around them. No new database. No ETL pipeline. No second system to keep in sync. The pitch is that your existing Postgres instance can do graph traversal, vector search, and hybrid retrieval natively, and that doing so in-place is not just simpler but measurably faster than shipping the same query to a dedicated store.

That's a strong, checkable claim, which is exactly what makes it worth digging into instead of skimming the landing page.

What Polygres actually is

Polygres itself is thin. It's a managed hosting layer — currently in a design-partner / early-access phase rather than generally available with public pricing — that runs pgGraph and pgContext for you and wraps them with the usual managed-Postgres conveniences (backups, connection pooling, a dashboard). If you want the interesting part, you don't need Polygres at all: both extensions are Apache-2.0 licensed and can be self-hosted for free, which is unusual restraint for a company whose product page leads with "AI."

pgGraph adds graph queries — traversal, shortest path, relationship search — on top of tables you already have, without a separate graph database or a new query language. It's written in Rust on the pgrx framework and ships as a real Postgres extension, not a foreign data wrapper bolted on the side. At the time of writing it carries over 1,000 GitHub stars, 86 forks, and 469 commits — meaningfully more traction than the typical week-old Product Hunt launch, which suggests the open-source project predates and is feeding the commercial one, not the reverse.

pgContext is the newer, smaller sibling (243 stars): a PostgreSQL 17/18 extension billed as "a full AI search engine, built into Postgres." It does dense vector search, metadata-filtered approximate search, and hybrid dense-plus-full-text retrieval, all inside the same tables and the same transaction boundary as the rest of your application data.

How it actually works

This is where the architecture gets more interesting than the tagline.

pgGraph doesn't turn Postgres into a graph database in the sense of replacing its storage engine. It compiles your relational foreign-key relationships into Compressed Sparse Row (CSR) edge stores — a layout built for O(1) adjacency lookups via contiguous array slices — and memory-maps the result as read-only .pggraph artifact files, one per backend process. Your relational tables stay the system of record; pgGraph builds a derived, rebuildable graph runtime next to them. That's a deliberate trade-off: you get traversal speed close to a dedicated graph engine, but the graph is a snapshot, not a live view. There's no real-time sync guarantee — if your underlying rows change, the graph index is stale until it's rebuilt. The project is upfront that unbounded traversal is a real failure mode and ships circuit breakers — depth limits, visited-node tracking, frontier limits — specifically to stop a bad query from taking down the database.

pgContext takes a different approach to the same "stay inside Postgres" principle. Instead of an external index that gets queried and then joined back to Postgres for the real data (the standard pattern with an external vector database), it persists a page-native HNSW index directly on Postgres index pages, and — this is the part competitors mostly skip — re-scores every approximate result exactly against the live row before returning it. That means every answer inherits Postgres's actual MVCC visibility, row-level security, and SQL predicates, rather than a best-effort copy that might be a write behind or blind to a permissions change. Metadata filtering is pushed through the persisted HNSW graph itself ("filter-aware ANN, not post-filtering," in the project's own words) rather than bolted on afterward, and hybrid retrieval — combining vector similarity with Postgres full-text ranking via reciprocal-rank fusion — ships as a built-in SQL function, not application-layer glue code you write yourself.

The headline number: on the GloVe-100-angular benchmark (1.18M vectors, cosine distance), pgContext reports matching pgvector's recall while answering 3.8–5.3x faster — 0.910 recall@10 at 2.4ms versus pgvector's 2.5ms delivering only 0.75 recall@10 at a comparable setting. That's a genuinely large gap if it holds outside one benchmark on one dataset, and it's the number every claim in the launch materials ultimately rests on.

Concretely, using pgContext looks like registering a column for filtering and then querying with SQL rather than a client SDK — something like CREATE EXTENSION pgcontext; followed by a hybrid search call that takes a query embedding, a text query for full-text ranking, and a metadata filter in one statement, with reciprocal-rank fusion happening inside the function rather than in your application code. That's the practical DX difference from a typical vector-database SDK: there's no separate client library version to pin, no separate connection pool, and no risk of the vector query and the row fetch executing against two different points in time. On the pgGraph side, the equivalent is a traversal function called from SQL — shortest-path or neighborhood queries against tables you already have foreign keys on — bounded by the circuit breakers (max depth, max frontier size, visited-node caps) so a runaway recursive traversal degrades to an error instead of an out-of-memory event on a shared production instance.

What actually changed versus what came before

Three existing options, and how Polygres's approach differs from each:

pgvector inside plain Postgres. This is the honest baseline, and the README implicitly concedes it: if you just need similarity search over documents, pgvector on any Postgres install does that, no extra extension required. Polygres's argument is narrower than "vector search in Postgres is new" — it's "our vector search in Postgres is faster than the vector search in Postgres you already have," plus a graph layer pgvector never attempted.

Dedicated vector databases (Pinecone and similar). These solve a different problem — massive scale, purpose-built infra, managed ops for enormous embedding volumes — at the cost of a second system, a sync pipeline, and a network hop between "find the match" and "fetch the row." For teams whose AI features are additive to an existing Postgres-backed app rather than the entire product, that second system is often pure overhead: another vendor bill, another place data can drift, another access-control surface to audit separately from the one Postgres already enforces.

The agent-memory layer category (Mem0, Zep, Letta). These products solve a genuinely different problem — deciding what an agent should remember, forget, or summarize across sessions — and they still need somewhere to persist that memory, typically their own store or an integration into one of the above. Polygres doesn't compete with that decision layer at all; it's a plausible foundation underneath one, if a team ever built a memory abstraction that just wrote to Postgres instead of a bespoke store.

Managed Postgres platforms (Supabase, Neon). Both already bundle pgvector and are excellent general-purpose managed Postgres — Supabase around $25/month for Pro plus usage, Neon usage-based with roughly a $15/month representative spend on its Launch tier — but neither ships graph traversal or the hybrid/filter-aware retrieval pgContext adds. Polygres doesn't attempt Supabase's auth, storage, and realtime bundle; it's a narrower, deeper bet on the retrieval layer specifically. Practically, that means Supabase or Neon plus self-hosted pgGraph/pgContext is a perfectly viable combination today — you don't need to wait for or adopt Polygres-the-company to get the extensions' benefits on a managed instance, as long as your provider allows installing community extensions, which is worth checking before assuming compatibility.

It's also worth placing this next to the broader "serverless Postgres platform" wave — companies like Xata, which open-sourced its core platform while keeping the profitable managed layer closed. Evokoa's split is structurally similar (open extensions, closed-for-now managed hosting) but narrower in scope: Xata is a full backend-as-a-service around Postgres, where pgGraph and pgContext are two specific capabilities you can bolt onto any Postgres you already run, managed by Evokoa or not.

Why developers should actually care

Cost. The self-hosted path is free and Apache-2.0, full stop. That's the strongest part of the pitch: you can add pgGraph and pgContext to a Postgres instance you already run and pay nothing beyond your existing hosting bill. The managed Polygres product, by contrast, has no public pricing yet — it's explicitly in a design-partner phase, reachable via email rather than a checkout page. If you were hoping for an apples-to-apples cost comparison against Supabase or a dedicated vector DB today, that comparison doesn't exist yet.

Latency. The 3.8–5.3x number is real if you trust a single self-reported benchmark on one open dataset. It hasn't been independently reproduced as far as this research turned up, and GloVe-100 is a convenient, well-understood dataset precisely because it's small and clean — production embedding workloads with higher dimensionality, filtered queries, and concurrent writes are a different test. Worth benchmarking yourself before betting a migration on it.

Developer experience. This is arguably the real selling point, more than raw speed: no new query language, no ORM adapter for a second database, no ETL job to babysit, no "which system is the source of truth right now" debugging session at 2am. If your AI feature reads from data that's already relational — user records, orders, support tickets, org structures — querying it in place is a meaningfully smaller surface area than standing up parallel infrastructure.

Security. Because pgContext re-checks results against live rows, your existing row-level security and access-control policies apply to AI-retrieved results automatically. That's not a minor detail — a lot of "add a vector database" projects quietly create a second, less-audited path to data that bypasses whatever permission model the primary database enforces. Keeping retrieval inside Postgres closes that gap by construction rather than by policy.

Lock-in. Apache-2.0 on both extensions is the opposite of a bait-and-switch open-core play, at least on paper. You can self-host the whole retrieval stack indefinitely without ever touching Polygres the company. The obvious risk with any young, VC-adjacent infra project is what happens to the license and roadmap once the managed product needs to make money — a pattern several other Postgres-platform companies have followed by open-sourcing the engine and keeping the profitable operational tooling closed.

Practical use cases

RAG over data you already have, without exporting it: support tickets, product catalogs, internal docs stored as Postgres rows, searched with the same transaction and permission boundary as everything else in the app. No nightly job pushing embeddings to a second store, and no window where a row was deleted in Postgres but still answerable from a stale vector index.
GraphRAG for relationship-heavy domains — org charts, fraud/anomaly detection over transaction graphs, recommendation paths, dependency graphs between internal services or documents — where the interesting signal is connections between rows, not just similarity between embeddings, and standing up a dedicated graph database (Neo4j-class infrastructure, a new query language, a new ops burden) for one feature is hard to justify against the size of the actual need.
Agent context that needs to respect access control: an internal support or ops tool where different users should see different retrieved results based on existing row-level security, without re-implementing that logic as a second, easy-to-forget filter in application code sitting in front of a vector database that has no concept of your permission model.
Hybrid search for product or documentation search, where pure vector similarity misses exact-keyword queries (SKUs, error codes, product names) and pure full-text misses semantic paraphrases — the reciprocal-rank fusion approach handles both without maintaining two separate search backends.
Incremental adoption inside an existing app. Because this is a normal Postgres extension rather than a new service, a team can add pgContext to one feature, measure it against pgvector on real traffic, and roll it back with DROP EXTENSION if it doesn't pan out — a much lower-commitment experiment than provisioning and populating a dedicated vector database first.

What the launch page leaves out

A few things worth knowing before adopting this, none of them fatal but all of them real:

Version lock-in on the newest Postgres. pgContext requires Postgres 17 or 18. If you're running 14–16 in production — extremely common — you can't adopt it without an upgrade project first. pgGraph is more permissive (14–18, with 13 deprecated post-EOL), but the two extensions don't share a version floor.
Experimental vector types. halfvec, sparsevec, and bitvec support is explicitly marked "partial, experimental" in the README, as is the IVFFlat index type. If your workload needs those specifically, you're on the leading, less-tested edge of the project.
The graph is a snapshot, not a live view. pgGraph's read-only, memory-mapped artifact model means graph queries can run against stale relationship data until the derived index is rebuilt. For workloads with rapidly changing relationships, that staleness window matters and isn't discussed in the marketing copy.
One benchmark, one dataset. The 3.8–5.3x speedup is real as reported, but it's a single vendor-run benchmark on a single well-known dataset. It's a reasonable signal, not independent verification.
The graph and search engines aren't unified yet. pgGraph and pgContext are sister projects; combined GraphRAG queries that use both in one pass are explicitly future work, not shipped today, despite Polygres's own tagline implying an integrated context layer.
No public pricing for the thing being launched. The Product Hunt launch is for Polygres, the managed product — but that product doesn't have a price yet. Everything genuinely usable today is the free, self-hosted open-source layer underneath it.

An independent read

The strongest part of this launch isn't the benchmark number, it's the restraint: a company that could have built "yet another vector database" instead built two narrow Postgres extensions and open-sourced both of them before monetizing anything. That's a healthier starting posture than most AI-infrastructure launches this year, and the 1,000+ stars on pgGraph suggest real developer pull rather than launch-day vote trading.

The weaker part is that the actual commercial product — the thing with a Product Hunt page and a launch story — is the least proven piece of the whole stack. The extensions have real adoption; the managed service is a design-partner waitlist with no price. Anyone evaluating this today is really evaluating pgGraph and pgContext as self-hosted open-source software, not Polygres as a managed offering, and should treat it that way rather than getting pulled in by launch-week framing that implies a finished, GA product.

The category-level argument — that AI context doesn't need a new database, just better use of the one you have — is genuinely under-explored compared to how much attention the "AI memory layer" space has gotten. It won't replace Pinecone-scale deployments or the deliberate forgetting policies Mem0/Zep/Letta are built around, and it shouldn't try to. But for the large number of teams whose "AI feature" is really "search over data that was already in Postgres," it's a much shorter path than most of what got funded this year.

Who should try it, wait, or skip it

Try it now if you're already on Postgres 17/18, your AI feature reads relational or graph-shaped data you already store there, and you're comfortable running community-maintained extensions in production. Self-hosting costs nothing but engineering time to evaluate.

Wait if you need the managed product specifically — there's no price and no GA date, so budgeting around it today is guesswork — or if your workload leans on the experimental vector types (sparsevec, bitvec, IVFFlat) that aren't fully baked yet.

Skip it if you're already deep into a dedicated vector database at real scale and migration cost outweighs a theoretical latency win you haven't verified against your own data, or if what you actually need is an opinionated agent-memory policy layer (summarization, forgetting, session scoping) rather than a faster retrieval engine underneath one.

Either way, the more durable story here isn't one product — it's the question it raises for the rest of the AI-infra market: how much of the "new database for AI" wave was solving a real technical limitation, and how much was skipping the less exciting work of making Postgres do it well?

Discussion: if you've put pgvector, a dedicated vector database, and a graph database in front of the same Postgres-backed app, which piece actually caused you the most operational pain — the sync jobs, the permissions drift, the query latency, or something else entirely?

Sources:

Omarchy Turned Arch Linux Into One Command. Apple Silicon Turned That Command Into a Support Thread.

Daniel Kim — Thu, 20 Aug 2026 06:14:58 +0000

Omarchy picked up more than 2,200 stars in the past week alone, pushing it past 26,800 total and onto GitHub's weekly trending page — the kind of number that usually belongs to a new JavaScript framework or an LLM wrapper, not a Linux desktop config. It's built by David Heinemeier Hansson (DHH), the person who wrote Ruby on Rails and who runs product at Basecamp and HEY, and it does something that sounds almost too small to justify the attention: it turns a fresh Arch Linux install into a fully configured Hyprland desktop with one command.

The pitch is "beautiful, modern & opinionated Linux," and on a supported machine that pitch mostly holds up. But the most instructive thing about Omarchy right now isn't the install script — it's a 150-plus-comment GitHub discussion full of developers trying to run it on the one class of laptop its target audience is most likely to already own: MacBooks. Watching that thread tells you more about what "opinionated" costs than the README does.

What actually happened

Omarchy isn't new — it's been public for over a year — but it's having a trending moment this week, sitting in GitHub's top-15 weekly list alongside things like public-apis and Basecamp's own omakub. The repo currently shows 489 open issues and 558 open pull requests, which for a desktop-config project is an unusually large amount of live surface area — more typical of a mid-size application than a dotfiles repo. It's MIT-licensed, maintained under the Basecamp GitHub org, and it's the direct sibling of an earlier DHH project, Omakub, which does the same "one command, fully configured desktop" trick for Ubuntu instead of Arch. Omakub sits at roughly 8,100 stars — a third of Omarchy's — which is itself a small signal about which base OS developers actually want this kind of product on.

What it actually does

Strip away the branding and Omarchy is a large, opinionated installer, not a distro image you boot from an ISO. You start with a working Arch Linux system, run Omarchy's install script, and it takes over from there: partitioning assumptions, disk encryption, window manager, terminal, editor, and a curated app catalog, all in one pass.

Concretely, a default install includes:

Hyprland as the compositor/window manager (Wayland-based, tiling)
Alacritty as the terminal and Neovim with a preconfigured setup as the editor, alongside tmux
A curated commercial-app layer — 1Password, Basecamp, ChatGPT, Chromium, LibreOffice, and Spotify are all listed as bundled defaults
Dedicated categories in the project's manual for AI tools, TUIs and GUIs, PDF handling, gaming, and even Windows VM support for the rare app that needs it
Mandatory full-disk encryption via LUKS — this isn't an install-time checkbox, it's baked into the default flow with no documented opt-out
A built-in theming system, with manual sections dedicated to both using the bundled themes and authoring your own
An update and migration mechanism, plus system snapshot support, so an existing install can be moved forward rather than reinstalled from scratch

That last point is the most structurally interesting part of the project and the part least visible from the marketing copy. The repository ships a top-level migrations/ directory alongside install/, config/, themes/, and applications/. That's a very Rails-flavored idea transplanted onto a desktop OS: instead of "reinstall when something changes," each new Omarchy release can ship an incremental migration that's applied to your existing machine, the same way a Rails app applies a schema migration instead of rebuilding the database. It's a small design choice, but it's the clearest fingerprint of who built this — someone whose entire professional identity is "convention over configuration," now applied to ~/.config instead of app/models.

There's a second, quieter signal sitting at the repository root that's worth pulling out on its own: AGENTS.md, CLAUDE.md, and an agents/skills/ directory. A Linux desktop-configuration project — not an application, not a framework, a dotfiles-and-install-scripts repo — ships its own instructions for AI coding agents and a folder of pre-built agent skills. That's a small thing, but it's a useful data point on how far "write the CLAUDE.md so an agent can safely touch this codebase" has spread as a default engineering practice by mid-2026: it's not just SaaS backends and API wrappers doing it anymore, it's show up-and-configure-your-desktop shell scripts too. The manual itself even carves out a dedicated "AI tools" category among the bundled default software, separate from the general dev-utilities section — Omarchy treats an AI coding assistant as baseline desktop software in the same tier as a terminal emulator, not as an optional extra.

How it's different from "just install Hyprland yourself"

Hyprland has had a large, active ricing and dotfiles community for a couple of years, and Omarchy is not the first project to wrap an installer around it. JaKooLit/Arch-Hyprland, for example, is a roughly 4,600-star automated installer that layers Hyprland onto an existing Arch (or Arch-derivative) system — but by the maintainer's own description, "this repo does not contain Hyprland dots or configs," it pulls those from a companion repo and leaves package selection editable before you run it.

That's the actual axis Omarchy differentiates on. JaKooLit's project, and most of the Hyprland dotfiles ecosystem generally, treats configuration as something you're expected to inspect and adjust before committing. Omarchy treats configuration as a decision that's already been made for you — theme, terminal, editor, encryption policy, bundled commercial apps and all — and the value proposition is that you don't have to make those decisions yourself. You get a real, coherent, "someone with taste already did this" desktop instead of a scaffold you're expected to finish. It's the same trade Rails made against raw PHP frameworks two decades ago, just applied to a window manager instead of a web stack.

Why this is worth developer attention

Setting up Hyprland well — picking a bar, a launcher, a notification daemon, a lock screen, a consistent GTK/Qt theme, and getting them to actually agree with each other visually — is a multi-day project even for people who enjoy it. Omarchy collapses that into an afternoon, and it does so with genuinely good default taste, which is the part screenshots don't fully convey but the churn of stars this week suggests people are finding out anyway.

The more interesting reason to care isn't the time savings, though — it's what the project says about a specific developer migration pattern that's been building for a while: people leaving macOS for Linux specifically because they want a machine that isn't managed by a vendor's roadmap, and who don't want to spend the first two weeks of that decision fighting a window manager instead of doing the work that made them want to leave in the first place. Omarchy is a bet that a large enough slice of that group would rather adopt somebody else's fully-formed opinion than assemble their own, the same bet Rails made about server-side web frameworks.

Run that through the usual adoption criteria and the picture is mixed in a useful way:

Cost: zero — it's MIT-licensed and free, but the bundled commercial apps (1Password, Spotify) still carry their own subscription costs once installed. Omarchy doesn't change your SaaS bill, it just front-loads the decision of which SaaS you'll be using.
DX: this is where it actually wins. The gap between "want a tiling Wayland desktop" and "have one that looks intentional" on stock Arch is measured in days of trial and error across GTK themes, bars, launchers, and lock screens. Omarchy collapses that to the length of one install script, and the migrations system means you're not starting that process over on every upgrade.
Lock-in: real, but shallow. Because the underlying system is still ordinary Arch and Hyprland config files, nothing stops you from ripping out any single piece — the theme engine, the bundled app list, even the migrations workflow — and running the rest bare. You're locked into a set of starting defaults, not a platform.
Security: mandatory LUKS by default is a genuine, unambiguous win over most "quick install" scripts in this space, which tend to treat encryption as an advanced option nobody enables. The tradeoff is control — you can't disable it through the documented flow even when you have a good reason to.
Maintainability: this is the open question. A 489-issue, 558-PR backlog on a project moving this fast means "maintainable" currently depends on an active maintainer team staying ahead of a growing, hardware-diverse user base — not yet a settled, boring property of the software the way it is for, say, a five-year-old Ubuntu LTS release.

Practical use cases

The clearest fit is a developer setting up a new machine from scratch — a fresh laptop, a home workstation, a machine being repurposed after years on macOS or Windows — who wants a genuinely usable tiling desktop without spending a weekend on it. Omarchy is also a reasonable choice for standardizing a small team or personal fleet on the same base config: because updates flow through the migrations system rather than requiring a fresh image each time, a solo developer or small shop can keep several Omarchy machines converging on the same defaults without hand-maintaining a dotfiles repo themselves.

It's a weaker fit for anyone who needs a single, shared, long-lived reference machine — a build server, a kiosk, anything where "opinionated and frequently changing" is a liability rather than a feature — and a poor fit today for anyone whose only available hardware is Apple Silicon, for the reasons the MacBook thread makes explicit.

Where the hype runs into hardware

Here's the part that doesn't show up in the pitch: a huge fraction of the developers most likely to want exactly what Omarchy sells — "leave the vendor-managed desktop, keep a coherent, tasteful environment" — are, right now, sitting on Apple Silicon hardware. And Omarchy's relationship with that hardware is close to nonexistent.

GitHub Discussion #155 is a running log of people trying to get Omarchy onto MacBooks via Asahi Linux (the reverse-engineered Apple Silicon Linux project), and it reads like a completely different, much rougher piece of software than the one in the README:

The stock install script fails outright on aarch64 because a number of packages Omarchy depends on simply don't have ARM builds
Full-disk encryption through archinstall — the mechanism Omarchy leans on by default — doesn't work on Asahi Alarm at all
Wi-Fi requires manually installing broadcom-wl firmware by hand
GPU acceleration was broken out of the box because the wrong Mesa package got selected for the platform
Audio doesn't work
The trackpad and keyboard are dead during the LUKS decryption prompt — on a laptop, that's not a cosmetic bug, it's a boot blocker
The app launcher (Walker) fails to open via its keybinding on several machines
Thunderbolt/USB-C display output doesn't work on Mac minis

The community workarounds are exactly what you'd expect from a project that wasn't built with this hardware in mind: commenting out set -e so the installer limps past failures instead of aborting, manually reinstalling Mesa from the Asahi Alarm repo, setting GSK_RENDERER=ngl as an environment variable to fix the launcher, and eventually a pair of undocumented flags — OMARCHY_ARM=true and OMARCHY_BARE=true — that get you a more reliable, if bare-bones, install. Maintainers engaged in the thread and fixed the Mesa selection issue, and pointed contributors toward upstreaming more of this — but the canonical fix that actually works today is a separate, third-party fork, omarchy-mac, maintained outside the Basecamp org, that only claims solid support for M1/M2 chips; M3 and M4 are explicitly waiting on further Asahi progress.

None of this is a criticism of the maintainers for not solving Apple Silicon support — Asahi Linux itself is still filling in real hardware gaps, and that's arguably not Omarchy's problem to fix. It's a criticism of the framing. "Opinionated" is being sold as a universal virtue — fewer decisions, more taste, no bikeshedding — but what the MacBook thread actually shows is that the opinions were formed against a specific, presumably x86, hardware target, and the parts of "opinionated" that don't survive contact with different silicon (disk encryption flow, GPU driver selection, package availability) are exactly the parts a newcomer has no way to know about until the installer fails midway through.

The tradeoffs the docs don't foreground

A few other constraints are easy to miss reading the manual sections in isolation:

No opt-out on full-disk LUKS encryption. That's a reasonable default for a personal laptop and a genuinely bad one for anyone who wants to dual-boot, run this in a VM for testing, or hand a machine to someone who'll forget the passphrase. There's no documented flag to skip it in the default flow.
Arch as a foundation is still Arch. Omarchy smooths over the setup pain of Arch, not the maintenance reality of it — it's still a rolling-release distro where a bad upstream package can break your session on an ordinary pacman -Syu. The migration system helps Omarchy-specific config move forward cleanly, but it doesn't insulate you from Arch's own volatility.
489 open issues and 558 open PRs is a lot of unresolved surface for a project whose main promise is "it just works." That volume is a natural side effect of fast growth, but it also means the gap between "the demo" and "your specific hardware" is currently being closed in public, one thread at a time, rather than something you can assume is already solved.
The commercial app bundle is a real design choice, not filler. Shipping 1Password, ChatGPT, and Spotify by default is convenient if you already use all three, and dead weight — or a trust question — if you don't. An "opinionated" desktop that bundles proprietary SaaS clients by default is a different kind of opinionated than one that just picks a tiling window manager and a font.

How it stacks up

	Omarchy	Omakub	JaKooLit/Arch-Hyprland	Hand-rolled dotfiles
Base OS	Arch Linux	Ubuntu	Arch / Arch derivatives	Whatever you already run
Stars (approx.)	26.8k	8.1k	4.6k	N/A
Window manager	Hyprland (Wayland)	GNOME-based desktop	Hyprland (Wayland)	Your choice
Apple Silicon support	Unofficial, community fork only	N/A (x86-oriented)	Not a primary target	Depends entirely on you
Disk encryption	Mandatory LUKS, no opt-out	Not enforced	Optional, user-configured	Your call
Bundled commercial apps	Yes (1Password, Spotify, ChatGPT, etc.)	Curated dev tools, lighter on SaaS	No — installer only, no app curation	None by default
Config philosophy	Fully opinionated, minimal choices	Fully opinionated, minimal choices	Opinionated installer, editable package list	Fully yours
Update model	Versioned migrations + snapshots	Versioned migrations	Re-run script / manual	Manual

The honest way to read that table: Omarchy and Omakub are the same philosophy applied to two different base distros by the same author, JaKooLit is a lighter-weight, more editable version of the same underlying idea, and hand-rolled dotfiles are what all of these exist to save you from doing yourself.

An independent read

Omarchy is good software with a marketing claim that's slightly bigger than the product. The engineering is real — the migrations system, the snapshot support, the sheer coherence of the default theme and app choices are not trivial to get right, and the star trajectory reflects a genuine, well-executed idea, not hype for hype's sake. But "opinionated" is doing a lot of quiet work in the pitch. It reads as "we made the good decisions so you don't have to," and for the hardware and workflow it was actually built and tested against, that's probably true. For Apple Silicon owners — arguably the single largest pool of developers curious enough about a DHH project to try it this week — "opinionated" currently means "decisions were made without you in the room," and the MacBook thread is the receipt.

That's not a reason to skip it. It's a reason to know, before you run the installer, which category of user you are.

It's also worth naming what Omarchy gets right that's easy to undervalue precisely because it's boring: shipping working full-disk encryption by default, on a project whose whole premise is "make Linux desktop setup fast," is the kind of decision that's very easy to skip under time pressure and this project didn't skip it. Most "one command, full desktop" scripts in the Hyprland ecosystem treat security as an advanced-user afterthought you opt into later, if you remember to. Omarchy inverted that — encryption is the default and speed is what you have to work for around it — and that ordering says something honest about the project's priorities that the trending-repo star count alone doesn't capture.

Who should actually try this

Try it now if you already run x86 hardware (or a well-supported laptop line — Framework and System76 machines show up favorably in the community discussions around this ecosystem), you're comfortable with Arch's rolling-release model, and you want a tiling Wayland desktop with genuinely good taste applied by default instead of assembled by you over a weekend.

Wait if you're on Apple Silicon and want this as your daily driver — the officially supported path doesn't exist yet, and you'd be running a third-party fork with an M-series ceiling for now, plus the encryption and driver issues documented in the MacBook thread.

Skip it if you need a Linux desktop that's boring in the way enterprise IT wants boring — Arch's rolling-release nature and a 489-issue backlog on a fast-moving opinionated layer are not what "stable" usually means, regardless of how polished the default theme looks.

What's the actual ceiling for "opinionated by default" software once it has to serve a genuinely diverse hardware base — is convention-over-configuration a strategy that only works when the target platform is as narrow as the original decisions that shaped it?

Sources:

Lovable's 'One Balance' Billing Update Still Runs on Four Different Credit Clocks

Daniel Kim — Thu, 20 Aug 2026 03:06:54 +0000

Somewhere between March and August 2026, "AI app builder" pricing pages quietly became the least readable part of the entire category. Every vendor bills in some flavor of usage unit — credits, tokens, "effort" — and every vendor insists its version is the simple one. Lovable, the prompt-to-app builder that has spent the last two years racing Bolt.new, v0, Replit Agent, and Base44 for the same non-technical-founder wallet, just shipped the clearest test case yet of whether that's true. On June 13, 2026, it announced it was collapsing two separate account balances — one for building an app, one for running it in production — into a single pool of credits. The framing was pure simplification: one number, one dashboard, nothing to reconcile.

Read the documentation that shipped alongside it, though, and the picture is messier than the announcement post lets on. The balance is unified. The rules governing what's inside it are not. Four different credit types, three different expiry clocks, and a handful of usage grants that still don't roll over are all sitting under that single number, and as of the most recent changelog entries, the rollout itself is still gradual enough that not every workspace sees the same experience yet. This is worth a closer look not because Lovable did something uniquely bad — it's a genuinely useful change — but because it's a clean specimen of a pattern every developer evaluating one of these tools is going to run into: the sticker price is never the real price, and "we simplified billing" rarely means what it says.

What actually happened

Until this update, a paid Lovable workspace carried two separate balances. Your monthly subscription bought you build credits — the currency for generating, editing, and updating an app inside the editor. Once that app went live, a completely separate Cloud and AI balance, denominated in dollars, paid for everything the running app needed: database reads, authentication, file storage, server functions, and any AI-gateway calls the app itself made at runtime. Two ledgers, two mental models, two places to run out of money.

Lovable's announcement post says the split made sense when Lovable Cloud and Lovable AI first launched, because it mirrored how people were used to buying software — pay to build, pay separately to host. But as workspaces started shipping real production apps — the post cites Klar's AI study agent serving 6,000+ students and WeGlow's nonprofit tooling as examples — the line between "building" and "running" blurred, and reconciling two balances with two different units (credits vs. dollars) became busywork nobody asked for.

The fix: one balance, spent across both building and running, with the old Cloud/AI dollar balance converted into credits at the workspace's plan rate during migration. According to the credits and usage documentation, this is still rolling out gradually — some workspaces were, as of early August, still on the old two-balance experience. Alongside the merge, Lovable shipped three related changes worth knowing about even if you never touch the billing page:

Pause instead of fail. If a workspace runs out of credits mid-message, the build no longer just stops. A card appears in chat offering to top up and resume exactly where the run left off, or to let Lovable wrap up the current step and halt cleanly instead of starting new work. There's no deadline — paused work waits indefinitely.
Credit check-ins (beta). For long-running messages, Lovable can now pause when a single message crosses a spend threshold (20 credits by default) and show you the running cost before continuing. It's a soft cap, not a hard one — a run can overshoot the threshold slightly before the check-in fires — and you can raise the level or disable it per account.
Natural-language usage queries. You can now ask Lovable directly about your workspace's credit spend rather than digging through the dashboard.

None of these are dramatic on their own. Together, they read as a company that got enough support tickets about surprise bills to build real guardrails around them — which is itself a useful signal about how this category actually gets used in practice.

How the credit system works now

This is the part the "one balance" headline glosses over. Open Settings → Plans & credit usage on a migrated workspace and you'll find not one credit type but four, each with its own expiry rule:

Credit type	Source	Expiry
Monthly credits	Included with your plan, issued each billing cycle	2 months after issue (monthly billing) or 1 month after the annual period ends (annual billing)
Rollover credits	Unused monthly credits carried forward	Same window as monthly credits
Bonus credits	Support grants, referrals, affiliate programs	Varies
Top-up credits	One-time or auto top-ups	12 months after purchase

On top of those four, three separate usage grants exist entirely outside the rollover system: a daily build grant (5 credits/day, resetting at 00:00 UTC, capped at 30/month on the Free plan), a monthly Cloud grant (20 credits), and a monthly AI grant (4 credits). None of the three roll over — an unused Tuesday's build grant is simply gone by Wednesday. When you spend, Lovable burns the soonest-expiring general credits first, which is sensible design, but it means the "one balance" you see in the dashboard is a rendered summary of at least seven different underlying rules, not a single pool with one behavior.

The other thing the unification doesn't touch: how much a given action costs. Per a detailed teardown from DVNC Agency, Plan Mode messages run 1 credit flat, but Build Mode is priced per action — making a button gray costs roughly 0.5 credits, removing a footer 0.9, wiring up authentication with sign-up and login 1.2, and generating a landing page with three AI images and five sections 1.7. That variance is normal for how LLM-driven builders work — a landing page with generated imagery genuinely costs more compute than toggling a color — but it means budgeting "100 credits a month" as "100 things I can do" is wrong by a wide margin depending on what you're building. AxonBuild's analysis, last verified against the docs on August 5, 2026, puts it plainly: this is "three clocks, not one" — a daily reset, a period-end expiry for grants, and a rolling multi-month window for plan credits, all coexisting in the same account.

What changed vs. the rest of the category

None of this makes Lovable an outlier — it makes it typical, which is the more useful observation. Every serious competitor in the prompt-to-app space has its own version of the same problem, and comparing them side by side is where the unification actually earns some credit (pun intended), because Lovable's model, warts and all, is one of the more legible ones on the market.

Tool	Meters usage in	Entry paid plan	What can blow up your bill
Lovable	Discrete credits (build + Cloud + AI, unified)	$25/mo (Pro, 100 credits)	Image-heavy generations, complex Build Mode actions
Bolt.new	Tokens	~$25/mo (10M tokens)	Large projects — the whole file tree gets re-synced to the model on every message
v0	Credits derived from tokens	$20–30/mo (per user)	Vercel's own hosting costs stack on top, separately
Replit Agent	Effort-based (time + compute per task)	$20/mo ($20 of credits)	Autonomous debugging loops — Agent 3 can run up to 200 minutes unsupervised
Base44	Two credit types: message (build) + integration (runtime)	$16/mo (Starter)	Integration credits are charged every time a live app sends an email, calls an LLM, or generates an image

Two of these deserve a closer look, because they show what "worse than Lovable's version" actually looks like in production. Replit's effort-based pricing is the most honest in theory — you pay for what a task actually costs — and the least predictable in practice. A widely cited incident, reported by Altar.io and corroborated independently by Dreaming Press, has a founder burning $607 in overage charges within days of subscribing, and multiple other users reporting single debugging sessions costing $45 to $350 above their plan's included credits. The mechanism is structural, not a bug: Agent 3's ability to run autonomously for up to 200 minutes and spawn sub-agents is exactly the capability that lets a stuck debugging loop keep spending without anyone noticing until the invoice arrives.

Base44 — acquired by Wix in June 2025 for roughly $80 million and run since as a semi-independent product — has arguably the worst-shaped incentive of the five. Its integration credits meter runtime usage: every email, every generated image, every LLM call your shipped app makes in production burns credits, and unlike Lovable's rollover credits, none of Base44's credit types carry over. HowAIWorks.ai puts it bluntly: it's a pricing model that "punishes success," since the more real users your app has, the faster you burn integration credits, with no cheaper steady-state once you've built the thing. Base44 also carries a 2.4/5 Trustpilot rating in Altar.io's reporting, with the most common complaint pattern being AI-generated code that breaks under real use, credits spent asking the AI to fix it, and the bug persisting anyway — a failure mode that isn't unique to Base44 but is made more expensive by its billing shape.

Against that field, Lovable's unified balance is a real improvement, not a cosmetic one: build costs and running costs compete for the same pool, so a workspace can see total cost of ownership in one place instead of reconciling a credit ledger against a dollar ledger by hand. That's a genuine reduction in operational overhead for anyone managing more than a hobby project. It's just not the reduction in underlying complexity the announcement post implies — the rules didn't get simpler, they got centralized.

Where this fits architecturally

It's easy to read "credits" as an arbitrary abstraction bolted on top of a normal cloud bill, but the unification only makes sense once you see what a Lovable app actually is under the hood. A generated app isn't just static frontend code — it ships wired into Supabase for its database, auth, and file storage, and into a Lovable-operated AI gateway for any in-app AI features (the changelog notes the gateway's default model recently moved from Gemini 3.6 Flash to Gemini 3.7 Flash for apps that don't pin a specific model). Before the merge, that meant a workspace's spend was split across three genuinely different cost centers — LLM calls to generate code, Supabase-shaped infrastructure costs to run the result, and separate AI-gateway calls the shipped app makes at runtime — collapsed into two visible balances that didn't map cleanly onto either. The new single balance doesn't change what's being metered underneath; it changes the accounting layer sitting on top of it, converting three cost centers into one spendable number while preserving (and now surfacing) which of the three consumed it. That's the right instinct architecturally — the alternative, tried by nobody in this category yet, would be flat infrastructure pricing decoupled from generation activity entirely, which none of these vendors can currently afford to offer given how directly their margins depend on LLM token costs.

Practical use cases where this actually changes behavior

The unified balance matters most in three concrete situations. An agency running client work through one Lovable workspace can now see, per project and per team member, whether a client's monthly retainer is being eaten by build iteration or by that client's live app's database and AI usage — previously an exercise in cross-referencing two separate statements. A team on the Business tier evaluating whether to move a side feature's AI calls in-house versus staying on Lovable's AI gateway now has a single number to compare against a self-hosted alternative, rather than having to separately estimate build-time and run-time costs. And anyone who has hit the old failure mode — a build silently stalling because the Cloud/AI dollar balance ran dry while the separate build-credit balance still had room — gets the new pause-and-resume flow instead, which is a meaningfully better failure state than a broken deploy nobody notices until a user reports the app is down.

Where it changes nothing: solo prototyping. If you're on the Free tier building a single public project to test an idea, you were never juggling two balances in any way that mattered, and the unification is invisible to you. The people who benefit are, unsurprisingly, the people spending enough to have needed a spreadsheet before.

Why this actually matters for developers, not just founders

It's tempting to read all of this as a solo-founder problem — "just budget more credits" — but the credit-metering pattern has three effects that scale badly the moment a real team or a real customer base gets involved.

Cost forecasting breaks at the point these tools are most useful. Every comparison piece surveyed for this article — AIToolPick, ProductOS, DVNC, Dreaming Press — converges on the same warning: the plan price is a floor, not a ceiling, because none of these vendors charge a flat rate for what a "feature" costs. A landing page redesign might run 1.7 credits or 17, depending on how many images get generated and how many revision rounds it takes to get right. That's fine for prototyping. It's a genuine planning problem the moment you're trying to give a client, a manager, or a budget owner a number before starting work — something developers coming from fixed-scope estimation are not used to having to hedge against.

Team pricing shapes differ enough to matter at headcount. Lovable's Business plan shares one credit pool across unlimited seats at $50/month; Bolt scales per-user at $30/seat; v0's Business tier runs $100/user/month; Replit's Pro tier is a flat $100/month for up to 15 collaborators — the cheapest team math in the category by a wide margin, per AIToolPick's breakdown. A three-person team evaluating these tools on sticker price alone will land somewhere very different depending on whether they read "team pricing" as per-seat, flat, or pooled.

Lock-in is a billing question as much as a code-export question. This is where Lovable's positioning is genuinely stronger than it gets credit for. Code export via GitHub sync is full and unrestricted, matching Bolt and v0 and beating Base44 outright — Base44 only exports the frontend, leaving auth, business logic, and API endpoints bound to its proprietary backend SDK, confirmed independently by both HowAIWorks.ai and Altar.io. If a Base44 app takes off, migrating off the platform means rewriting the backend, not just cloning a repo. Lovable's credit rollover and unified balance don't change that calculus for anyone else in the category, but they do mean that if you do stay on Lovable, understanding what you're actually paying for is at least tractable — which is not nothing, given how opaque the alternatives are.

What the marketing leaves out

Three things worth knowing before you take "we simplified billing" at face value:

First, the rollout has been gradual since June, and as of the documentation's most recent revision, some workspaces are still on the legacy two-balance system. If you're evaluating Lovable right now, don't assume the pricing page or a colleague's dashboard matches what you'll see — check your own workspace's Plans & credit usage page directly.

Second, the credit check-in feature — the one piece of the update genuinely aimed at preventing bill shock — is beta, off by default in the sense that it only triggers past a threshold you can raise or silence, and it's a soft pause, not a hard stop. A determined runaway generation can still overshoot before the check-in fires. It's a meaningfully better guardrail than Replit or Base44 offer, but "meaningfully better than a category with no guardrails" is a low bar.

Third, the "your plan price isn't changing" line in the announcement is true and slightly beside the point. The price didn't move; what moved is how legible your spend is and how many separate rules govern it. Anyone reading the blog post as "billing got easier" without reading the docs page will be surprised the first time a top-up credit expires on a 12-month clock while their monthly credits expire on a 2-month clock in the same balance.

Who should actually care

If you're already running a production app on Lovable Cloud, this is a clear win — you get one dashboard instead of two, per-model cost visibility you didn't have before, and a pause-and-resume flow that beats hard-failing mid-build. Migrate when your workspace offers it and read the Usage Details tab once to understand where your spend actually goes; most teams underestimate how much of it is Cloud/AI runtime versus build-time generation until they can see it broken out.

If you're evaluating which of these five tools to start with, the credit-vs-token-vs-effort question should weigh more heavily than the sticker price. Teams that iterate in short, predictable sessions do fine with any of them. Teams that expect long agentic runs — multi-step refactors, autonomous debugging, anything that could plausibly run unattended for tens of minutes — should treat Replit's effort-based pricing as a real cost risk, not a footnote, given the documented $45–$607 overage range. Anyone building something with real customers and any chance of wanting to leave the platform later should weight Base44's backend lock-in heavily against its lower sticker price.

If you're a solo developer or small agency building disposable prototypes and immediately exporting to your own stack, none of this billing architecture matters much — Bolt's generous free tier and instant browser-based iteration will get you there faster, and you'll be gone before the credit clocks matter.

The honest read

Lovable's update is a real, useful piece of engineering — consolidating two billing systems that grew organically into one coherent data model is not trivial, and the visibility improvements (per-model spend, per-project breakdown, per-person usage on team plans) are things every competitor in this list should be shipping and mostly isn't. But "simplifying billing" and "simplifying the number you see" are different claims, and the gap between them is exactly where developers get burned across this entire category — not just at Lovable. Four credit types and three non-rolling grants under one balance is progress over two ledgers in two currencies. It is not the same thing as one rule.

The deeper pattern this exposes is that "credits" as a unit has become a way for an entire product category to avoid saying "we don't know what this will cost you until you run it" out loud. Lovable said it more honestly than most, with real guardrails attached. That's worth crediting. It's also worth not mistaking for the problem being solved.

What's your experience been budgeting for one of these AI app builders in a team setting — has usage-based credit pricing ever actually surprised you the way per-seat SaaS pricing never did, and if so, what changed how you scoped work around it afterward?

Sources:

This Multi-Agent Coding Harness Skips LangGraph Entirely — It Coordinates Agents With a Git Repo

Daniel Kim — Thu, 20 Aug 2026 00:12:35 +0000

Somewhere in the last 24 hours, a TypeScript desktop app named after the fictional paper company from The Office added roughly 800 GitHub stars and landed on the daily trending page. It now sits at around 2,700 stars. That kind of overnight spike usually means one of two things: a genuinely useful idea hit a nerve, or a good meme did the work a changelog couldn't. Munder Difflin is a bit of both, and the meme (pixel-art Dunder Mifflin cosplay, an AI "Michael Scott" running the show) is doing a lot of the marketing. But underneath the branding is a genuinely interesting answer to a problem most people using Claude Code, Codex, or Gemini CLI at the same time have quietly worked around with a pile of terminal tabs: how do you get more than one CLI coding agent to actually work together, instead of just running in parallel and ignoring each other.

What it actually is

Munder Difflin is not another agent framework you build on top of. It's a wrapper around the terminal agent CLIs you already have installed — Claude Code, Gemini, Codex, Grok, Kimi, and others — that gives them a shared inbox, a shared memory store, and a router that passes tasks between them. Each agent shows up as a pixel character on an office floor, "working" at a desk while its real terminal process runs underneath. It's a skin. The part worth paying attention to is what's routing the work and holding the state.

The README frames the pitch directly: individual agent CLIs work in isolation. You can run five of them, but they don't know about each other, they don't share context, and nothing coordinates who does what while you're not watching. Munder Difflin's answer is a persistent, self-coordinating group of agents that keeps working while you're away, escalating to a human only for decisions that matter.

How it's built

The architecture is described in three layers, and each one is doing something specific.

The terminal plane runs each agent as an actual pseudo-terminal process via node-pty, rendered in the UI with xterm.js. This matters more than it sounds — it means you're not talking to some abstracted "agent API," you're driving the real CLI binary byte-for-byte, the same one you'd use from a terminal. Nothing about the agent's own tool-calling, permission prompts, or output format needs to change to plug into the system.

The event plane is where the actual coordination happens, and it's the part that distinguishes this from a tmux session with fancy graphics. It's a local, git-based "hive": per-agent memory, atomic-file mailboxes for messaging, a shared blackboard for state other agents can read, and an append-only event log. A router delivers messages between agent inboxes. Sitting on top of that is a "GOD agent" — nicknamed Michael, after the show's regional manager — that adjudicates routine coordination decisions and escalates anything critical to a human. Per-agent git worktrees give agents working in parallel their own isolated checkout, so two agents editing the same repository don't stomp on each other's uncommitted changes.

The renderer is the React/Pixi.js office floor, plus a Monaco-based IDE view, a task kanban board, memory search, and activity monitoring. This is the layer generating the screenshots that got it onto trending — and it's the least technically interesting part of the system.

The choice to build the coordination layer on git rather than a database or message queue is the actual design decision worth studying, independent of whether you ever run this specific app. A git-based event log gives you free auditability (every state change is a commit, diffable and revertable), free replication (clone the hive, get the full history), and a mental model developers already understand. It also means the "memory" agents share isn't a vector database or a proprietary format — it's markdown files in a repo, described in the README as "markdown-first" for instant cross-session recall. You can read what an agent remembers by opening a file.

What changes versus what already exists

Multi-agent orchestration isn't new — CrewAI, LangGraph, and AG2 (the AutoGen fork) have been doing agent-to-agent coordination for a couple of years. But those are code-first frameworks: you define agents, roles, and handoffs in Python, and you're building a new application on top of an SDK. If you already have a workflow built around calling Claude Code or Codex from a terminal, adopting one of those frameworks means re-architecting how you interact with agents entirely, and usually means giving up the specific CLI tool you were using in favor of whatever the framework wraps natively.

Munder Difflin's bet is the opposite: don't replace the CLI, coordinate around it. That's also the meaningful difference from the recent wave of terminal-agent dashboards — tools that let you watch multiple coding agent CLIs from one terminal but stop at showing you their status. Munder Difflin's agents can message each other, write to a shared blackboard, and have a supervising agent route work between them without a human relaying instructions by hand. The distinction is the same one between a monitoring dashboard and an actual team: one shows you six people are busy, the other lets them talk to each other and lets one of them delegate.

Whether "let the agents delegate to each other autonomously" is a feature or the thing that should make you nervous is a fair question, and the README seems to know it — hence the circuit breaker for cost control and the "human gates" for spend, scope changes, and destructive operations. Those guardrails exist specifically because the failure mode of autonomous multi-agent delegation is a runaway loop that burns tokens or does something irreversible while you're asleep. Baking that concern into the architecture, rather than bolting it on later, is a reasonable sign the author has actually run this thing unsupervised and hit the problem.

Why this matters to developers, concretely

Cost. Running several agent CLIs continuously is not free, and Munder Difflin's own docs treat that as a first-class risk with a circuit breaker rather than an afterthought. If you're evaluating this, budget for the failure case where the GOD agent misjudges an escalation and lets something loop.

Lock-in. Because it wraps existing CLIs instead of replacing them, you're not migrating your prompts, tools, or workflows into a new framework's abstractions. You keep whatever agent you already trust for a given task and add coordination on top. That's a genuinely different risk profile from adopting LangGraph or CrewAI, where the framework becomes the thing your workflow depends on.

Auditability. A git-based event log and markdown memory store means you can inspect exactly what an agent "remembers" and exactly what happened, in order, without a proprietary trace format. For anyone who has debugged a multi-agent system by staring at an opaque JSON blob, this is a meaningfully better failure-diagnosis story.

Security surface. This is also where the project asks for the most trust and offers the least evidence. The marketing image claims "E2E encrypted" and "private cloud," and the README lists Slack spawning ephemeral workers, webhook ingestion, and GitHub CI watching as integrations. Each of those is a legitimate attack surface — a webhook-triggered agent with write access to your repo and a Slack integration that can spawn new workers is exactly the kind of thing a security review should sit down and go through line by line before it touches anything you care about. None of the specific claims about encryption or the "private cloud" component are substantiated in what's public; take them as marketing copy until you've read the code that backs them.

Where this sits next to Claude Code's own subagents

It's worth being precise about a comparison people will reach for immediately: Claude Code already has a Task tool for spawning subagents, and Anthropic's own agent SDK supports multi-agent patterns within a single Claude session. That's not the same problem Munder Difflin is solving. Claude Code's subagents are homogeneous — they're all Claude, coordinated inside one process, sharing one model's context conventions. Munder Difflin's hive is explicitly heterogeneous: a Codex agent, a Gemini agent, and a Claude Code agent, each a genuinely separate process with its own CLI, its own auth, and no shared runtime, coordinated only through the files and messages the hive layer exposes to all of them. If your team already standardized on one agent, you don't need this — use that agent's native subagent or multi-step tooling instead, it'll be faster and better integrated. Munder Difflin only earns its complexity when you're actually running more than one vendor's CLI and need them to hand off work, which is a narrower audience than the star count suggests.

Practical use cases

The obvious one is the overnight shift: hand a set of well-scoped tasks to the hive before you log off, let one agent triage and route, others execute, and wake up to a kanban board with green and red tasks instead of a blank terminal history. A second is role specialization without hand-rolling a framework — one agent watches GitHub CI, one drafts fixes, one reviews, and the GOD agent decides when a human actually needs to look. A third is the Slack-triggered ephemeral worker pattern: someone posts a request in a channel, a fresh agent spins up, does the work, and reports back, without anyone opening a terminal.

What the announcement leaves out

A few things the README doesn't dwell on, and that anyone evaluating this seriously should chase down before trusting it with real access:

Maturity. The project's own badge reads "status: working prototype." Version 0.4.4 just fixed a bug where agents couldn't message each other at all on Windows — a core feature of the product, broken until very recently on a major platform. That's not a knock on the project (prototypes have bugs), but it's a reason to treat "autonomous overnight operation" as aspirational rather than proven.
Concurrency correctness. Per-agent git worktrees solve the obvious case of two agents editing the same repo, but the README doesn't describe how conflicts are resolved when multiple worktrees need to merge back to a shared branch, or what happens when the blackboard is written to by two agents in the same tick. Git-based coordination is auditable; it isn't automatically safe under concurrent writes.
Star velocity isn't a maturity signal. Adding 800 stars in a day tells you a Reddit, Hacker News, or X post landed well — usually thanks to the Office branding and the office-floor visualization, which are the most shareable, least architecturally significant parts of the project. It says nothing about how many people have actually run it unsupervised for a week.
Unverified security claims. As above — "E2E encrypted" and "private cloud" appear on the marketing image with no elaboration in the public README. Given the integrations on offer (webhooks, Slack spawning, CI watching, agents with repo write access), this is the single most important thing to verify before granting it real credentials.
Sustainability. It's built by a small group (the README credits a primary author plus a couple of named collaborators, alongside GitHub Actions and — notably — "Claude (Anthropic)" itself in the contributor list, presumably from Claude Code being used to help write the tool that now orchestrates Claude Code). That's a fun bit of self-reference, but it's also a reminder this is a small-team open-source project, not a funded product with an SLA.

Independent read

The pixel-art office and the Michael Scott framing are doing real work — they're the reason this is trending instead of sitting at a few hundred stars like a dozen similar multi-agent harnesses. Strip the cosmetics away and what's left is a legitimately clever piece of systems design: coordinate heterogeneous, already-trusted CLI agents through a git-based event log and shared markdown memory, rather than forcing them into a new framework's agent abstraction. That's a lower-friction path to multi-agent coordination than anything CrewAI or LangGraph offers if your team has already standardized on specific terminal agents and doesn't want to re-platform.

The risk is that the same branding that got it 800 stars in a day will get it 800 installs from people who read "clones for you and your team, working 24/7" and skip straight past "working prototype," "E2E encrypted" with no supporting detail, and a Windows messaging bug fixed in the last point release. The circuit breaker and human gates are the right instincts. Whether they're implemented well enough to trust with a webhook that can spawn agents with repo write access is a question the README doesn't answer, and one worth answering yourself, in the code, before this touches anything that matters.

Who should look at this

Try it if you're already running two or more CLI coding agents daily, you're comfortable being the human escalation point, and you want to experiment with letting them hand off work to each other on a project where the blast radius of a mistake is small.

Study the architecture, skip the app if what interests you is the git-based hive-mind pattern — markdown memory, atomic mailboxes, append-only event log, per-agent worktrees — and you'd rather implement a narrower version of it yourself against a single trusted agent than adopt someone else's prototype wholesale.

Wait if you need anything resembling a compliance story, an SLA, or confidence that concurrent writes won't corrupt shared state. "Working prototype" is an honest label; take it at face value.

Ignore it if you're happy running a single capable agent per task and don't have a coordination problem to solve. Multi-agent orchestration is a solution to a specific pain (context-switching across five terminal tabs, no shared state between agents), and if you don't have that pain yet, none of this changes your day.

If you've actually tried coordinating multiple CLI agents on a real codebase — whether with something like this, a hand-rolled tmux setup, or a framework like CrewAI — what broke first: the coordination logic, the shared state, or your trust in letting it run unsupervised?

Sources:

InsForge Teaches AI Agents to Run Your Backend. It Hasn't Learned to Keep Postgres Alive Yet.

Daniel Kim — Wed, 19 Aug 2026 12:45:06 +0000

Every backend-as-a-service platform since Firebase has been designed around the same assumption: a human opens a dashboard, clicks through a schema editor, copies an API key, and wires it into an app. Supabase modernized that flow with a nicer UI and a Postgres core, but it kept the human in the loop as the operator.

InsForge, which shipped its 2.0 release on Product Hunt this month, throws that assumption out. Its dashboard is an afterthought. The primary user it's designed for is a coding agent — Claude Code, Cursor, or anything that speaks MCP — reading your backend's schema, deploying your edge functions, and running your migrations without you touching a UI at all. The company is part of Y Combinator's Spring 2026 batch, raised $1.5M in pre-seed funding, and its GitHub repo has been climbing fast enough that different write-ups from the past few weeks cite wildly different star counts — anywhere from roughly 2,000 to north of 10,000, depending on the day you looked.

That's the headline. The more interesting story is what an independent Postgres operator found when they actually opened the hood: a genuinely clever agent-facing API layer sitting on top of a database that, by the maintainer's own repo structure, is still a single Docker container with no failover, no monitoring, and no automated backup. InsForge solved the "AI agent talking to your backend" problem convincingly. It has not yet solved the "your backend stays up" problem, and that gap is worth understanding before you point an autonomous agent at it.

This isn't a niche curiosity, either. It's a direct response to a problem the "vibe coding" wave surfaced and never really solved: agents are extremely good at writing frontend code and increasingly good at writing backend logic, but the actual infrastructure underneath — the database schema, the auth config, the storage bucket policies — has stayed a human-mediated bottleneck. You'd watch an agent write a beautiful migration file and then... you'd be the one who had to open a dashboard, paste it into a SQL editor, and run it. InsForge's bet is that this handoff step is unnecessary friction, and that removing it is worth rebuilding the backend stack around.

What InsForge actually is

InsForge is an open-source (Apache-2.0), self-hostable backend platform that bundles the pieces most apps need — authentication, a relational database, file storage, serverless functions, an LLM gateway, and site deployment — and exposes all of it through interfaces built for agents rather than humans:

Database: a standard Postgres instance, accessed through PostgREST for auto-generated REST endpoints.
Authentication: user management, sessions, and auth providers.
Storage: an S3-compatible object store (bundled MinIO or RustFS by default, or bring your own — AWS S3, Wasabi, Cloudflare R2, Tencent COS, Aliyun OSS).
Edge Functions: serverless functions running on Deno.
Model Gateway: an OpenAI-compatible API that fans out to multiple LLM providers.
Compute (private preview): longer-running container services.
Site Deployment: build and deploy static/SSR frontends alongside the backend.

None of these primitives are novel — this is the same feature list Supabase, Appwrite, and Firebase have shipped for years. What's different is who's meant to operate them. The GitHub description puts it plainly: it's a platform that "gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end." Not "gives you" — gives your agent. That's a small wording choice with a large architectural consequence: every design decision downstream of it, from how errors are formatted to what the setup script auto-generates, optimizes for an agent's ability to parse and act on it, not a human's ability to read it comfortably in a dashboard.

How it works

InsForge runs as five Docker containers via Docker Compose — a Postgres database, PostgREST, the InsForge application server, an auth service, and a Deno runtime for edge functions — spun up with a single setup script that generates a JWT secret, an encryption key, database credentials, and API keys into a local .env file. You can also deploy it with one click on Railway, Zeabur, or Sealos, or skip self-hosting entirely and use the managed cloud at insforge.dev.

The part that matters is the interface layer on top of those containers. Agents talk to InsForge through one of two paths:

An MCP Server (available both self-hosted and on the managed cloud) that exposes every backend operation — deploy a function, run a migration, create a storage bucket, configure an auth provider, pull runtime logs — as a tool call any MCP-compatible agent can invoke.
A CLI paired with Skills (cloud-only) that an agent can invoke directly from a terminal instead of going through MCP.

Both paths give the agent two categories of capability the README is explicit about: it can read backend context — documentation, live schema, metadata about deployed functions and bucket contents, and runtime logs — so it has grounding before it writes code and can verify what it built after. And it can configure primitives directly: deploying functions, running migrations, provisioning auth, without a human relaying instructions through a dashboard. The verification step in the screenshot above — "call InsForge MCP's fetch-docs tool to learn about InsForge instructions" — is the whole philosophy in one line: the agent is expected to look up how the platform works itself, the same way a new backend engineer would read the internal wiki before touching production.

The repo's own architecture diagram frames it as a single fan-out: AI coding agents talk to one thing — InsForge — and InsForge fans that out into the seven subsystems (auth, database, storage, edge functions, model gateway, compute, deployment). The point of that shape is that the agent never has to know it's coordinating seven different services with seven different APIs and seven different failure modes; it knows one MCP surface, and InsForge is responsible for translating a single "deploy this function and wire it to this table" instruction into the right calls against Deno, PostgREST, and Postgres underneath.

Getting it running is refreshingly boring for something this ambitious. A setup script pulls the compose files and generates secrets into a local .env; docker compose up -d brings up the five containers; you open localhost:7130, connect an MCP client (Cursor, in the screenshot above), and send a one-line prompt telling the agent to go read the docs. Running multiple isolated projects is just multiple directories with distinct COMPOSE_PROJECT_NAME values and non-colliding ports — no orchestration layer required. Storage defaults to the local filesystem, but swapping in bundled MinIO or an Apache-2.0-licensed alternative called RustFS is a one-line compose overlay away, and bringing your own S3-compatible bucket (AWS, Cloudflare R2, Wasabi, Tencent COS, Aliyun OSS) is a handful of environment variables. None of this is exotic system design — it's competent, unglamorous Docker Compose engineering, which is exactly what you'd want underneath something an agent is going to be poking at unsupervised.

What changed versus the Supabase model

Supabase's MCP server exists too — you can already point Claude Code or Cursor at a Supabase project through MCP. The difference InsForge is betting on isn't availability of an agent interface, it's what that interface was designed for. Supabase's surfaces (SQL editor, migration files, dashboard-driven config) were built for a human first and retrofitted with an agent-accessible layer second. InsForge inverts the build order: the semantic layer, the fetch-docs tool, and the structured tool responses are the primary product, and the dashboard is a secondary convenience.

InsForge's own benchmark, MCPMark, tries to put a number on that difference. Running 21 real-world backend tasks, the company reports InsForge completing them roughly 1.6x faster than Supabase's MCP server, using about 30% fewer tokens, with a 47.6% task-pass rate versus 28.6% for Supabase. A more recent v2 run against Claude Sonnet 4.6 reportedly widened that further — 28% higher accuracy while using 2.4x fewer tokens. Take those numbers for what they are: a vendor measuring itself against a competitor using its own benchmark suite, not a neutral third-party eval. The direction of the result (a platform purpose-built for agent tool-calling outperforms one that wasn't) is plausible on its face; the magnitude deserves the standard skepticism any self-reported benchmark earns.

It's worth sitting with why that direction is plausible, though, rather than just discounting the whole thing as marketing math. When an agent hits Supabase through its MCP server today, it's usually navigating APIs and error formats designed for a human debugging in a browser — verbose Postgres error strings, dashboard-oriented pagination, config surfaces that assume a person reading a settings page. Every one of those design choices costs an agent extra reasoning tokens to parse and extra turns to recover from when something goes wrong. InsForge's tool responses and its fetch-docs entry point are shaped for exactly the failure mode agents hit most: not knowing what's already there. Whether that's worth a full 1.6x in a controlled, vendor-run benchmark is a separate question from whether the underlying mechanism is real — it plausibly is.

Why this should matter to developers

Cost: self-hosting is free and Apache-2.0 licensed — genuinely open source, not open-core with the useful parts gated. The managed cloud has a free tier with unspecified limits and paid tiers the team hasn't published in detail yet, which makes it hard to budget against today if you're evaluating the hosted option for anything beyond a prototype.

DX: the actual pitch is fewer round trips. Instead of an agent guessing at your schema, hallucinating a column that doesn't exist, or asking you to paste error output back into the chat, it can query the live schema and pull structured logs itself. If you've watched a coding agent burn a turn re-deriving context it already had access to a minute ago, this is a direct answer to that specific waste.

Lock-in: low, on paper — Apache-2.0, self-hostable, standard Postgres underneath. You're not locked into a proprietary query language the way you are with Convex's document model.

Security: the setup script auto-generates JWT secrets and encryption keys per instance rather than shipping default credentials, which is the right default. But the bigger security question isn't credential hygiene, it's blast radius — an agent with standing MCP access to deploy functions and run migrations is a new kind of privileged actor in your stack, and InsForge's docs don't yet say much about scoping that access down (per-project keys exist, but fine-grained permissions within a project are thin).

Maintainability: this is where the story gets less flattering, and it's covered in detail below.

Put those together and the value proposition is narrower than "AI-native backend" makes it sound. It's not that InsForge does something Postgres and PostgREST couldn't already do — it's that it removes a specific, recurring tax: the seconds-to-minutes an agent spends re-establishing context about a backend it configured five minutes ago in a previous turn, multiplied across every session, every schema change, every deploy. If your workflow already has an agent iterating on a backend dozens of times a day, that tax adds up. If a human is going to open a dashboard and review every migration before it ships anyway, most of InsForge's differentiation disappears and you're left comparing it to Supabase on ordinary BaaS terms — where Supabase's five-year head start on tooling and community still counts for a lot.

Practical use cases

Agent-driven prototyping: you're vibe-coding an MVP with Claude Code or Cursor and don't want to hand-configure Postgres, auth, and storage before the agent can even start building features.
Hackathons and internal tools: fast, disposable backends where "an agent can spin this up and tear it down without me babysitting it" is the actual requirement, not a nice-to-have.
Per-branch ephemeral backends: since setup is scriptable and instances are cheap to spin up with distinct ports and project names, it's plausible to give an agent a fresh backend per feature branch or PR and have it self-provision what it needs.
Teams without a dedicated backend engineer: the semantic layer is explicitly trying to let a frontend-leaning team let their coding agent handle backend configuration that would otherwise require someone who knows Postgres migrations and auth flows.
Multi-tenant demo environments: because whole instances are cheap to declare and isolate by directory and port range, it's a reasonable fit for spinning up an isolated backend per customer demo or per sales-eval sandbox, then tearing it down without leaving orphaned config in a shared project.
Agent evaluation harnesses: if you're building or testing your own coding agent and need a realistic, disposable backend target for it to operate against — closer to a real Postgres-backed app than a mocked API — a fresh InsForge instance is a cheaper target to stand up than a full Supabase project per test run.

What it's a weaker fit for is anything where "the agent configured it and it looked right" isn't a sufficient bar — which, per the AI-generated-code security research this year, is a real and common failure mode. A 2026 grey-literature review of vibe coding practice found that developers using AI-first workflows frequently skip testing, accept model output without modification, and delegate verification back to the same tools that generated the code in the first place. InsForge's MCP layer makes an agent's backend changes easier to make; it doesn't, by itself, make them easier to review. That's still a human's job, and nothing about "the agent read the docs first" changes that.

What the launch page doesn't tell you

The most substantive independent look at InsForge so far comes from Vonng, the maintainer of Pigsty, an open-source "batteries-included" Postgres distribution used for production RDS-alternative deployments. Vonng's read, after going through the InsForge stack directly: it's a thin, well-designed agent-oriented operating layer sitting on top of an ordinary Postgres instance — and that Postgres instance is exactly where the platform is weakest.

Specifically: the bundled database is a single-node Docker container with no high availability, no monitoring, and no automated backup configured out of the box. By contrast, Vonng's own Pigsty bundles Patroni for HA failover, VictoriaMetrics for monitoring, pgBackRest for automated backups, and connection pooling and load balancing — the operational scaffolding a production Postgres deployment actually needs and that InsForge's Docker Compose setup doesn't include. Documentation on self-hosted HA, backup, and hardening is, in Vonng's words, still thin. And the bundled Postgres version lags the ecosystem — InsForge ships PG15 while Pigsty has already moved to PG18.

None of this means InsForge is broken. It means InsForge solved a different problem than "run a production database," and the launch materials don't draw that line clearly. The interesting coda: Vonng liked the agent-facing layer enough to fold InsForge into Pigsty's own toolbox — pairing InsForge's MCP interface with Pigsty's actual database operations story is a reasonable way to get both halves right, but it's not what you get by default from InsForge alone.

Two more gaps worth flagging: Compute is still marked private preview in the README, so the "long-running container services" piece of the pitch isn't generally available yet. And the "maturity of the semantic layer" — how well the agent-facing abstractions hold up outside the happy path InsForge's own docs walk through — is still an open question with a project this young; a handful of independent write-ups note the vision is compelling without yet claiming it's been stress-tested at scale.

It's also worth noting what Vonng's critique implies about the managed cloud offering versus the self-hosted one, even though the public docs don't spell it out directly: a hosted platform has every incentive to run its own production Postgres behind something more resilient than a bare Docker container — connection pooling, replicas, real backups — even if the open-source repo you'd clone doesn't ship that by default. If that's true, the gap Vonng identified may be specifically a self-hosting gap rather than a platform-wide one. But that's an inference, not a confirmed fact; InsForge hasn't published details on what infrastructure sits behind the managed tier, and until they do, treating the self-hosted repo's architecture as representative of what you'd get on insforge.dev is the more conservative — and currently the only verifiable — assumption.

How it stacks up

Platform	Primary operator	Data model	Self-host story	Where it's strong
InsForge	AI agent (MCP/CLI-first)	Postgres + PostgREST	Docker Compose, 5 containers, no HA out of the box	Agent tool-calling, schema/log introspection
Supabase	Human (dashboard-first, agent bolted on)	Postgres + PostgREST	Mature, widely deployed	Ecosystem maturity, ops tooling, community
Convex	Human, TypeScript-function-first	Custom reactive document store	Cloud-only for the reactive engine	Real-time reactivity, no SQL to manage
Firebase	Human, mobile-first	Firestore (NoSQL)	Not self-hostable	Mobile SDKs, Google ecosystem
Appwrite	Human, BaaS-first	Multiple (SQL options available)	Docker Compose, more mature ops story	Self-host flexibility
PocketBase	Human, single-binary simplicity	SQLite	Single Go binary	Personal projects, low-ops prototypes

The honest summary: InsForge is the only platform in this table built agent-first from day one, and it's the least operationally mature of the group. That's not a contradiction — it's a young project that chose to solve the interface problem before the ops problem, which is a defensible sequencing decision for a two-month-old 2.0 release, but it does mean "agent-native" and "production-ready" are currently two different claims about this product.

A few of these comparisons deserve unpacking rather than a table cell. Convex is the most architecturally distinct alternative here — it's not a Postgres-with-extras play at all, it's a reactive document database where you write server-side TypeScript functions and clients get live updates automatically, no polling or webhooks required. That buys real-time UX for free, but it means Convex and InsForge aren't really substitutes for each other; you'd pick Convex because you want the reactivity model, and you'd pick InsForge (or Supabase) because you want SQL and relational guarantees. Appwrite sits closer to InsForge on the self-hosting axis — Docker Compose, open source, willing to give you infrastructure ownership — but Appwrite's agent story is still the retrofitted kind: solid product for a human operator, MCP support layered on afterward rather than designed in from the start. PocketBase is the odd one out precisely because it doesn't compete on this axis at all; a single Go binary with SQLite underneath is a different tool for a different job (personal projects, prototypes, anything that doesn't need to survive a second server), and comparing it to InsForge is really comparing two different definitions of "simple."

Who should actually use this

Try it now if you're prototyping with an AI coding agent as your primary development interface, running hackathon or internal-tool projects where downtime is an annoyance rather than an incident, or you're curious what backend development looks like when the agent — not you — is expected to read the docs first.

Wait if you need a production database with real failover and backup guarantees today. Either self-host InsForge behind something like Pigsty for the Postgres operations layer, run it on the managed cloud and get concrete answers from the InsForge team about what HA/backup story the hosted tier actually provides (the public docs don't spell this out yet), or stick with Supabase's more battle-tested ops tooling until InsForge's does.

Ignore it if your team isn't using AI coding agents as the primary way code and infrastructure get written — the entire value proposition is agent-first operation, and a human clicking through the dashboard gets a worse experience here than on Supabase or Appwrite, which were built for that workflow from the start.

Product Hunt is full of "AI-native" rebrands of existing categories that don't actually change the underlying mechanics. InsForge is a rarer thing: a platform that changes who the primary user is and rebuilds the interface around that change consistently. Whether that's enough to matter depends entirely on whether you trust an agent to be the one reading your database logs at 3 AM — and right now, per the most careful independent look at it, that's still a single Docker container's job.

If your CI pipeline let an agent provision and tear down a full Postgres-backed backend on every pull request, what's your actual blast radius the first time its semantic layer misreads a migration — and who's actually on call for that?

Sources:

An 87% Benchmark Score Just Embarrassed Every Big Lab's Browser Agent. The Winner Never Looks at the Screen.

Daniel Kim — Wed, 19 Aug 2026 12:19:58 +0000

Every agent framework shipped in the last eighteen months eventually hits the same wall: the model can reason, plan, and call tools all day, but the moment the task requires "go to this website and do something," you have to decide how the agent actually touches a browser. That decision is no longer obvious. Four distinct approaches have hardened into production options, they solve the problem in genuinely different ways, and picking the wrong one for your use case shows up later as cost blowouts, flaky test suites, or agents that silently fail on the 5% of sites that don't play by the rules.

The four are Playwright driven through Microsoft's Playwright MCP server, the open-source Browser-Use library, Browserbase's Stagehand SDK, and Anthropic's Claude computer use tool. They get lumped together constantly under "AI browser agents," but they're not competing on the same axis. One skips vision entirely and hands the model a structured tree of the page. One rebuilt itself around a lower-level browser protocol to go faster. One is a commercial SDK designed to convert AI actions into deterministic scripts over time. And one is the fallback that works when none of the other three can — at a cost most teams underestimate until the bill arrives.

Why this comparison matters right now

Two things changed in 2026 that make this decision urgent instead of academic. First, coding agents like Claude Code, Cursor, and Codex started shipping with browser tools as a default capability, not an add-on — which means the choice of browser backend is now baked into how millions of agent sessions behave, not just something a scraping team debates in a design doc. Second, the tooling itself split architecturally. For most of 2025, "AI browser agent" meant one thing: wrap Playwright, take a screenshot, ask a vision model where to click. That's no longer true. Stagehand's v3 release removed its Playwright dependency and moved to a CDP-native architecture that talks to the browser directly over the Chrome DevTools Protocol, citing a 44% improvement on complex DOM interactions. Browser-Use made the identical architectural bet independently, also dropping Playwright for direct CDP control and citing the same 44% figure on shadow DOM and iframe handling. Two competing open-source projects converged on the same conclusion at the same time: the abstraction layer that made browser automation approachable for the last decade was becoming the bottleneck for the thing everyone actually wants to build now.

Meanwhile Playwright MCP took the opposite bet — stay on top of Playwright, but ditch pixels for structure — and Anthropic's computer use tool held its ground as the only approach that needs neither a DOM nor a browser protocol at all, because it's just looking at a screen the way a person would. Four camps, four different tradeoffs, and no vendor is going to tell you when its own approach is the wrong one.

It's worth being clear that this isn't the entire market — OpenAI ships its own computer-using agent behind its API, and Google has been building an equivalent capability into its own agent stack. Both follow the same vision-first pattern as Anthropic's tool rather than the accessibility-tree or CDP approach, which is part of why Browser-Use's benchmark result is notable: an open-source library beat agents built by all three labs, including the ones whose own vision-based tools it wasn't even using. This piece focuses on the four options a working developer is actually choosing between today — the two lab-run, general-purpose "operate a computer" tools converge on the same tradeoffs as Anthropic's, so the interesting decision space is the one laid out below.

Picture the concrete decision: you're building an agent that needs to check order status across a dozen vendor portals, none of which expose an API. Do you write Playwright scripts by hand and accept that every portal redesign breaks a selector? Do you hand the task to an agent that reasons its way through each portal fresh, accepting the token cost and occasional wrong turn? Do you invest in a caching layer that gets cheaper the more it runs? Or, if two of those twelve portals are legacy Java applets with no DOM at all, do you fall back to an agent that just looks at the screen? Most real systems end up mixing two or three of these, which is exactly why understanding what each one is actually good at — not just what the landing page claims — is worth the hour it takes to read this.

What each one actually does

Playwright MCP is a Model Context Protocol server, maintained by Microsoft under an Apache-2.0 license, that exposes browser control as a set of over 50 discrete tools — navigate, click, type, snapshot, manage tabs, mock network requests, inspect storage, generate PDFs, and more. The critical design choice is what it hands back to the model after each action: not a screenshot, but Playwright's accessibility tree, a structured, semantic, text-based representation of what's on the page. There's no vision model in the loop at all. Every interaction is deterministic in the sense that the tool call operates on a real DOM element, not a guessed pixel coordinate.

Browser-Use is an open-source Python library — MIT licensed, 109.7k GitHub stars, built by Magnus Müller and Gregor Žunič — that turns natural-language task descriptions into autonomous multi-step browser sessions. You describe the goal ("apply to this job posting," "extract pricing from these 40 competitor pages"), and the agent plans and executes the sequence of actions itself, including recovery when something on the page doesn't match expectations. It supports every major LLM provider, runs locally or against a hosted cloud version, and on the Odysseys leaderboard — 200 long-horizon web tasks — it posted an 87.4% average success rate, ranking first ahead of agents built by OpenAI, Google, and Anthropic themselves.

Stagehand, maintained by Browserbase, bills itself as "the SDK for browser agents" rather than a testing framework. It exposes Playwright-compatible methods (goto, click, locator) alongside three AI-native primitives — act, observe, and extract — that accept natural-language instructions. Its distinguishing idea is caching: AI-identified actions get progressively converted into deterministic replay scripts, so a workflow that costs real inference tokens the first time it runs gets cheaper and faster every time after, without needing an LLM call at all for the steps that already worked. It ships in TypeScript, Python, and Go, and it's designed to pair with Browserbase's managed, serverless browser infrastructure, though it doesn't strictly require it.

Claude's computer use tool is Anthropic's vision-based approach: the model receives screenshots, reasons about what it sees, and outputs coordinates and keystrokes the way a human would operate a mouse and keyboard. It requires no DOM access, no accessibility tree, no browser automation library at all — which is precisely the point. It works on canvas-rendered applications, legacy software with no accessible markup, and anything else where there's no structured hook to grab onto, because it's controlling the screen, not the page.

How they're actually built — and what changed

The through-line across all four tools in 2026 is a retreat from screenshots as the default interface between model and browser, everywhere except the one tool built explicitly for the case where screenshots are unavoidable. Playwright MCP never used them in the first place. Browser-Use and Stagehand both used to sit on top of Playwright and both ripped that dependency out in favor of talking to Chrome directly over CDP, independently arriving at the same headline number for the speedup on the hardest cases (shadow DOM, iframes, nested and dynamic content) — a strong signal that Playwright's abstraction, built primarily for deterministic testing, was adding real latency for agents that need to observe and re-plan on every step.

That convergence matters more than it looks. It means the "wrap Playwright, ask GPT where to click" pattern that defined the first wave of browser agents is now considered legacy by the two projects that built it. What replaced it isn't one thing — it's a fork between accessibility-tree-as-source-of-truth (Playwright MCP) and CDP-as-source-of-truth-with-AI-on-top (Browser-Use, Stagehand). Anthropic's computer use tool sits outside this entire conversation because it was never trying to solve the same problem; it's the tool for when there is no tree and no protocol to hook into, and its architecture hasn't needed to chase this trend because vision-based control was always going to be slower and less deterministic by design, not by implementation quality.

The practical difference between "accessibility tree" and "raw CDP" is worth spelling out, because it explains why two teams solving similar problems landed on different layers of the stack. The accessibility tree is a browser-native structure built for screen readers — every element gets a role, a label, and a position in a semantic hierarchy, and Playwright already knew how to read it because that's what its own getByRole and getByLabel locators are built on. Handing that tree to an LLM means the model reasons over roughly the same representation a blind user's screen reader would use, which is compact, well-understood, and already filtered down to what's meaningfully interactive. CDP, by contrast, is the low-level protocol Chrome itself exposes for anything that wants to instrument or control the browser — DOM mutations, network events, rendering state, input dispatch — with no built-in notion of "what's a button." Building directly on CDP means Browser-Use and Stagehand get to skip Playwright's overhead and decide for themselves what to extract and how to trim it for a model's context window, which is where Stagehand's "hybrid accessibility tree trimming" and Browser-Use's own DOM-state extraction come from — both ended up reimplementing a leaner version of the same tree Playwright MCP gets for free, just with tighter control over token budget and latency.

Why developers should actually care

Cost is the sharpest differentiator, and it isn't close. Claude's computer use tool can burn 50,000 to 200,000+ tokens on a single multi-step workflow because every action requires a fresh screenshot and a vision-model reasoning pass — at Anthropic's current published rates that's real money per task, not a rounding error, and it compounds fast at any kind of scale. Playwright MCP and Browser-Use, by only sending structured text (the accessibility tree, or targeted CDP state) instead of images, use a fraction of that per step. Stagehand goes further: its caching model means the first run of a workflow costs inference tokens, but every subsequent run of the same flow can skip the LLM call entirely and replay the deterministic script, which is a genuinely different cost curve than the other three — it degrades toward near-zero marginal cost for repeated tasks instead of staying flat.

Latency follows the same pattern for the same reason: screenshot-plus-vision-reasoning is inherently slower than reading a tree or issuing a CDP command, and removing Playwright's translation layer (Stagehand v3, Browser-Use) shaved meaningful time off the hardest interaction cases.

DX cuts differently. Playwright MCP is the most familiar to anyone who's written Playwright tests — the mental model transfers directly, and it slots into any MCP-compatible agent (Claude Code, Cursor, and others) with no code, just config. Browser-Use optimizes for "describe the goal, let the agent figure out the steps," which is the fastest path from zero to a working automation but the hardest to debug when it goes sideways in a way you didn't anticipate. Stagehand explicitly targets teams that want a middle ground — write deterministic code where you can, drop into natural language only where the page is unpredictable — which is a genuinely different engineering posture than "hand the whole task to an agent" or "write imperative test code."

Lock-in is where the vendor incentives show. Playwright MCP and Browser-Use are both fully open source with permissive licenses and no required hosted component — you can run either entirely on your own infrastructure forever. Stagehand is open source too, but its natural gravitational pull is toward Browserbase's paid, managed browser infrastructure, and the caching/optimization story gets meaningfully better the more of the stack you run on their platform. Claude's computer use tool has no self-hosted alternative at all; it's an Anthropic API capability, full stop.

Security deserves more attention than any vendor's landing page gives it. Playwright MCP's own documentation states outright that it is "not a security boundary" and points teams to MCP security best practices before deploying it — a direct admission that giving an LLM 50+ browser tools, including network mocking and storage access, is a real attack surface if the agent processes untrusted content. Computer use carries a starker version of the same risk: an agent that can see and click anything on a screen and has no concept of scope is explicitly recommended by Anthropic to run only in a sandboxed environment with limited permissions, never on a primary machine, because a model that misreads a malicious page can act on it exactly as if a human had.

Maintainability is the long-game question nobody markets well. Stagehand's replay-script caching is explicitly a maintainability feature — it converts "AI figured this out once" into "this is now a boring deterministic script," which is a real answer to the classic complaint that AI-driven automation is unpredictable in production. Browser-Use and Playwright MCP don't have an equivalent built-in mechanism; every run re-derives the plan, which is more resilient to site changes but also means you're paying the reasoning cost and accepting the non-determinism every single time, forever.

Practical use cases per option

Playwright MCP is the right default when you're wiring browser access into an existing coding agent (Claude Code, Cursor, any MCP client) for one-off or exploratory tasks — filling out a form during development, checking that a UI change rendered correctly, scraping a page while you're already in a terminal session. It's free, it's fast to set up, and because it's deterministic and text-based, it's also a legitimate fit for QA and test automation, not just agentic exploration — several teams are using it as a Playwright-compatible test runner that an LLM can drive interactively rather than only through hand-written scripts.

Browser-Use fits autonomous, long-horizon tasks where you want to describe an outcome and let the agent figure out the path: bulk job applications, competitive price monitoring across dozens of sites with different layouts, lead generation, or any workflow where writing per-site selectors doesn't scale. Its benchmark strength is specifically on multi-step tasks that require recovering from unexpected page states, which is the exact scenario hand-written scripts break on.

Stagehand plus Browserbase is built for production pipelines that run the same handful of workflows repeatedly at volume — checkout testing, data extraction jobs, monitoring flows — where the cost curve of "pay AI tokens once, replay a script forever after" actually pays off, and where you want managed, scaled browser infrastructure instead of running headless Chrome instances yourself.

Claude's computer use tool earns its cost premium specifically where the other three can't function at all: canvas-rendered apps (design tools, some dashboards, games), legacy desktop software, or any interface with no accessible DOM or CDP hook to grab. It's also the right tool for genuinely general-purpose "operate this computer" tasks that go beyond a browser tab — the same capability extends to any application on screen, which none of the browser-specific tools can claim.

Getting started with each

The integration effort differs enough to be a real factor in which one you reach for first. Playwright MCP is a single npx @playwright/mcp@latest away from running as a local MCP server, and any MCP-compatible client — Claude Code, Cursor, Claude Desktop — picks it up through a few lines of JSON config; there's no account, no API key beyond whatever LLM you're already using, and no code to write unless you want to customize its capabilities. Browser-Use is a pip install browser-use plus an API key for whichever model provider you're using, and you're writing a few lines of Python to hand it a task string — the library handles planning and execution internally, which is also why debugging it means reading agent traces rather than stepping through code you wrote. Stagehand is an npm install @browserbasehq/stagehand (or the Python/Go equivalent), and while it can run against a local Chromium instance for development, production use assumes a Browserbase API key and account — the free/local path exists but isn't where the SDK's caching and infrastructure story is optimized for. Computer use requires no browser library at all, just a beta flag on an Anthropic API call plus your own sandboxed execution environment (a VM or container with a virtual display) to actually give the model a screen to see and a mouse to move — which is also the most infrastructure any of the four demands before you write a single line of task logic.

What the marketing leaves out

Browser-Use's benchmark win is real but survivorship-biased: CAPTCHA solving is explicitly gated behind Browser Use Cloud's "stealth browsers," meaning the fully open-source, self-hosted path hits a wall on any site with real bot defenses — the 87.4% score was not run against a CAPTCHA gauntlet.

Stagehand's caching pitch undersells how much it depends on target pages staying stable. A replay script is only as good as the assumption that the site didn't change its layout since the script was recorded; the SDK's own value proposition is "self-healing" recovery when that assumption breaks, which is another way of saying the caching benefit evaporates on any site that changes frequently, and you're back to paying the AI-driven cost on every run.

Playwright MCP's "not a security boundary" disclosure is unusually honest for a README, but it's easy to skim past, and Microsoft doesn't put a security review checklist in front of you before you npm install fifty tool calls into an agent's hands.

Anthropic's computer use accuracy numbers are the most understated risk in this whole category: the tool started at roughly 15% on the OSWorld benchmark and has climbed to somewhere around 22%, against a human baseline of 72%. That's a meaningfully better trajectory than a year ago, but it is still a tool that gets a majority of complex real-world desktop tasks wrong, and the token cost for a single workflow can already run into real dollars before you factor in retries from those failures.

Comparison table

Dimension	Playwright MCP	Browser-Use	Stagehand (+ Browserbase)	Claude Computer Use
Maintainer	Microsoft	Independent (Müller/Žunič)	Browserbase, Inc.	Anthropic
License / cost	Apache-2.0, free, self-hosted	MIT, free; paid cloud for scale/CAPTCHA	MIT SDK; pairs with paid managed infra	API-metered, no self-host option
Model input	Accessibility tree (text)	CDP state + optional vision	Hybrid: CDP + trimmed accessibility tree	Screenshots (pixels)
Underlying protocol	Playwright (on top of CDP)	Direct CDP (Playwright removed)	Direct CDP as of v3 (Playwright removed)	None — OS-level screen/input
Determinism	High (tool calls hit real DOM elements)	Medium (agent re-plans each run)	High after first run (script caching)	Low (coordinate guessing from pixels)
Reported benchmark	N/A (deterministic tool, not scored)	87.4% on Odysseys (#1 among labs)	Not independently benchmarked in sources reviewed	~22% on OSWorld vs. 72% human
Token/step cost	Low (text only)	Low–medium	Low first run, near-zero on cached replays	High (50k–200k+ tokens/task)
Handles non-DOM UIs (canvas, desktop apps)	No	No	No	Yes
Explicit security caveat	Yes ("not a security boundary")	CAPTCHA/stealth gated to paid cloud	Depends on target-page stability	Yes (sandboxing strongly urged)
Best fit	Dev-tool integration, QA, exploratory agent tasks	Autonomous long-horizon multi-site tasks	High-volume repeated production workflows	Non-DOM / legacy / canvas apps

An independent read

None of these four tools is wrong, and the framing of "which one wins" is the wrong question — they occupy different points on a tradeoff between determinism, cost, and generality, and the market is still sorting out whether that will collapse into one dominant pattern or stay permanently fragmented by use case. What is worth being skeptical about is the marketing pattern common to all of them: every vendor benchmarks against the scenario it wins. Browser-Use's leaderboard win says nothing about CAPTCHA-heavy sites. Stagehand's cost story assumes stable target pages. Playwright MCP's speed and determinism say nothing about tasks that have no DOM. And computer use's generality is bought at a cost and accuracy level that would be disqualifying for any of the other three's use cases. The architectural convergence toward CDP-native, non-vision control across two independent open-source projects in the same year is the most objectively interesting signal here — it suggests the industry consensus is quietly settling on "avoid vision when you can" even as the highest-profile lab-backed tool (computer use) is vision-only by necessity, not by choice, because it's solving a problem the others explicitly can't touch.

There's also a structural point worth naming: three of these four tools are, directly or indirectly, funded by the same idea — that browser infrastructure and browser intelligence are separable businesses. Browserbase sells the infrastructure and gives away the SDK; the SDK's design choices (caching, hybrid trimming) happen to also be the choices that make its managed infrastructure more attractive at scale, which isn't a conspiracy, it's just how open-source-with-a-commercial-core projects tend to evolve. Playwright MCP has no such pull, because Microsoft isn't selling browser hosting — it's a pure devtool play, which is part of why it's the least commercially aggressive option and the easiest to trust for teams wary of lock-in. Browser-Use sits in between: fully open source at the core, with a hosted cloud tier that unlocks the CAPTCHA-handling most real-world scraping actually needs, meaning the free tier's benchmark numbers and the paid tier's real-world reliability are not quite the same product. None of this makes any of them dishonest — it just means "free and open source" and "free to actually use at production reliability" aren't always the same claim, and it's worth reading the pricing page for whichever one you pick before you architect around it.

Which reader profile should pick which option

If you're wiring browser access into an existing coding agent for development and testing work, start with Playwright MCP — it's free, familiar if you already know Playwright, and the accessibility-tree approach means you're not paying vision-model costs for routine interactions. If you need an agent to autonomously complete open-ended, multi-step tasks across sites you don't control the structure of, Browser-Use's benchmark performance and permissive license make it the strongest starting point, with the caveat that CAPTCHA-heavy targets will push you toward its paid cloud tier. If you're building a production pipeline that runs the same workflows repeatedly at real volume and you want the cost curve to improve over time rather than stay flat, Stagehand's caching model plus Browserbase's managed infrastructure is worth the commercial relationship, especially if your target pages are stable. And if your actual problem isn't a browser at all — it's a canvas app, a legacy desktop tool, or literally any UI with no DOM to hook into — computer use is the only one of the four that will work, and the cost and accuracy hit is the price of that generality, not a reason to avoid it when it's genuinely the only option on the table.

What's your experience been running these in production — has anyone gotten Stagehand's replay-script caching to hold up on sites that change their layout without warning, or does "self-healing" end up meaning you're paying the AI cost almost every time anyway?

Sources:

Holehe Checks 120 Login Pages in Seconds. Most of Them Never Fixed a 15-Year-Old Bug.

Daniel Kim — Wed, 19 Aug 2026 06:23:14 +0000

A tool that only checks whether an email address has an account somewhere shouldn't be interesting. There's no model behind it, no vector database, no agent loop. It's a Python script that sends HTTP requests to password-reset endpoints and reads the response. And yet holehe is sitting on GitHub's weekly trending page this week with 13,600+ stars, 1,800+ forks, and a growing pile of open issues from people asking it to add "just one more site."

The reason it's worth a deep dive isn't the tool itself. It's what the tool is actually measuring. Every one of holehe's 120+ site modules is, functionally, a documented account-enumeration bug — a place where a web app's "forgot password" or "sign up" flow tells you, with total confidence, whether a given email address already has an account. Holehe didn't invent this weakness. It just automated checking for it, packaged it as a single CLI command, and quietly turned it into one of the most-used OSINT reconnaissance tools on GitHub.

What it actually does

Holehe takes one input — an email address — and checks it against 120-plus online services: Twitter/X, Instagram, Discord, GitHub, Spotify, and a long tail of smaller platforms. For each service, it reports whether an account exists, and where the site's own response leaks it, whether the account has 2FA enabled or a partially-masked recovery phone/email attached.

Per its own documentation, the tool "retrieves information using the forgotten password function" and "does not alert the target email" — meaning it never actually triggers a password-reset email to land in anyone's inbox. It just asks the endpoint the question a real password reset would ask, and reads the answer off the wire.

You can run it three ways: pip3 install holehe from PyPI, clone-and-install from source, or pull the Docker image. The CLI usage is a one-liner (holehe test@example.com), and the library exposes the same checks as async Python functions built on httpx and Trio, so you can wire it into a larger pipeline and get JSON back instead of a terminal table. It's licensed GPL-3.0 and maintained mostly by its original author, megadose, with community PRs adding and fixing individual site modules.

How it works: your password-reset page as an oracle

This is the part that matters more than the star count. Almost every "forgot your password?" form on the internet has to answer one binary question before it can do anything else: does an account with this email exist? How a site answers that question — and how loudly — is the entire attack surface holehe is built on.

A well-designed reset flow gives the same response either way: "If an account with this email exists, we've sent a reset link." A response that differs — a different HTTP status code, a different error message ("no account found" vs. "check your email"), a redirect to a different page, a different response time, or even a subtly different JSON shape — turns the endpoint into what security researchers call an observable discrepancy. That's cataloged as CWE-203, and testing for it is a standard line item in authenticated penetration tests and in OWASP's web security testing methodology under account enumeration and weak password-reset testing.

Holehe's 120+ modules are, one by one, hand-written exploits of exactly this discrepancy, tuned per site. Each module knows what a "yes, this email has an account" response looks like on that specific platform, and what a "no" looks like, because someone reverse-engineered it once and committed the difference as a Python function. Multiply that by 120 sites and you get, in aggregate, a working map of which major platforms leak account existence through their password-reset or signup flow and which ones have closed the hole.

Run against a single email, holehe fires these checks concurrently via async I/O, so a sweep across all 120+ modules typically finishes in seconds rather than the minutes it would take sequentially. That speed is also why rate-limiting matters so much for the tool's usability — more on that below.

Zoom into what a single module actually looks for, and the pattern repeats across all 120+ with only the specifics changing:

Status code discrepancy. A 200 for a known email versus a 404 or 400 for an unknown one, even if the page content looks identical to a human eyeballing it in a browser.
Body content discrepancy. Different copy in the JSON payload or HTML — "we've sent you a link" versus "no account found with that email" — the single most common leak, because it's the easiest for a frontend team to write without thinking about it.
Redirect target discrepancy. Some flows redirect to a "check your email" page only when the account is real, and silently re-render the form (or show an inline error) when it isn't.
Response-shape and metadata discrepancy. A handful of holehe's modules go further than exists/doesn't-exist — they parse a partially masked recovery phone number or secondary email out of the response body, or detect whether 2FA is enabled, because some platforms include that detail in the reset flow itself to help the legitimate user pick the right recovery method.

None of these require credentials, a session, or bypassing any authentication. They're all observable from a single unauthenticated HTTP request to a public endpoint — which is exactly why the technique scales to 120+ sites checked in seconds, and why it's so cheap for holehe's maintainers to add a new module: find the discrepancy once, write a ten-line async function, done.

What changed versus what came before

Cross-referencing an email address against social platforms isn't new. What's new is that it used to cost something. Commercial people-search and OSINT aggregators like Pipl or Spokeo charge for this, sit behind a web UI, and don't tell you their methodology. Manual OSINT — the kind taught in investigator training — meant visiting each platform's reset page by hand, one at a time, and eyeballing the response.

Holehe collapses that into a free, open-source, scriptable primitive that anyone can inspect, extend, and run offline (well, mostly — see limitations). It sits in a broader 2026 wave of accessible OSINT tooling alongside projects like Sherlock (username correlation across platforms), theHarvester (domain/subdomain/email reconnaissance), and GHunt (deep-dive OSINT specifically on Google accounts). None of these tools broke new cryptographic ground — they made existing techniques cheap, fast, and reproducible, which is exactly the pattern that made holehe climb GitHub's trending page again this week even though the project itself has been around for a few years.

Why developers should actually care

If you maintain any kind of signup, login, or password-reset flow, holehe is effectively a free, continuously community-updated audit of whether your endpoint is on the "leaks account existence" list. That's the part that should get an AppSec team's attention, not the OSINT angle.

Security and compliance. Account enumeration is routinely flagged in penetration test reports and increasingly shows up in bug bounty submissions, because tools like holehe make it trivial to demonstrate. Under data-protection regimes like GDPR, confirming "this specific person has an account here" from an email address alone is itself a small information disclosure — it links a real person's identity to their presence on your platform, which is exactly the kind of inference GDPR's data-minimization principle is meant to limit.

The fix is cheap, which is the annoying part. Closing this hole doesn't require new infrastructure. It requires: identical response bodies and status codes regardless of account existence, constant-time responses (or artificial delay padding) so timing doesn't leak the answer, generic copy ("if an account exists, we've emailed a link") instead of "no account found," and rate limiting on the reset/signup endpoint itself, independent of your general API rate limits. Most of this is a one-sprint fix. The fact that it's still this common across the 120+ services holehe checks suggests it's not a hard problem, it's a forgotten one — reset flows get built once, early, and rarely get a second security pass once the "happy path" works.

It's also a maintainability signal in reverse. Holehe's module list is a rolling record of which platforms fixed their enumeration leak (their module breaks or gets removed) and which haven't (their module keeps working, PR after PR, release after release). If your product's module is still green months after a pentest flagged the same issue, that's a visible, public data point — not just an internal Jira ticket nobody prioritized.

The cost/latency/DX tradeoffs are smaller than they look. The financial cost sits almost entirely on the "didn't fix it" side: enumeration is cheap to exploit at scale (credential-stuffing operations use exactly this kind of check to prune target lists down to emails that are worth attacking), so the downstream cost is fraud and account-takeover risk, not a line item anyone budgets for the leak itself. Fixing it does add a small amount of latency by design — padding a "no account" response to match the timing of a real password-reset email dispatch is a deliberate few hundred milliseconds, not a bug. The main DX cost is on copywriting and support: a generic "if this email exists, we sent a link" message means legitimate users who mistype their email, or who have three accounts and forgot which one, get less help from the UI itself and lean on support more. That's a real tradeoff, not a free fix, and it's worth deciding on purpose rather than by accident.

Lock-in cuts the other way here. Teams that outsource authentication to a managed identity provider — Auth0, Clerk, Firebase Authentication — largely inherit generic, enumeration-resistant reset responses as a platform default, because the vendor has already had this exact conversation with their own security team. That's a real argument for the lock-in tradeoff of managed auth: you give up some control over the login flow, and in exchange you stop having to remember to re-solve a 15-year-old bug every time someone rebuilds the reset page. Teams with hand-rolled auth — still extremely common, especially in older codebases or anything that predates the current wave of auth-as-a-service — are the ones actually exposed, and they're also the ones least likely to have a recent pentest that would have caught it.

Practical use cases

Self-audit. Point holehe at your own team's throwaway test accounts across the services you integrate with, or better, run the same discrepancy-testing logic against your own reset endpoint as part of CI/security regression testing.
Authorized penetration testing and bug bounty work. Enumeration checks are a standard step in scoped, permissioned engagements; holehe automates a step that used to be manual.
Breach and exposure response. Incident responders checking how far an email address's footprint extends across platforms, as part of assessing blast radius after a credential leak.
Digital-footprint audits with consent — journalists, researchers, or individuals auditing their own online presence before a job change, a public role, or a privacy cleanup.

What holehe is not built for, despite how easy it is to point at any email address: running it against someone without their knowledge or a legal basis to do so. The tool's own README limits itself to a single line — "built for educational purposes only" — which is a common OSS disclaimer but not a technical or legal safeguard. There's no consent flow, no scope-limiting, no audit log. The gap between what the tool makes trivially possible and what its disclaimer asks you to voluntarily not do is the real ethical surface area here, and it's worth being honest about that rather than waving it away with the standard GitHub README boilerplate.

Limitations the trending-page hype skips over

The rate-limit arms race is real and it's losing ground. The platforms with the largest user bases and the most to lose from enumeration — think Google, Meta-owned properties — have invested the most in blocking exactly this kind of automated probing, through CAPTCHAs, IP-based rate limits, and increasingly aggressive bot detection. Holehe's own maintainers note that sustained or large-scale use requires IP rotation to keep working, which immediately pushes serious usage toward proxy infrastructure — a step up in cost and complexity that the "just pip install and run" pitch glosses over.

Module freshness is a real bus-factor problem. The repository shows on the order of 434 commits against 13,600+ stars and a large fork count, which is a strikingly small commit history for a project this popular — a sign that active maintenance load sits on a small number of people. When a platform changes its error page copy or its response codes (which happens more often than API versioning would suggest), the corresponding module silently starts returning wrong answers until someone notices and files a fix. There's no automated regression suite continuously verifying all 120+ modules against live endpoints, so accuracy at any given moment is only as good as the last person who happened to check that specific site.

Results quality is uneven across the module list. Some modules key off multiple response signals and are quite reliable; others rely on a single brittle string match against an error message that a platform could change without any warning. The tool reports a binary exists/doesn't-exist, but doesn't expose a confidence score per module, so a user with no visibility into the underlying HTTP responses has no way to tell a rock-solid check from a shaky one.

It doesn't verify — it infers. A "yes" from holehe means "this platform's reset flow behaves as if this email has an account," not confirmed ground truth. False positives happen when platforms change behavior; false negatives happen when platforms close the enumeration hole holehe used to exploit (a genuine security win that just looks, from holehe's side, like a missing result).

The legal ground is greyer than "no CAPTCHA bypass, no login" implies. Holehe never authenticates and never brute-forces a password, so it sidesteps the most obvious unauthorized-access tripwires. But automated, high-volume probing of third-party endpoints you don't own — even unauthenticated ones — sits close enough to territory covered by computer-misuse statutes in multiple jurisdictions (the U.S. Computer Fraud and Abuse Act among them) that security researchers generally treat "no login required" as necessary, not sufficient, for a checked-off legal green light. None of that is legal advice, and the honest answer is that the law here is unsettled and platform-dependent — which is itself a reason to keep usage inside clearly authorized scope rather than treating the tool's own "educational purposes" disclaimer as a substitute for one.

How it stacks up against the rest of the OSINT toolbox

Tool	Input	What it actually checks	Notification risk to target	Maintenance model
holehe	Email address	Account existence across 120+ services via reset/signup endpoint discrepancies	Low — designed not to trigger reset emails	Small core team, community module PRs
Sherlock	Username	Username registration across 400+ sites (URL/profile existence, not auth flow)	Low — checks public profile URLs	Large community, frequent site-list churn
theHarvester	Domain/company name	Emails, subdomains, employee names, IPs from search engines and public sources	None — passive/OSINT-source based	Actively maintained, broader recon scope
GHunt	Google email/account	Deep Google-ecosystem OSINT (Calendar, Maps reviews, YouTube, Photos exposure)	Low, but Google-account-specific and higher legal sensitivity	Smaller team, narrower but deeper scope
Commercial aggregators (Pipl, Spokeo)	Name/email/phone	Cross-referenced public records, social profiles, historical data	Varies, opaque methodology	Paid, closed-source, black-box

Holehe's niche in that table is narrow and specific: it's the only one purpose-built to abuse account-existence discrepancies specifically, rather than scraping public profile pages (Sherlock) or public search-engine indexes (theHarvester). That narrowness is also its strength — it does one mechanism well instead of trying to be a general-purpose OSINT suite.

An independent read

Holehe's real value isn't as an OSINT weapon, even though that's the framing most coverage of tools like this defaults to. Its real value is as a decentralized, continuously updated vulnerability list for one of the oldest and most boring classes of auth bug there is. Every green checkmark in its module list is a live demonstration that a specific, well-known company hasn't closed a gap that's been in security testing checklists for over a decade. That's a more interesting story than "OSINT tool goes viral," and it's one the project's own README doesn't tell, because it's framed entirely around what the tool finds on other people, not what it says about the platforms being checked.

The ethical framing is thinner than the popularity deserves. "Educational purposes only" carries no technical weight, and a tool this fast and this free is going to get used for things well outside a classroom. That doesn't make the project illegitimate — Sherlock and theHarvester carry the same disclaimer and the same dual-use reality, and dual-use security tooling has always required the user, not the software, to supply the authorization. But it does mean the "13K stars, community-loved" framing you'll see elsewhere undersells how easily this particular tool maps onto stalking and doxxing use cases that have nothing to do with security research. Both things are true at once, and a fair deep dive should say so plainly instead of picking one.

Who should actually use this

AppSec and backend teams: worth 20 minutes of your time — run it against your own product's email, confirm whether your reset flow is on the list, and fix it if it is. This is a same-sprint fix, not a roadmap item.

Pentesters and bug bounty hunters with signed scope: a solid, fast addition to the recon phase; treat its results as leads to confirm manually, not as findings to report directly, given the module-freshness caveats above.

OSINT researchers and investigative journalists: useful, but pair it with your organization's legal review before running it against anyone besides yourself or a consenting subject — the tool gives you no guardrails, so you have to bring your own.

General app developers not touching auth: skip it as a tool, but take the underlying lesson — audit your own password-reset endpoint for response-based discrepancies even if nobody's asked you to, because the fix is cheap and the tool proving the bug exists is now one pip install away for anyone curious enough to look.

What's your team's actual policy on password-reset response symmetry — is it something you test for explicitly in CI/pentest scope, or did it only ever get checked the one time a pentester happened to try it?

Sources:

Atlassian Code Context Makes AI Agents 44% More Accurate. Its Fine Print Puts the IP Risk on You.

Daniel Kim — Wed, 19 Aug 2026 03:06:53 +0000

On August 12, Atlassian shipped something with a boring name and an unboring implication: Code Context, a new layer in its Teamwork Graph that indexes your source code — across every repo you connect — and hands it to Rovo, Jira, and any coding agent that asks nicely. Atlassian's internal benchmark claims agents get 44% more accurate and burn 48% fewer tokens once they have it. Those are good numbers, and Atlassian's own documentation undercuts the pitch in a way most launch posts never do: if you use this feature through its command-line interface with Claude Code, Cursor, or Codex, your source code leaves Atlassian's infrastructure and lands inside a third party's, "governed by their terms" — and you, not Atlassian, are on the hook for deciding whether that's acceptable.

That sentence, buried in a support article rather than the press release, is the actual story here. Everyone selling AI coding tools in 2026 is selling "context." Almost none of them are this candid about where that context goes once it leaves the building. This piece digs into what Code Context does, how the indexing pipeline actually works, what Atlassian's own fine print says about it, and how it stacks up against Sourcegraph, GitHub Copilot, and Cursor's built-in retrieval — three products already fighting over the exact same "context is the real differentiator" argument.

What happened

Code Context is a rename-and-expand of a feature Atlassian previously called "Code Intelligence." It's now generally available in open beta, folded into the Teamwork Graph — the data-and-permissions layer Atlassian unveiled at its Team '26 conference in May to unify Jira issues, Confluence pages, Loom recordings, and roughly 100 connected third-party apps into one queryable graph. Code Context adds source code to that graph as a first-class citizen, connected via Bitbucket or GitHub.

The launch was accompanied by a quote from Mark Walz, CTO of point-of-sale vendor SpotOn, a real enterprise customer rather than a hypothetical persona: "When an agent starts in the wrong place, everything slows down and costs more. Developers end up explaining where to look, why the code works the way it does, and what else it touches. Code Context puts all of that in front of the agent from the start, so it can focus on getting the work done." Sanchan Saxena, Atlassian's SVP and head of product for the Teamwork Collection, framed it as a two-part bet: "Frontier intelligence gives teams speed. Context points that speed in the right, most impactful direction."

That framing matters because it's a direct shot at the current AI-coding-tools arms race, where every vendor claims access to the same handful of frontier models. If the models converge, Atlassian's argument goes, the fight moves to who can hand those models the right sixty lines of code out of six million.

What it actually does

Strip the announcement language and Code Context is a retrieval system for source code, wired into three surfaces:

Rovo Chat — ask a natural-language question ("where is auth token refresh handled?") and get an answer grounded in indexed code plus related Jira tickets, Confluence pages, and Loom clips, not just a keyword match.
Jira and the wider Atlassian ecosystem — code context surfaces inline where teams already work, rather than requiring a context switch to a separate search tool.
The Teamwork Graph CLI — a command-line interface that lets any coding agent, including third-party ones, query the graph before it plans or edits. Atlassian explicitly names Cursor, Claude Code, and Codex as agents that can use it this way.

Under the hood, Atlassian's own documentation describes two complementary retrieval modes: lexical search (traditional keyword/string matching, for when you know the exact function name) and semantic search (embedding-based retrieval for when you know the concept but not the identifier). In Rovo Chat and the CLI, the underlying agent picks a mode automatically, sometimes blending both.

How the indexing pipeline works

This is the part most coverage skipped, and it's worth walking through because it explains both the accuracy claim and the risk section below.

An org admin opts in per site under Atlassian Administration → Rovo → Code context. It is off by default — nothing gets indexed until someone with admin rights turns it on, and once on, individual contributors cannot exclude their own repos from indexing (Atlassian's docs note this deliberately mirrors how Bitbucket's existing lexical search already behaves).
Atlassian connects to repositories via the GitHub-for-Jira connector or the native Bitbucket integration.
For GitHub repositories specifically, the code is mirrored into Atlassian's own infrastructure before indexing. Bitbucket repositories, by contrast, are indexed directly, without a separate mirrored copy — because Bitbucket is already Atlassian's own system.
Files are chunked and converted into vector embeddings using what Atlassian describes as a code-optimized embedding model. Embeddings are stored as non-human-readable numerical representations, alongside the raw code chunks, in what the docs call "a secure, isolated environment."
Pushes and branch updates trigger incremental re-indexing, so the graph doesn't go stale immediately — though there's a lag (more on that below).
Disabling code context stops indexing immediately and deletes all stored embeddings, chunks, and indices.

Permissions are enforced at query time against the live repository ACLs in GitHub or Bitbucket, not against a permissions snapshot taken at indexing time — Atlassian's stated design goal is that an agent or user can never see through Code Context anything they couldn't already see by opening the repo directly.

That GitHub-mirroring detail is the one to sit with. It means opting into Code Context for a GitHub org doesn't just let Atlassian query your code — it creates a second, Atlassian-hosted copy of it. For most teams that's an unremarkable SaaS pattern (Cursor and Sourcegraph both do versions of the same thing), but it's a meaningfully different security posture than "Atlassian reads your code over an API call," and it's not the framing used anywhere in the launch materials.

What changed vs. before

Before Code Context, an agent working inside a single repo — via Rovo Dev, Claude Code, Cursor, or anything else — was limited to whatever was checked out locally or explicitly pasted into a prompt. Atlassian's blog post walks through a side-by-side example: two agents are given the same bug report. Both correctly guess the likely cause. The agent without Code Context stops at a plausible hypothesis. The one with Code Context finds a related repository not present on the developer's machine, confirms the actual root cause lives there instead, and — critically — cites a prior architectural decision (surfaced from Confluence or Jira, not the code itself) explaining why the fix belongs in that other service rather than the one open in the editor.

That's the real product claim: not "better autocomplete," but turning a plausible guess into a verified diagnosis by pulling in cross-repo dependencies and the organizational reasoning that produced them. It's a meaningfully different pitch from a pure code-search tool, because half the value is coming from Jira and Confluence, not the code index itself.

Versus the previous "Code Intelligence" branding, the practical change is scope and distribution: it now spans large-scale, multi-repo codebases rather than a single connected repo, and it's exposed through the CLI to agents Atlassian doesn't build, not just to Rovo's own agents.

Why developers should care

Token cost is a real line item now. With agentic coding tools billing by token consumption — GitHub replaced Premium Request Units with usage-based AI Credits on June 1, 2026, and Cursor's plans scale similarly — a credible 48% reduction in tokens-per-task, if it holds up outside Atlassian's own benchmark, is a budget line, not a vibe. Worth treating with the usual skepticism reserved for vendor-run internal benchmarks: nobody has published an independent replication yet.

It's a genuine bring-your-own-agent play, which is unusual for Atlassian. Most platform vendors want you inside their own agent (Rovo Dev, in this case). Exposing the graph to Cursor, Claude Code, and Codex via a CLI is a bet that context, not the agent runtime, is the moat — and it's the more defensible bet if you believe frontier models really have converged.

The IP exposure disclosure is unusually direct, and worth reading in full. From Atlassian's own support docs: "The Teamwork Graph CLI augments Atlassian coding agents (via the Rovo CLI) or third-party products (like Claude Code or Codex). If you use code context via the Teamwork Graph CLI with a third-party agent, your source code will be sent to those products and governed by their terms, which may expose proprietary code and IP. You're responsible for assessing the third-party providers['] security and suitability, for managing all their associated costs, API capacity, and agent actions." That's Atlassian explicitly declining to be the liability backstop for what happens to your code once a third-party agent has it. Reasonable and honest — the CLI is a pipe, not a walled garden — but it means the compliance conversation about Code Context can't stop at Atlassian's own SOC 2 posture. It has to extend to every agent your developers point the CLI at.

Lock-in runs through the graph, not the code index. The code-search half of this is replicable elsewhere. What isn't easily replicable is the Jira-ticket-plus-Confluence-doc-plus-Loom-clip context that makes Atlassian's pitch different from a pure code index — and that only exists if your team's actual work already lives in Atlassian's tools. If it doesn't, Code Context is a mediocre code search product wearing a much bigger product's branding.

Compliance gaps are specific and currently disqualifying for some teams. Code context is explicitly not available to HIPAA-enabled sites, and it currently supports only Bitbucket Cloud and GitHub Cloud — no GitLab, no self-hosted Bitbucket or GitHub Enterprise Server, at least not yet.

Practical use cases

Onboarding. New hire asks Rovo how order fulfillment actually works and gets an answer traced across the services that touch it, instead of pinging three people on Slack.
Cross-repo debugging. Support ticket references a symptom in service A; the actual bug lives in service B's shared library. Semantic search plus the Jira/Confluence layer surfaces that connection instead of leaving it to institutional memory.
Impact analysis before a change. A tech lead asks which services depend on an API before touching it — arguably more valuable than code generation itself, since it prevents work rather than accelerating it.
Agent grounding via the CLI. A team already standardized on Claude Code or Cursor keeps its editor but pipes Teamwork Graph context in before the agent plans a change, rather than switching tools to get better context.
Rovo Chat as a search replacement. For teams that already live in Jira, this may simply replace ad hoc grepping and Slack archaeology with a single chat interface — the lowest-friction use case and the easiest to evaluate in an afternoon.

What the marketing leaves out

Beyond the IP-exposure disclosure above, Atlassian's own support documentation lists limitations that don't appear anywhere in the launch blog post or press release:

Semantic search is not exact-match. Results are ranked by conceptual similarity; if you need a literal string or function name, you're expected to fall back to lexical search.
Freshness lags reality. Recently pushed code may not appear immediately while re-indexing catches up, and if a connected GitHub or Bitbucket instance has an outage, indexing pauses until the connection is restored.
AI answers are probabilistic, not guaranteed — Atlassian's own docs explicitly warn users to verify AI-generated answers before acting on them "in critical situations like incident response or security decisions." That's a reasonable disclaimer, but it's a direct hedge against the 44%-more-accurate headline number sitting one paragraph away in the same product's marketing.
No GitLab support, no self-hosted Git support, which quietly excludes a large share of regulated and infrastructure-heavy engineering orgs.
Not available to HIPAA-enabled sites at all — not throttled, not gated behind a higher tier, simply unavailable.
The rename from "Code Intelligence" to "Code Context" isn't disclosed as a rename anywhere except a single parenthetical in the support documentation. If you evaluated the earlier feature and passed, that context is easy to miss on a second look.

None of these are disqualifying on their own. Collectively, they're the difference between "context engine for your entire codebase" (the headline) and "beta-quality semantic search over two cloud SCMs, with a real IP-liability handoff the moment you point it at a third-party agent" (the more accurate one-line description).

Competitive comparison

The market Code Context is entering already has three players making a version of the same "context, not model quality, is what matters now" argument, and they've converged on genuinely different architectures for it:

Cursor builds its own local index of the checked-out repo and layers automatic plus manual (@codebase) retrieval on top, inside a VS Code fork it fully controls. It's fast and requires zero setup, but it's editor-scoped — cross-repo, org-wide context depends on what's checked out on that specific machine, and there's no shared index across a team's many repos.
Sourcegraph's Cody built its reputation on exactly the problem Code Context is now targeting: a code graph spanning "100 to 1M repositories" across GitHub, GitLab, Bitbucket, Gerrit, and Perforce, with governance features (allow/deny lists, SOC 2 Type II, ISO 27001, zero data retention) aimed squarely at security teams. The catch, and it's a significant one for anyone comparing the two products today: Sourcegraph discontinued Cody's individual Free and Pro tiers in July 2025, pointing solo users toward its newer agentic tool, Amp, instead. Cody Enterprise is still fully supported and remains the strongest option for teams on GitLab, Perforce, or self-hosted Git — none of which Code Context currently touches at all.
GitHub Copilot leans on @workspace and open-file context rather than a persistent cross-repo index. It's the lowest-friction option for teams already fully inside GitHub and Microsoft's ecosystem, with the deepest PR and code-review integration, but multiple independent comparisons published this year describe its large-codebase context as "good but not great" next to a fully indexed graph.

Code Context's actual differentiator against all three isn't the code index — Sourcegraph's is more mature and covers more SCMs today. It's that Code Context is the only one of the four bundling code with an org's Jira tickets, Confluence architecture docs, and Loom explainer clips in the same retrieval layer, natively, because Atlassian already owns all three products. Whether that's a decisive advantage depends entirely on whether your organization's actual "why we built it this way" record lives in Confluence and Jira, or scattered across Notion, Google Docs, and people's heads.

An independent read

Financial coverage of the launch has been notably unenthusiastic, which is a useful counterweight to the CTO quote in the press release. One analysis published two days after launch called Code Context "supportive rather than transformative for the near term" for Atlassian's business, arguing it reinforces the company's AI narrative without changing the underlying investment thesis — which now hinges on Atlassian's guided ~13% year-over-year revenue growth for fiscal 2027 converting into actual margin expansion, rather than just funding more R&D spend on features like this one. That's a fair framing to bring into a technical evaluation, too: this is a beta-stage feature from a company with a strong incentive to make "AI-native" claims land with investors, not just with the developers actually running code context queries at 2am chasing a cross-service bug. Weigh the 44%/48% numbers accordingly — they're internal, unaudited, and haven't been independently reproduced.

Who should try it, wait, or skip it

Try it now if you're already a Jira and Confluence shop on GitHub Cloud or Bitbucket Cloud, your team is experimenting with Claude Code, Cursor, or Codex, and you want to test whether piping Teamwork Graph context into those tools measurably changes output quality. The opt-in is admin-gated and reversible — indexing stops and deletes on disable — so the downside of a trial is bounded.

Wait if you're on GitHub Enterprise Server, self-hosted GitLab, or Bitbucket Server, since none of those are supported yet, or if you're a HIPAA-covered org, where the feature is simply not available. Also wait if your organization's real institutional knowledge lives outside Atlassian's product suite — you'll get a decent code search tool and none of the cross-signal advantage that's the actual pitch.

Skip it if your security team won't sign off on routing source code through a third-party agent's own terms of service the moment a developer runs the CLI against Claude Code or Cursor — that's not a hypothetical edge case, it's the documented default behavior of the feature as shipped. And if your codebase already lives in a mature Sourcegraph Cody Enterprise deployment spanning GitLab and Perforce, there's little reason to duplicate that investment with a narrower, newer beta.

The most interesting thing about this launch isn't the 44% number. It's that Atlassian shipped an unusually blunt admission, in its own documentation, that giving an AI agent your entire codebase's context also means deciding exactly which company's terms of service that code is now subject to — and that decision belongs to you, not the platform selling you the pipe.

Discussion: if you've piped an internal code index into a third-party coding agent via CLI or MCP, how did your security team actually scope the risk — per-repo allowlists, a separate low-sensitivity index, human review of every agent-initiated query, something else? What did the decision process for "yes, but only these repos" actually look like at your org?

Sources:

A Solo Developer's 29K-Star Repo Just Validated Anthropic's Open Skills Bet

Daniel Kim — Wed, 19 Aug 2026 00:18:31 +0000

Nine months ago, Anthropic made a decision that looked, on the surface, like giving away a feature it could have kept proprietary. Agent Skills — a lightweight, folder-based format for packaging domain expertise so an AI agent can load it on demand — had launched as a Claude-only capability in October 2025. Two months later, Anthropic published it as an open standard instead. Any platform could implement it. Any developer could write skills once and have them run in Claude Code, GitHub Copilot, Cursor, OpenAI's Codex CLI, or two dozen other agentic tools, without rewriting a line.

This week, the first real evidence that bet paid off showed up on GitHub's trending page. mukul975/Anthropic-Cybersecurity-Skills — a solo-maintained repository of 817 structured cybersecurity workflows built entirely on top of the open Agent Skills format — crossed 29,000 stars and 3,500 forks, gaining hundreds of stars in a single day. It's not built by Anthropic, a security vendor, or a well-funded startup. It's maintained by one developer, Mahipal Jangra, publishing under the handle @mukul975, with help from eight listed contributors. And it's currently one of the largest structured knowledge bases for AI agents on GitHub, in any domain.

That's the story worth unpacking: not "here's a cool repo," but what it means that the biggest proof-of-concept for cross-platform agent interoperability is a community project a corporate security team would never have signed off on funding.

What the repo actually contains

Strip away the framing and Anthropic-Cybersecurity-Skills is exactly what it says: 817 Markdown-based "skills," each a self-contained folder that teaches an AI agent how to execute one cybersecurity procedure the way a working analyst would — not a Stack Overflow answer, not a tool's --help text, but the actual decision tree.

A skill directory looks like this:

skills/performing-memory-forensics-with-volatility3/
├── SKILL.md              ← YAML frontmatter + Markdown body
├── references/
│   ├── standards.md      ← framework mappings
│   └── workflows.md      ← deep technical procedure reference
├── scripts/
│   └── process.py        ← working helper scripts
└── assets/
    └── template.md        ← checklists and report templates

The SKILL.md frontmatter for that example:

---
name: performing-memory-forensics-with-volatility3
description: ">-"
  Analyze memory dumps to extract running processes, network connections,
  injected code, and malware artifacts using the Volatility3 framework.
domain: cybersecurity
subdomain: digital-forensics
tags: [forensics, memory-analysis, volatility3, incident-response, dfir]
atlas_techniques: [AML.T0047]
d3fend_techniques: [D3-MA, D3-PSMD]
nist_ai_rmf: [MEASURE-2.6]
nist_csf: [DE.CM-01, RS.AN-03]
version: "1.2"
author: mukul975
license: Apache-2.0
---

The Markdown body underneath follows a fixed four-section shape — When to Use, Prerequisites, Workflow, Verification — which is the actual point. It's not a wiki page an agent has to interpret loosely; it's a structured runbook with explicit trigger conditions and a way to check the output was correct.

The 817 skills span 29 security domains, weighted toward what security teams actually spend time on: cloud security (66 skills covering AWS, Azure, and GCP hardening and forensics), threat hunting (58), threat intelligence (52), network security (43), web application security (42), digital forensics (41), and malware analysis (39), down to smaller categories like hardware/firmware security (4) and deception technology (6).

The mechanism: progressive disclosure, and why it matters at 817 skills

The reason a repo this size doesn't blow out an agent's context window is the specific thing the Agent Skills format was designed to solve. Per the README, each skill costs roughly 30 tokens to scan — name, description, tags in the frontmatter — and 500 to 2,000 tokens to fully load once it's selected. An agent facing a prompt like "analyze this memory dump for signs of credential theft" scans all 817 frontmatters in a single pass, narrows to a handful of candidates by keyword and description match, loads the two or three that actually apply, executes the Workflow section, and checks its own work against Verification. The other 800-plus skills never touch the context window at all.

This is the practical difference between Agent Skills and simply dumping documentation into a system prompt or a retrieval index: the frontmatter/body split is a built-in two-stage retrieval mechanism, cheap enough that loading all 817 headers costs less than a single paragraph of prose.

It's also worth being precise about what this is not. Agent Skills is not Model Context Protocol (MCP). MCP is the connector layer — it gives an agent access to a tool or a data source (a database, a ticketing system, a shell). Agent Skills is the procedural-knowledge layer — it tells the agent when and how to use what it already has access to. The two are explicitly designed to compose: several of the repo's AI Security skills reference MCP server compromise and tool-invocation abuse as their own attack surface, which is a small, telling sign of how entangled the two standards are becoming in practice.

What changed since Agent Skills went cross-platform

The timeline matters here. Anthropic shipped Agent Skills as a Claude-specific feature on October 16, 2025. On December 18, 2025, it published the specification at agentskills.io as an open, vendor-neutral standard, with partner-built skills from Canva, Stripe, Notion, and Zapier available at launch. According to reporting at the time, Microsoft integrated it into VS Code and OpenAI added it to ChatGPT and Codex CLI within 48 hours of the announcement. Atlassian, Figma, and GitHub followed. The current count of compatible platforms sits above 26, spanning code assistants (Claude Code, GitHub Copilot, Cursor, Windsurf, Cline, Continue, Roo Code, Amazon Q Developer, Tabnine, Sourcegraph Cody, JetBrains AI), CLI agents (Codex CLI, Gemini CLI), autonomous agents (Devin, Replit Agent, SWE-agent, OpenHands), and frameworks (LangChain, CrewAI, AutoGen, Semantic Kernel, Haystack, the Vercel AI SDK).

What Anthropic-Cybersecurity-Skills demonstrates, eight months on, is that the standard's value wasn't just "install a Canva skill in ChatGPT." It's that a single motivated domain expert can produce a knowledge base large and structured enough to rival what a well-funded security vendor might ship as a product — and have it work identically across every tool on that list, with zero platform-specific engineering. That's a genuinely different distribution model than the one that preceded it, where a security-focused prompt library was, at best, a set of copy-pasteable strings tied to whichever chat interface you happened to be using.

Framing it against the field: VoltAgent's awesome-agent-skills index — a curated list the repo itself is featured in — reportedly tracks over 1,000 skills across all domains and publishers combined. If that figure is roughly accurate, one solo maintainer's cybersecurity library alone accounts for a meaningful fraction of the entire public Agent Skills catalog, in a single vertical, less than a year after the standard opened.

Six frameworks, one mapping problem solved (mostly)

The part of this repo that reads as genuinely load-bearing engineering, rather than content aggregation, is the framework mapping. Every skill's frontmatter can carry identifiers from up to six industry frameworks, applied selectively based on what the skill actually covers:

Framework	Version	What it covers	Skills mapped
MITRE ATT&CK	v19.1	Adversary behaviors and TTPs, 15 tactics	805
NIST CSF 2.0	2.0	Organizational security posture, 6 functions	804
MITRE D3FEND	v1.4.0	270 defensive countermeasures	139
NIST AI RMF	1.0	AI risk governance	97
MITRE F3 (Fight Fraud Framework)	v1.1	Cyber-enabled financial fraud	94
MITRE ATLAS	2026.07	AI/ML adversarial threats	93

The MITRE ATT&CK mapping is validated programmatically against the official mitreattack-python library, and the README claims zero revoked or deprecated technique IDs across 290 distinct techniques and sub-techniques — a level of rigor that's unusual for a community repo and that most enterprise security teams don't apply to their own internal runbooks. The most recent addition is MITRE F3, released April 9, 2026, by MITRE's Center for Threat-Informed Defense with backing from JPMorganChase, Citigroup, Lloyds Banking Group, and Standard Chartered — it fills a real gap ATT&CK doesn't cover (what happens after a fraud actor gets in: account takeover monetization, mule layering, synthetic-identity positioning), and its inclusion here, four months after F3 shipped, is a fast turnaround for a volunteer project.

The NIST AI RMF mapping has a specific, concrete payoff worth calling out: Colorado's AI Act, effective February 2026, provides a legal safe harbor for organizations that can demonstrate compliance with the NIST AI RMF. A skill library that ships pre-mapped AI RMF references isn't just a nice-to-have taxonomy — it's a starting point for an actual compliance artifact, assuming a legal team is willing to treat community-sourced mappings as a foundation rather than a finished product (more on that caveat below).

Why this should matter to developers who aren't in security

Even outside cybersecurity, the pattern here is the more interesting story than the repo itself. Three things compound:

Portability kills the rewrite tax. Before an open skills standard, building agent-usable domain knowledge meant picking a target platform and writing for it — a LangChain tool spec looks nothing like a custom GPT's instructions, which looks nothing like a Claude Project's knowledge files. A skill written against the agentskills.io spec runs, unmodified, in Claude Code and in Cursor and in Codex CLI. For a maintainer, that's the difference between building for one customer base and building for the entire agentic tooling market at once — which is very likely why one person was able to produce 817 of these and reach 29,000 stars instead of a few hundred.

Token economics change what's viable to bundle. The 30-token scan cost means an agent can carry knowledge of 817 procedures — or ten times that — without meaningfully taxing every request with unrelated context. That's a different design space than RAG-over-a-vector-store (retrieval quality and latency-dependent) or a giant system prompt (doesn't scale past a few dozen entries before context and cost balloon). Teams building internal agents for any structured-procedure domain — legal review checklists, SRE runbooks, compliance audits, onboarding workflows — have a template here for how to ship that knowledge cheaply.

Crowdsourced content is now a credible substitute for vendor content, at least in scale. Stripe, Notion, Canva, and Zapier shipped official skills at the standard's launch. A solo developer's community project now outweighs any single one of those in raw skill count, at least within cybersecurity. That's a genuine shift in where "authoritative" agent knowledge can plausibly come from — and it cuts both ways, which is the subject of the next section.

What the README doesn't fully reckon with

A few things are worth separating from the repo's own framing before anyone points an agent at this in production:

It ships offensive, dual-use content by design. The README is upfront about this — red-team C2 tooling, phishing simulation, exploitation techniques are explicitly included, with a warning to use them only against systems you own or have written authorization to test. That's the right disclaimer to have, but a disclaimer isn't an access control. Once a skill for, say, NTLM relay attacks or device-code phishing is npx skills add-installed into an agent, nothing in the Agent Skills format itself distinguishes "an authorized pentester's agent" from any other agent that happens to load the same package. The standard, as documented, doesn't appear to define a provenance or signing mechanism — installing a skill is a filesystem operation, not a verified supply chain.

The trust model is one person plus a 48-hour PR review promise. The README states every pull request is reviewed for technical accuracy and standard compliance within 48 hours — a self-reported process, not an independently audited one, run by a single maintainer across 817 technical procedures spanning cloud security, memory forensics, cryptography, and OT/ICS. That's an enormous surface for one reviewer to hold accurately, and the project's own "featured in" section — being cited by curated lists and a skills marketplace — doesn't substitute for a security audit of the workflows themselves. Nothing here suggests bad-faith content; it's simply an open question whether crowdsourced review catches subtle procedural errors in, say, an OT/ICS Modbus workflow the way a domain specialist team would.

The README also isn't purely the technical artifact it presents itself as. Mixed into the documentation are calls to action for an unrelated third-party product — a "Casky.ai" agent playground with waitlist sign-up, UTM-tagged links, and a token-reward incentive for completing a linked academic survey. None of that undermines the technical work, but it's a departure from how a pure open-source reference project usually reads, and worth noticing before treating every claim in the README with equal weight.

"26+ platforms" means format compatibility, not tested behavior. Any tool that implements the folder-plus-YAML-frontmatter convention can technically load these skills. Whether a given platform's agent reliably follows a 2,000-token Workflow section the way Claude Code does is untested and unclaimed by the README itself.

Competitive and ecosystem context

The Agent Skills standard's closest conceptual competitor is arguably not a rival open format but MCP — both emerged from Anthropic, both are now multi-vendor, and both get bundled together in most serious agent deployments rather than treated as either/or. The more direct comparison for this specific repo is the pre-standard status quo: security "cheat sheet" repos, wordlist and payload collections, and tool-specific prompt libraries that have existed for years but were never designed for an agent to select and execute autonomously. Anthropic-Cybersecurity-Skills is closer in spirit to a structured expert-system knowledge base — the kind that was expensive, bespoke, and mostly confined to defense contractors and threat-intel vendors a decade ago — repackaged into a format a $0 GitHub clone and any of two dozen agent tools can consume immediately.

The independent read

The genuinely notable thing here isn't the repo's size — GitHub has plenty of large lists. It's that the size and structure were achievable by one person specifically because the underlying format removed the platform-lock-in tax that used to make this kind of investment only make sense for a company with a distribution channel already built. Anthropic didn't just open a spec; it changed the economics of who can profitably build agent-facing domain knowledge, and the ROI showed up fastest in a domain — cybersecurity — that already had well-documented, framework-driven procedures ready to be reformatted rather than invented from scratch. That's a repeatable playbook: any field with existing structured methodology (clinical protocols, financial audit procedures, engineering runbooks) is a candidate for the same move, and the barrier to entry is now "one motivated domain expert with a weekend," not "a funded team and a distribution deal."

The unresolved part is governance. An open standard with no central content review is exactly the kind of system that scales fast and then has a bad week — a subtly wrong forensics procedure, a compliance mapping that's stale against a framework revision, an exploitation technique with an unclear authorization boundary, surfacing in production because an agent picked it up automatically. Nothing about this specific repo has shown that failure mode yet. But 817 skills reviewed by one person in 48-hour windows is a bet that hasn't been stress-tested at scale, and the standard itself doesn't yet supply the tooling — signing, provenance, independent audit trails — that would catch it if it happens.

Who should actually use this

Security teams already running agent-assisted SOC, DFIR, or pentest workflows in sandboxed or explicitly authorized environments have a legitimate reason to pilot this now — the framework mapping alone (particularly ATT&CK and NIST CSF) saves real time over hand-rolling agent prompts from scratch, and the progressive-disclosure structure means adding it costs almost nothing in context budget even if an agent only ends up using a handful of the 817 skills. Compliance and GRC teams eyeing the NIST AI RMF mapping for something like the Colorado AI Act safe harbor should treat it as a first draft, not a finished compliance artifact, and get it reviewed by counsel and an internal security architect before relying on it. Teams building agents for regulated, high-consequence domains outside security — healthcare, finance, critical infrastructure — should watch this as a proof of concept for the pattern, not necessarily adopt this specific repo. And anyone not currently building or deploying AI agents that touch security workflows can safely ignore it entirely; there's nothing here that changes how you'd use Claude, Copilot, or Cursor for ordinary software work.

What would actually change the calculus on trust here — a MITRE-endorsed review process, a signed-skill mechanism baked into the agentskills.io spec, a corporate sponsor taking over maintenance — none of that exists yet. Whether the ecosystem builds it before or after the first bad incident is the open question worth watching.

Discussion: If Agent Skills' progressive-disclosure model is enough to let an agent index 817+ procedural skills for a few tokens of overhead, what's actually stopping teams from shipping ten times that many, across every internal domain — is it a tooling gap, a governance gap, or just that most organizations haven't inventoried their own tribal knowledge into a structured-enough form to convert yet?

Sources:

Temporal, Inngest, Trigger.dev, and Restate Are Not Actually Competing for the Same Job

Daniel Kim — Tue, 18 Aug 2026 12:19:03 +0000

Every AI agent demo works the same way: call the model, call a tool, maybe call the model again, print the answer. It runs in a few seconds, on your laptop, and if it crashes you just re-run the script. Then someone puts it in production, where a single agent turn might involve four sequential LLM calls, two external API calls with unpredictable latency, a human approval step that takes six hours, and a deploy that happens to land mid-run. The process restarts. All of that state — which step you were on, what the model already said, which tool calls already executed — is gone, and if any of those tool calls had side effects (a charge, an email, a ticket created), re-running the whole thing from the top isn't just wasteful, it's wrong.

This is the problem durable execution engines exist to solve, and in 2026 it has quietly become one of the more consequential infrastructure decisions a team building agentic systems will make. Not because the category is new — Temporal has been production infrastructure at companies like Netflix, Snap, and Stripe for years, mostly for payment sagas and order-fulfillment pipelines that had nothing to do with LLMs — but because agent workloads have the exact shape that durable execution was built for: long-running, failure-prone, step-based, and expensive to redo. The category has responded by growing three more entrants with meaningfully different bets on how much of Temporal's model actually needs to survive the transition: Inngest, Trigger.dev, and Restate. This piece is about what each one actually is, what changed to make this a live decision now, and which one fits which team.

The problem, stated precisely

"Durable execution" means a workflow's state — its position in the code, its local variables, the results of steps it already completed — is persisted after every step, so that if the process running it dies, a new process can resume exactly where the old one left off, without re-executing completed steps. The classic hard case is a sleep(6 hours) in the middle of a function: you cannot keep a process alive for six hours waiting on a human, and you cannot lose the fact that three steps already ran successfully.

For AI agents specifically, the failure modes that make this non-optional are:

Multi-step tool use with side effects. If step 3 of an agent run already sent a Slack message or charged a card, a naive retry-the-whole-function approach double-executes it. Durable execution engines checkpoint each step's result so retries only re-run what actually failed.
Long waits that aren't sleeps. Human-in-the-loop approval, waiting on an async webhook from a third-party API, waiting for a batch LLM job — these can take minutes to days. A durable engine parks the workflow without holding a server process or a database connection open.
Non-determinism from the LLM itself. A model's response is not reproducible on replay the way a pure function is, which is exactly why these engines checkpoint the result of a step rather than relying on being able to re-derive it.
Fan-out orchestration. Multi-agent patterns — a planner spawning worker agents, an agent calling sub-agents in parallel and joining on all of them — need primitives for concurrency, not just linear retries.

You can build a crude version of this yourself with a Postgres table tracking job status and a cron-based retry loop. Plenty of teams do, right up until the state machine for "what counts as done, what counts as retryable, what counts as a duplicate" gets complicated enough that they're reinventing a worse version of one of these four systems.

What changed

Three things converged to turn this into an active decision point rather than a niche infrastructure choice reserved for payments teams.

First, agent frameworks themselves stopped assuming a single request-response cycle. LangGraph, CrewAI-style multi-agent orchestration, and increasingly the coding-agent products that developers use daily all model work as long-running, resumable graphs — which is durable execution's native shape, even when the framework doesn't call it that.

Second, the JavaScript/TypeScript ecosystem got its own durable execution options for the first time. Temporal's SDKs exist for TypeScript, but Temporal's operational model — you run a Temporal Server cluster, or pay for Temporal Cloud, and you write workflow code under strict determinism constraints (no direct Date.now(), no direct random, no arbitrary I/O in workflow code) — was a heavy lift for a team that just wants a background job to survive a redeploy. Inngest and Trigger.dev were built specifically to remove that operational tax for teams already living in Vercel/Next.js-style deploys.

Third, a genuinely different architecture showed up. Restate, built by several ex-Kafka Streams and Flink engineers, doesn't route work through a central workflow engine the way Temporal does — it embeds a lightweight proxy in front of your existing services and journals each interaction so failures replay to only the exact effect that hadn't yet been durably confirmed. It's newer (Restate crossed roughly 4,300 GitHub stars at the time of writing, versus Temporal's ~22,400) but it's the one architecture in this group that treats "state across a whole system of services," not just "one workflow function," as the unit of durability.

What the code actually looks like

Reading past the marketing copy, the four systems land in two families. Temporal and Restate ask you to make an explicit distinction between orchestration code and side-effecting code — Temporal splits it into separate Workflow and Activity functions; Restate wraps side effects in ctx.run() calls inside a single handler. Inngest and Trigger.dev collapse that into one function body where a step.run("call-llm", async () => {...}) call marks the durable boundary inline, which reads closer to plain async/await than to a formal orchestration DSL.

That distinction matters more than it looks for agent code specifically. An agent loop that calls a model, inspects the response, decides whether to call a tool, and loops again is naturally a single function with branching logic — which is awkward to express as Temporal's separated Workflow/Activity pair (you end up calling back into Activities from inside a loop that itself has to stay deterministic) but maps cleanly onto Inngest or Trigger.dev's inline step.* style, and onto Restate's ctx.run() style too, since Restate doesn't impose Temporal's strict workflow-code determinism rule — it journals the actual invocation and its result rather than requiring the surrounding code to be replay-safe. That's arguably Restate's sharpest technical differentiator versus Temporal: you get durability without rewriting your control flow into two cooperating function types.

How each is actually built

Temporal is a client-server system. A Temporal Server (or Temporal Cloud) tracks workflow execution history as an append-only event log; your Workflow code, running in a separate worker process, replays that history to reconstruct state after any crash — which is why workflow code must be deterministic and all actual I/O has to happen in separately-defined "Activities." This determinism constraint is Temporal's biggest asset and its biggest onboarding cost: it's what gives you exactly-once-semantics-by-construction, and it's also why simply calling fetch() inside a workflow function is a bug, not a shortcut. Temporal Server itself is MIT-licensed and free to self-host; Temporal Cloud is the metered managed option.

Inngest is event-driven at its core: you write functions that trigger on events (a webhook, a cron, an internal inngest.send()), and inside the function you wrap durable units of work in step.run() calls, which Inngest's SDK and backend memoize so a re-invocation skips completed steps and resumes from the next one. There's no separate workflow/activity split to reason about — ordinary code with step.* calls sprinkled in. Its licensing is worth being precise about: Inngest's server and CLI ship under the Server Side Public License with a delayed conversion to Apache 2.0 (a "fair source"-style model), while its SDKs are Apache 2.0 outright — so you can inspect and eventually reuse the server code, but it's not a standard permissive open-source project you can freely fork into a competing hosted service today.

Trigger.dev looks similar to Inngest from the code you write — TypeScript tasks, durable steps, a dashboard for observability — but it's fully Apache 2.0 licensed and explicitly built to be self-hosted with no feature gate between the free self-hosted version and the hosted one. It's also the most narrowly TypeScript/Node-focused of the four; if your stack is polyglot, this is the one option here without first-class support outside the JS ecosystem.

Restate ships as a single self-contained binary (or Docker image) with an embedded RocksDB-backed journal — no separate database to provision. SDKs exist for TypeScript, Java/Kotlin, Python, Go, and Rust. Instead of a workflow/activity split, Restate gives you durable functions and "Virtual Objects" (stateful, single-threaded-per-key actors), which is a more natural fit for per-session AI agent state — one Virtual Object per conversation, say — than trying to model a chat session as a single long workflow execution.

Maturity and community signals

Stars are a weak proxy for production-readiness, but paired with commit and issue activity they at least indicate how much real usage is generating bug reports. Temporal's repository sits around 22.4k stars with the deepest history of the four, having grown out of a fork of Uber's internally-built Cadence system — it is, by a wide margin, the project with the longest track record of running at large scale. Trigger.dev, at roughly 16.1k stars, has grown fast on the strength of its open self-hosting story. Inngest, at roughly 5.7k stars with 335 forks, is smaller by this measure despite significant commercial adoption, which is at least partly explained by its hosted-first, not-fully-open-source model — teams evaluating it are more often signing up for the cloud product than starring or forking the repo. Restate, at roughly 4.3k stars across about 4,100 commits with over 300 open issues and 80-plus open pull requests at the time of writing, shows an actively developed but genuinely young project — the kind of activity profile you'd want to see before self-hosting it for anything business-critical, but also a reminder that its rough edges are still being found in public, not already sanded down by years of production use elsewhere.

None of this settles which is "better" — Temporal being older doesn't make its determinism model the right fit for a team that just wants a background job runner, and Restate being younger doesn't disqualify it for a greenfield agent project with no legacy Temporal investment to protect. But maturity is a real input to the decision, particularly for the "will this still be actively maintained and staffed in two years" question that matters more for infrastructure you're building a business on than for a library you can swap out later.

Observability and debugging a failed agent run

This is an underrated axis because it's where you actually spend time once a system is in production, not during the initial proof of concept. All four ship a dashboard that shows a workflow's step-by-step execution history, but the shape of what you're debugging differs. Temporal's event history is the most granular and the most alien to newcomers — you're reading raw workflow/activity/timer events and cross-referencing them against your code, which is powerful once you're fluent in it and opaque before that. Inngest and Trigger.dev both present something closer to a trace view — a timeline of named steps with inputs/outputs attached, which reads naturally if you're used to APM tooling like Datadog or Honeycomb traces. Restate's introspection is proxy-level: because it sits in front of your services rather than owning workflow execution the way Temporal does, what you see is closer to a service mesh's request log than a workflow engine's execution history, which is unfamiliar if you're coming from Temporal but familiar if you're coming from a microservices background.

For an AI agent specifically, the thing you actually want to inspect after a bad run is usually "what did the model see, and what did it decide to do" at each step — none of these four platforms are LLM-observability tools in the way Langfuse or Braintrust are, and pairing one of these durable execution engines with a dedicated LLM tracing tool is common in practice, not redundant. The durable execution layer answers "did this step run, and can I resume it"; it doesn't natively answer "was this a good tool call."

What developers should actually weigh

Cost model. Temporal Cloud's pricing is usage-metered across workflow "actions," active/retained storage, and support tier, with published entry points around $100–$500/month before enterprise negotiation — but the self-hosted Temporal Server is free and identical in capability, so cost is really an operations-vs-cash tradeoff. Inngest's hosted free tier covers a modest number of monthly executions before its paid tier begins around the low hundreds of dollars a month; because the server isn't conventionally open-source, self-hosting to avoid that cost isn't straightforwardly available the way it is for Temporal or Trigger.dev. Trigger.dev's hosted tiers start cheaper, and its Apache 2.0 self-hosted path means a team with existing infra capacity can avoid the recurring cost entirely — at the cost of owning the operational burden. Restate doesn't publish the kind of tiered SaaS pricing the others do; its pitch is that the lighter deployment footprint (one binary, no external database) makes self-hosting itself cheap enough that the pricing-page comparison is somewhat beside the point.

Lock-in. This is where the determinism constraint cuts both ways. Temporal's replay model means your workflow code is tightly coupled to the SDK's execution semantics — moving off Temporal generally means rewriting orchestration logic, not just swapping a client library. Inngest and Trigger.dev's step-function model is closer to ordinary async code, which is easier to reason about and, arguably, easier to migrate away from later. Restate's Virtual Object model is the newest abstraction here and least like anything you've written before, which is a real cost even if the operational footprint is lighter.

Latency and step granularity. All four checkpoint at step boundaries, which means the practical latency floor for a workflow is however long it takes to durably persist each step's result before moving to the next — typically low milliseconds for these systems, but it means chatty step-per-token patterns are the wrong fit for any of them; you checkpoint after a tool call or a full model response, not per streamed token.

DX and adoption cost. This is the most differentiated axis. Temporal's learning curve is real — determinism rules, Activities vs Workflows, a worker fleet to run and scale — and teams that haven't operated it before should budget real ramp-up time, not an afternoon. Inngest and Trigger.dev are both designed to get a first durable function running same-day inside an existing Next.js or Node app. Restate sits in between: the single-binary deploy is simple, but Virtual Objects are a new mental model even for engineers who've used Temporal before.

Security and multi-tenancy. Temporal Cloud and Restate Cloud both offer namespace/tenant isolation for multi-tenant SaaS use; the interesting nuance for AI agent builders specifically is that if your agent executes arbitrary tool calls with real side effects (payments, infra changes, sending communications), the durable execution layer is not your security boundary — none of these four systems sandbox what a step is allowed to do. That has to be enforced at the tool-definition layer regardless of which orchestration engine sits underneath.

Practical use cases per option

Temporal: multi-day approval workflows with strict exactly-once guarantees (payment sagas, order fulfillment, compliance workflows) where an agent step is one participant in a larger, already-Temporal-native system.
Inngest: teams already deployed on Vercel-style serverless who want event-triggered AI pipelines (webhook comes in → agent runs → result posted back) without operating any infrastructure themselves.
Trigger.dev: TypeScript-only teams that want the Inngest-style DX but need to self-host for compliance, data-residency, or cost reasons, or who want to avoid depending on a vendor's hosted-only server.
Restate: per-session or per-user AI agents modeled naturally as long-lived stateful actors (a support agent tied to one ticket, a coding agent tied to one repo session) where you want exactly-once tool-call semantics without adopting Temporal's full operational model, and where a polyglot backend (not just TypeScript) matters.

What the marketing pages don't emphasize

Every vendor page in this category frames its competitors' complexity as the problem being solved and undersells its own. A few things worth knowing before you commit:

Temporal's "just write normal code" pitch has an asterisk the size of the determinism rulebook — accidentally calling non-deterministic code inside a Workflow is a common, sometimes silent, source of production bugs for teams new to the model.
Inngest's server not being conventionally open source means "self-hosting" claims should be read carefully — the delayed-publication license is not the same guarantee as Trigger.dev's or Restate's permissive licensing, and it matters if avoiding vendor dependency is a real requirement rather than a nice-to-have.
Trigger.dev's self-hosted path being "the same code as the hosted product" is true, but running it well — workers, queues, the Postgres/Redis dependencies underneath — is still real operational surface area that the marketing copy compresses into "just self-host it."
Restate is the youngest project of the four by a wide margin, with a correspondingly smaller production track record at scale; the single-binary simplicity is genuine, but "battle-tested at Temporal's scale" is not yet a claim Restate can make for itself, and its own comparison pages against Temporal are, unsurprisingly, vendor-authored rather than independently audited.
None of the four vendors' comparison pages will tell you that adopting any of these systems is itself a commitment — workflow history/journal formats are generally not portable between them, so this is a decision with real switching costs baked in from day one, not a reversible config choice.

Comparison table

Dimension	Temporal	Inngest	Trigger.dev	Restate
Core model	Workflow + Activity, deterministic replay	Event-triggered functions with memoized `step.run()`	TypeScript tasks with durable steps	Durable functions + stateful Virtual Objects
Deployment	Self-hosted server/cluster or Temporal Cloud	Hosted cloud (self-hosting not standard)	Hosted cloud or self-hosted (same code)	Single binary / Docker, self-hosted or Restate Cloud
License	MIT (server), open source	SSPL w/ delayed Apache 2.0 (server), Apache 2.0 (SDKs)	Apache 2.0	Source-available / open (BSD/MIT-family per component)
Languages	Go, Java, TS, Python, .NET, PHP, Ruby	TypeScript, Python, Go, Kotlin/Java	TypeScript/JavaScript only	TypeScript, Java/Kotlin, Python, Go, Rust
GitHub stars (approx., Aug 2026)	~22.4k	~5.7k	~16.1k	~4.3k
Entry hosted price	~$100–500/mo (Cloud)	Free tier, then ~$75/mo+	Free tier, then ~$10–50/mo+	No standard tiered SaaS pricing published
Learning curve	Steep (determinism rules, worker ops)	Low	Low	Moderate (new Virtual Object model)
Best-fit unit of durability	One workflow execution	One event-triggered function run	One task run	One stateful object/session across a system
Multi-tenant / polyglot backend	Yes	TS-centric, some polyglot SDKs	No (TS-only)	Yes

Independent read

Stripped of vendor framing, the honest summary is that this is not really a four-way race for the same job. Temporal is the incumbent for teams that need proven, exactly-once orchestration and are willing to pay the operational and learning-curve cost for it — and for anyone already running Temporal for non-AI workloads, routing agent orchestration through the same system is usually the path of least resistance, not a new evaluation. Inngest and Trigger.dev are close cousins competing mostly on licensing philosophy and self-hosting freedom rather than fundamentally different technical approaches — pick based on whether "vendor-hosted-only, SSPL-delayed source" or "fully Apache 2.0, self-host from day one" matters more to your team, since the developer experience of writing a function is nearly identical between them. Restate is the one making a genuinely different architectural bet, and it's the most interesting option specifically for AI agents because per-session stateful actors map naturally onto how conversational and multi-agent systems actually behave — but it's also the newest and least proven at scale, which is a real cost, not a footnote.

Who should pick what

Pick Temporal if you're already operating it, need audited exactly-once guarantees for workflows with financial or compliance stakes, and can afford dedicated platform engineering time. Pick Inngest if you want the fastest path to a durable AI pipeline on top of an existing serverless deploy and vendor dependency is an acceptable tradeoff for speed. Pick Trigger.dev if you want that same fast DX but need a genuinely open, self-hostable path — for compliance, cost control, or just principle — and your stack is TypeScript end to end. Pick Restate if you're building session-oriented or multi-agent systems where per-conversation state is the natural unit of durability, you need a polyglot backend, and you're comfortable being an early adopter of a smaller, newer project in exchange for a lighter, more elegant operational footprint.

Discussion question: For teams already running Temporal for non-AI workloads (payments, fulfillment, etc.), is there a real technical case for routing AI agent orchestration through a second, lighter-weight durable execution system like Restate or Trigger.dev instead of just extending the existing Temporal deployment — or is that split mostly organizational (different teams, different comfort levels) rather than architectural?

Sources: