DEV Community: Jason Lee

The LLM Observability Tool You Pick Today May Not Exist As You Know It Tomorrow

Jason Lee — Tue, 11 Aug 2026 12:09:14 +0000

In a five-week stretch between mid-January and late February 2026, the three companies that most engineering teams weigh when picking an LLM observability stack all changed what they fundamentally are. ClickHouse bought Langfuse outright as part of a $400M Series D. Mintlify acquired Helicone and put it into maintenance mode — no more new features, ever, just security patches. And Braintrust raised an $80M Series B and stayed independent, doubling down on being the "eval-first" pure-play.

If you're choosing one of these three right now, that's not trivia. It's the actual decision. The feature checklists for Langfuse, Helicone, and Braintrust have converged enough that on a Tuesday afternoon comparing docs, you'd struggle to tell them apart — all three trace LLM calls, all three run evals, all three ingest OpenTelemetry spans. What differs, and what almost nobody writing "top LLM observability tools" listicles bothers to check, is which of these three still has a team whose job is to keep building the thing you're about to wire into production.

This is a comparison of what each platform does today, but more importantly, of what kind of company you're actually buying into for the next two years.

Why this comparison matters now

LLM observability went from "nice to have" to "the thing that tells you your agent silently started hallucinating refund amounts" sometime in 2025, as more teams moved from demos to production agents that call tools, retrieve documents, and chain multiple model calls per request. Traditional APM tools like Datadog or New Relic were built for exceptions and latency percentiles, not for "the model returned syntactically valid but factually wrong JSON." That gap created an entire product category — trace the LLM call, score the output, catch regressions before they ship — and Langfuse, Helicone, and Braintrust became the three most-adopted names in it.

Then, within one quarter, the category's competitive landscape reshuffled. A team picking today isn't just comparing pricing tables; they're picking a bet on who's still actively shipping in 2027. That's a genuinely different question than "which dashboard has more chart types," and it's the one this article tries to actually answer instead of skating past it.

There's also a structural reason this specific category attracts acquisitions rather than staying independent forever: LLM observability is fundamentally a data-infrastructure problem wearing a developer-tools UI. Agent traces are large, deeply nested (a single request can spawn dozens of child spans across retrieval, tool calls, and sub-agent hops), and need to be both written fast and queried flexibly for evaluation. That's exactly the workload profile that analytics-database companies like ClickHouse are built to serve, which is part of why "an LLM observability startup gets bought by the database it's built on" isn't a one-off story — it's closer to the shape this market was always going to take.

What each one actually does

Langfuse started as an open-source (MIT-licensed core) LLM engineering platform: tracing, prompt management with versioning, LLM-as-a-judge and code-based evaluators, dataset management, and a playground for iterating on prompts against real data. It ships typed SDKs for Python and JS/TS, integrates natively with LangChain, LlamaIndex, the OpenAI SDK, and LiteLLM, and accepts OpenTelemetry spans from anything else. Deployment is genuinely flexible — Langfuse Cloud, a five-minute Docker Compose install, a VM, Kubernetes via Helm, or Terraform modules for AWS/Azure/GCP. As of mid-2026 it sits around 32,900 GitHub stars, and at acquisition time ClickHouse cited over 26,000 SDK installs per month, 6,000+ Docker pulls, and adoption inside 19 of the Fortune 50.

Helicone takes a different architectural stance: it's primarily an AI gateway — a proxy you route requests through — that layers observability, cost tracking, caching, and rate limiting on top, rather than a tracing SDK you instrument your code with. That means integration is often a one-line base-URL swap instead of wrapping every LLM call, which is genuinely the fastest path to "I can see my OpenAI/Anthropic/Gemini spend by endpoint" of the three. It's also open source and self-hostable, and until March 2026 was on a clear trajectory to add deeper eval and agent-observability features to compete more directly with Langfuse and Braintrust.

Braintrust is built eval-first: the trace and the evaluation score live in the same object from day one, not bolted on after the fact. Its differentiators are CI/CD-integrated evals that can block a merge when a quality score regresses, a proprietary trace database called Brainstore built specifically for large nested agent traces (which traditional row-oriented databases handle poorly), and "Topics," a feature that automatically clusters production traces into patterns so teams can spot emergent failure modes without hand-writing every eval upfront. It ships SDKs for Python, TypeScript, Go, Ruby, and C#, and — notably — has no meaningful self-hosted open-source tier; Enterprise offers hybrid/on-prem deployment, but the product is fundamentally cloud-first and commercially licensed.

A fourth name worth a sentence: Arize AI, particularly its open-source Phoenix project, sits adjacent to all three with a heavier focus on ML-style evaluation rigor and drift detection carried over from traditional model-monitoring roots. It's a legitimate option for teams that already think in terms of embeddings and statistical drift, but it's a narrower fit for teams whose primary need is "trace my agent and catch regressions," so I'm treating it as a footnote rather than a fourth full contender here.

Worth being precise about what "evaluation" means across these tools, because the word gets used loosely. All three support three broad scoring mechanisms: LLM-as-a-judge (another model grades the output against a rubric), code-based evaluators (deterministic checks — did the JSON parse, does the output contain a banned phrase, is the extracted number within tolerance), and human-in-the-loop review queues for cases neither of the first two can reliably judge. Where they differ is workflow integration: Braintrust wires evaluators directly into CI so a regression fails the build; Langfuse treats evals as a first-class object you can run ad hoc or schedule against production traces and datasets; Helicone's evaluation surface is the thinnest of the three, reflecting its gateway-first origin — historically closer to "flag this trace for review" than "block this deploy."

How each is actually built

The architecture differences explain a lot of the trade-offs that marketing pages gloss over.

Langfuse's core data layer is ClickHouse itself — the company literally built v3 of its product on the database that would go on to acquire it, switching from Postgres because Postgres became the ingestion/analytics bottleneck at scale. That's not a coincidence; it's the reason the acquisition made technical sense in the first place, and it's also why Langfuse's self-hosted deployment is non-trivial: running it well at production scale means running ClickHouse well, which is its own operational skill.

Helicone's proxy architecture means it sees every request by definition — no SDK instrumentation gaps, no missed spans because someone forgot to wrap a call — but it also means your LLM traffic physically routes through Helicone's infrastructure (or your self-hosted instance of it) before hitting OpenAI or Anthropic. That's a latency and availability dependency that SDK-based tracing doesn't introduce, and it's a meaningfully different risk profile to sign up for, especially now that the team maintaining that proxy has been folded into a documentation company.

Braintrust's Brainstore is the most opinionated architectural bet: a purpose-built database for nested, tree-shaped agent trace data, which the company claims outperforms "traditional" databases on full-text search, write latency, and span load time for this specific workload (Braintrust doesn't publish the comparison numbers on the public pricing/marketing pages, so treat the specific multipliers as vendor-claimed until you benchmark your own traces). The trade-off is that Brainstore is proprietary — you can't self-host your way out of it, and there's no open-core version to fall back on if you want to leave.

There's a second layer to Braintrust's architecture worth flagging: "Loop," a built-in agent that can generate prompts, scorers, and datasets on request, and "Topics," which continuously clusters live production traces against custom facets you define (use case, customer segment, compliance sensitivity, tone) without you having to hand-write a taxonomy first. Both are genuinely novel relative to Langfuse and Helicone's current feature sets — neither ships an equivalent today — but both also mean more of your evaluation logic lives inside Braintrust's proprietary layer rather than in code you own and could port elsewhere.

On the security and compliance axis, all three have converged toward the same checklist at their upper tiers: SOC 2 Type II, HIPAA support, and SSO/SAML are available from Braintrust (Enterprise), Langfuse (Pro and up, with BAAs available), and Helicone (Team and up). None of the three differentiates meaningfully here anymore — treat compliance as table stakes you should verify at your specific tier rather than a deciding factor between them.

What changed vs. before

Eighteen months ago, "which LLM observability tool" was a feature-and-pricing question. Now it's also a going-concern question, and here's the timeline that made it one:

January 16, 2026 — ClickHouse announced it had acquired Langfuse as part of closing a $400M Series D led by Dragoneer Investment Group, with Bessemer, GIC, Index, Khosla, Lightspeed, and others participating. Langfuse's founders (Marc Klingen, Max Deichmann, Clemens Rawert) and the whole team joined ClickHouse. In their own announcement, the founders were explicit: no licensing changes, self-hosting remains first-class, the team keeps building Langfuse, roadmap unchanged.
February 17, 2026 — Braintrust announced an $80M Series B led by ICONIQ Capital, with a16z, Greylock, Elad Gil, and basecase capital returning. Publicly named customers include Notion, Vercel, Ramp, Stripe, Replit, Zapier, Airtable, and Instacart. The stated use of funds: expanding engineering and go-to-market teams, new offices, and new products revealed at Braintrust's user conference.
March 3, 2026 — Mintlify announced it had acquired Helicone, with founders Justin Torre and Cole Gottdank and the team joining Mintlify in San Francisco. Mintlify's own announcement states Helicone moves into maintenance mode: security updates, bug fixes, and "new models" keep shipping, but — in the founders' own words on their blog — "we will not be shipping new features going forward." A follow-up post from the founders frames the move as a bet that the "knowledge layer" (Mintlify's docs/retrieval business) matters more than the observability layer they'd spent three years building.

Read plainly: one of these three vendors told its own users, in writing, that active development has stopped.

Why developers should actually care

Cost. Helicone's published pricing starts free (10K requests/month), $79/month Pro, $799/month Team, and custom Enterprise. Langfuse Cloud runs Free, $29/month Core, $199/month Pro (with a $300/month add-on for enterprise SSO/RBAC), and $2,499/month Enterprise, all with usage-based overage on top of included units. Braintrust's model is structurally different — a platform fee ($0 Starter, $249/month Pro) plus consumption-based charges for processed data ($4/GB then $3/GB) and scored outputs ($2.50 then $1.50 per 1,000), which means your bill scales with eval volume in a way the other two don't as directly. None of these are apples-to-apples without knowing your actual trace volume and eval cadence — get real numbers from each vendor's calculator before assuming the sticker price is the bill you'll get.

Self-hosting and lock-in. This is where the three diverge hardest. Langfuse's MIT-licensed core is self-hostable with no seat caps, no retention limits, and no usage caps — genuinely free if you're willing to run and scale the ClickHouse-backed stack yourself (real talk: that's roughly $3,000–4,000/month in infra and DevOps overhead at medium scale, against $199–300/month for the equivalent managed Pro tier, so "free" self-hosting isn't actually free once you count engineering time). Helicone is also open source and self-hostable, though a maintenance-mode project only gets you as far as its last shipped release — no future architecture improvements are coming. Braintrust has essentially no meaningful self-hosted or open-core path; you're a cloud customer of a VC-backed company, full stop, and your evaluation history and Brainstore-formatted traces live in their infrastructure.

Latency and blast radius. Helicone's gateway model means an outage or slowdown on their infra is a direct outage or slowdown on your model calls, not just a gap in your dashboards. Langfuse and Braintrust's SDK/OTel-based tracing degrades more gracefully — a tracing backend hiccup means you lose some observability data, not that your app stops calling the LLM.

Maintainability, i.e., "will this still be a product in two years." This is the part the acquisition wave actually answers, and it answers it unevenly. Langfuse's founders stayed on their own product with a funded, aligned parent whose core business (real-time analytics infra) benefits directly from Langfuse's continued growth — that's about as good an acquisition outcome as an open-source infra project gets. Braintrust just took venture money specifically to keep building faster, and remaining independent means its roadmap answers to its own customers rather than a parent company's separate product strategy. Helicone's founders were explicit that new feature development has stopped; whatever gap exists today between Helicone and Langfuse/Braintrust on evals, agent observability, or anything else is now a permanent gap, not a temporary one, unless a fork or a well-resourced competitor picks up where they left off.

Practical use cases

Pick Langfuse if you need to keep sensitive trace data inside your own infrastructure (regulated industries, contractual data residency requirements), you already run or are comfortable running ClickHouse-adjacent infra, and you want a genuinely complete open-source tool rather than an open-core teaser. It's also the strongest fit if your stack already leans LangChain/LlamaIndex, given the native integration depth.

Pick Braintrust if evals are the actual bottleneck — you have a quality bar you want enforced automatically pre-merge, not just visibility after the fact — and you're comfortable being a cloud customer of a well-funded startup. The CI/CD quality-gate workflow and Topics' automatic pattern discovery are the most differentiated capabilities in this comparison; nothing in Langfuse or Helicone matches "block the deploy because eval scores regressed" as a first-class, built-in workflow today.

Pick Helicone, cautiously, if you specifically want gateway-style cost tracking and caching with the absolute lowest integration lift (swap a base URL, done), your needs are already fully met by its current feature set, and you're comfortable that "current feature set" is now permanent. It remains a reasonable choice for teams that only need routing, logging, and cost/caching — just budget migration effort later, because "maintenance mode" is a polite way of saying sunset clock, even an unusually slow one.

Mixed/hybrid approaches are common in practice. Plenty of teams run Helicone (or another gateway) purely for routing/caching/fallback in front of multiple model providers, while sending traces to Langfuse or Braintrust for the actual observability and eval workflow — the gateway and the trace-and-eval platform aren't mutually exclusive, and given Helicone's status, that division of labor is arguably the more defensible way to keep using it going forward.

A few more concrete scenarios worth naming, since "pick the eval-first one" only helps if you know what eval-first workflows actually look like day to day. A support-bot team iterating on a system prompt weekly gets the most direct value from Braintrust's playground-to-dataset-to-CI loop: turn last week's worst production traces into a regression dataset with one click, then gate every future prompt change against it. A platform team building an internal LLM gateway for a dozen product teams to share — centralized rate limiting, per-team cost attribution, response caching to cut redundant spend — is closer to Helicone's original design center than either of the other two, frozen roadmap notwithstanding. And a team building agents inside a compliance-heavy environment (health data, financial data) that needs both traces and prompts to physically never leave a VPC has, realistically, one option here: Langfuse self-hosted.

What the marketing pages don't say

Braintrust's Brainstore performance claims (faster full-text search, write latency, span load vs. "the competition") are stated without published comparison methodology or numbers on the public marketing pages — reasonable to be skeptical of specific multipliers until you run your own trace volume through it.

Langfuse's "self-hosting is free" pitch is true of licensing and false of total cost once you count the infrastructure and the DevOps time to run ClickHouse well at production trace volume — several independent teardowns put realistic self-hosted TCO in the same ballpark as, or above, the managed Pro tier once you're past hobby scale.

Helicone's and Mintlify's announcement posts both frame maintenance mode gently ("services will remain live," "security updates... keep shipping") without emphasizing what that means operationally: no roadmap response to competitive feature gaps, no new provider integrations as new model APIs ship, and a support org that isn't growing with your usage.

And all three vendors' comparison pages (yes, including the ones aggregated in this piece) are written by the vendor being compared favorably — treat any "X vs Y" page hosted on x.com's own domain as marketing copy first, evidence second.

One more thing none of the acquisition announcements dwell on: all three deals were framed, by the acquired company's own founders, as unambiguously positive for users — "no changes," "roadmap continues," "your data is safe." That's the correct thing for a founder to say in an acquisition announcement, and in Langfuse's case the evidence since January (continued commits, continued open-source releases) backs it up so far. But five months of continuity after an acquisition is a thin sample size, and "maintenance mode" for Helicone was announced with the same reassuring tone as Langfuse's "nothing changes" — the actual difference between the two outcomes only became visible once you read past the headline to what each post committed to shipping next. Read the fine print, not the framing, when a vendor you depend on gets acquired.

Comparison table

Dimension	Langfuse	Helicone	Braintrust
Core model	SDK/OTel tracing + evals, open-source-first	AI gateway/proxy + logging	SDK/OTel tracing, eval-first, CI/CD gating
License	MIT core, open source	Open source	Proprietary, cloud-only
Self-hosting	Full-featured, unlimited on free tier	Available, frozen at current feature set	Enterprise-only hybrid/on-prem
Entry cloud price	Free / $29 mo (Core)	Free / $79 mo (Pro)	Free / $249 mo (Pro)
Pricing model	Included units + $8/100k overage	Included requests + usage-based	Platform fee + $/GB processed + $/1k scores
Standout feature	Open-source completeness, prompt mgmt	Zero-code proxy integration, caching	CI/CD quality gates, automatic pattern discovery (Topics)
Primary DB	ClickHouse (post-v3)	Proprietary logging store	Brainstore (proprietary, purpose-built)
Corporate status (as of Aug 2026)	Acquired by ClickHouse, Jan 2026 — team intact, roadmap continuing	Acquired by Mintlify, Mar 2026 — maintenance mode, no new features	Independent, $80M Series B Feb 2026
Best fit	Regulated/data-residency-sensitive teams, LangChain-heavy stacks	Multi-provider routing/cost-tracking with minimal code changes	Teams that need enforced quality gates in CI/CD
Biggest risk	Self-hosted TCO creep at scale	Feature set is now frozen	No self-host exit ramp; fully dependent on vendor

Independent read

None of these is a bad tool today — that's precisely what makes the decision harder, not easier. If the three had wildly different feature depth, the choice would make itself. Instead you're picking based on second-order bets: whether you trust an infra database company to keep an open-source observability product healthy inside its portfolio (Langfuse/ClickHouse looks like a genuinely good pairing so far, for what a five-month-old acquisition is worth), whether a well-funded eval-first pure-play stays focused as it scales its GTM team post-Series-B (Braintrust, still to be proven, but the incentives point the right way), or whether "maintenance mode" is a real long-term option for infrastructure you're about to depend on in production (Helicone, and the honest answer is: for narrow use cases yes, for anything you expect to grow into, no).

Which reader profile should pick which

If you're a regulated-industry team or one with hard data-residency requirements, Langfuse's self-hosted MIT core is the only one of the three that actually satisfies "our trace data never leaves our VPC" without an enterprise contract — pick it, and budget for the ClickHouse operational overhead going in.

If your actual pain point is "we ship an agent update and have no idea if quality regressed until a customer complains," Braintrust's CI/CD-gated evals are purpose-built for exactly that workflow, and it's worth the lack of a self-host option if you're fine being a cloud customer of a company that just took funding specifically to keep building.

If you're early-stage, multi-provider, and mostly need cost visibility and caching without touching your codebase, Helicone still does that job well today — just don't plan your two-year roadmap around features it doesn't already have.

And if you're not sure yet, that's a legitimate answer too: all three have generous free tiers, and the actual cost of trying two of them for two weeks on a real workload is lower than the cost of guessing wrong on the vendor whose long-term trajectory you can't fully know in advance.

Which of these three would you actually bet your team's roadmap on for the next two years, and does a vendor's post-acquisition status change your calculus as much as it changed mine writing this?

Sources:

DevCleaner Bets Your AI Coding Tools Are the New Disk Hogs, Not Xcode

Jason Lee — Tue, 11 Aug 2026 09:21:27 +0000

Every Mac cleanup tool on Product Hunt makes the same pitch: your disk is full of junk, click here to get it back. Most of them mean browser caches, old photos, and duplicate downloads. DevCleaner means something narrower and, if you're a developer, more interesting: the private stash every build tool keeps and never cleans. Xcode DerivedData. Gradle caches. Forgotten iOS simulators. npm's attic.

That pitch alone wouldn't be worth 4,000 words — "Mac cleaner but for devs" is not a new category. What makes DevCleaner worth a closer look in August 2026 is what its version history quietly reveals: it has spent the last two months racing to also clean up after your AI coding tools. ~/.claude, ~/.cursor, OpenAI Codex CLI, Cline, and downloaded model weights from Ollama and LM Studio all got added to the scanner list in the 1.8 and 1.9 releases. That's the actual story here: a solo indie developer watching, in near real time, agentic coding tools become one of the biggest sources of disk bloat on a working developer's machine — and building a business on being the first cleaner that knows the difference between a Gradle cache and a 40GB local model.

What happened

DevCleaner is a free macOS menu bar utility built by David Tereba, a solo maker based in Prague. It launched on Product Hunt on June 16, 2026 and, by the maker's own account on the product page, finished #12 on launch day — a respectable but unspectacular showing, not a chart-topper. That's worth stating plainly up front, because "Product Hunt launch" headlines often imply viral traction that the underlying numbers don't support; here the maker isn't claiming otherwise.

What's more telling than the launch-day rank is the cadence of updates since: version 1.6 added Project Hibernation (archiving idle projects instead of deleting them), 1.8.0 shipped on July 14 with expanded scanning for ~/.npm, .claude, .cursor, Codex, and Cline caches plus JetBrains and Android Studio coverage, and 1.9.0 followed with SwiftPM source packages, browser-testing caches (Playwright, Electron, Cypress, Puppeteer), Android emulator snapshots, and a full simulator device manager. As of this writing the app is at 1.10.1. That's four meaningful releases in under two months from one person — a pace that says more about product-market signal than the launch-day leaderboard position does.

DevCleaner is also not a standalone bet. It's the middle app in a three-tool suite Tereba is building for the indie-developer lifecycle: Planelo for capturing and triaging project ideas, DevCleaner for the build phase, and TesterBuddy for collecting beta feedback from TestFlight and Google Play once you ship. None of the three appear to be venture-funded; all three are narrow, single-purpose utilities sold directly to developers. That context matters for how you should read the rest of this piece — this is bootstrapped indie software, not a category-defining platform play.

What it actually does

Under the hood, DevCleaner is a scanner-plus-risk-model. It ships with detectors for 23 developer ecosystems and lets you add arbitrary custom folders on top. The list spans the obvious build-tool suspects — Xcode (DerivedData, SPM cache, simulators, archives, device support), Android Studio (Gradle caches, AVDs, wrapper distributions), JetBrains IDEs (indexes, compilation caches, logs), Node.js package managers (npm, Yarn, pnpm, Bun, node-gyp), Python (pip and uv wheel caches, stale virtualenvs), Flutter, Rust (cargo registry and git checkouts), Go, CocoaPods, Homebrew, Docker (build cache, dangling images, stopped containers), Maven, Composer, and Unity — and then the newer, more interesting tier: VS Code, Claude desktop and Claude Code caches, ChatGPT desktop caches, Gemini CLI temp files, Cursor, Windsurf, Antigravity, and downloaded model weights from Ollama and LM Studio.

Every category is tagged Safe, Warning, or Danger, and only Safe items are pre-selected for deletion:

Safe (deleted by default): pure caches that regenerate on the next build — DerivedData, Gradle caches, pip cache. The stated cost of deleting them is "one slower compile, nothing more."
Warning (your call, never pre-selected): things that grow back slowly or that you might still need — old simulators, .xcarchives, AVDs.
Danger (hands off): SDKs and device symbols that can break your environment if removed — Android SDK components, iOS Device Support files. The app shows their size, asks twice, and never touches them on its own. Credentials and session files sit on what the FAQ describes as a hard deny-list, and the app checks whether the owning tool is still running before touching its cache.

Beyond one-shot cleanup, two features push DevCleaner past "glorified rm -rf":

Ghost Projects and Project Artifacts surface stale, forgotten project folders and their node_modules/build/.venv directories — the stuff you cloned six months ago and never deleted.

Project Hibernation (since 1.6) archives an entire idle project into a single compressed file, strips the regenerable junk (node_modules, build folders) while keeping lockfiles, and restores it later with dependencies reinstalled. It offers a dry-run restore that verifies the archive and previews exactly what will land where before writing anything — a real nod to the fact that you're one bad archive away from losing a project entirely.

The app itself is small: 4MB, no account required, native menu bar UI with no dock icon — just a badge showing reclaimable space near the clock.

It's worth being concrete about why these particular caches balloon, because the mechanics differ per tool and that's exactly what a risk-tiered scanner has to get right. Xcode's DerivedData grows because every build variant, every simulator target, and every incremental compile leaves its own subtree behind, and Xcode almost never prunes it itself — developers who haven't touched ~/Library/Developer/Xcode/DerivedData in a year routinely find tens of gigabytes there. Docker's build cache grows because layer caching is deliberately generous by default — it keeps intermediate layers around to speed up the next build, and "docker system prune" is a command most developers learn about only after docker.raw eats 80GB. node_modules duplication is the oldest offender in the list: every cloned repo gets its own full dependency tree, and unlike Python's shared site-packages-per-venv convention, Node's per-project install model means the same lodash gets downloaded and stored dozens of times across a machine. None of this is new information to anyone who's run du -sh in frustration, but it's the reason a tool that knows these patterns per ecosystem is doing something a generic "find big files" utility structurally can't.

How it works, architecturally

There isn't a public technical writeup of DevCleaner's internals, and the app doesn't appear to be open source — there's no linked repository on the product page, in the FAQ, or on the maker's two public GitHub repos (which are SDKs for TesterBuddy, not DevCleaner itself). So what follows is inferred from behavior described on the product page, not from source.

The design is straightforward: a background scanner walks a fixed table of known cache paths per ecosystem (the same approach an open-source alternative, k-angama/macOS-dev-cache-cleaner, documents openly in its Constants.swift file — a useful reference if you want to see what "known cache paths for Xcode, Gradle, CocoaPods, npm/Yarn/Bun" actually look like on disk). Sizes stream in live as the scan proceeds. Each path is mapped to a risk tier, Quick Clean acts on the Safe tier only, and everything else requires explicit selection. Workspace-level cleanup (matching package.json → node_modules, Package.swift → .build, settings.gradle → .gradle, and similar marker-file-to-generated-directory rules) is the same pattern used by that open-source project, which suggests it's close to industry-standard practice for this category rather than a DevCleaner invention.

The one place the architecture gets genuinely interesting is the AI-tool scanners, because they don't all behave the same way underneath, and the product page doesn't distinguish them. That's worth unpacking, because it's the piece a launch page has every incentive to gloss over.

Project Hibernation deserves a slightly closer look too, because it's the feature that separates DevCleaner from being "just" a cache sweeper. The problem it targets is real and specific: a side project you haven't opened in eight months isn't a cache, it's a whole working tree, and the instinct most developers have is to either leave it alone forever (disk creep) or delete the folder outright (data loss risk if you're wrong about needing it again). Hibernation's answer — strip the regenerable parts, keep the lockfile, compress the rest into one file, and offer a dry-run restore that verifies the archive without writing anything — is a reasonable middle path that neither general cleaners nor the open-source alternative referenced above attempt. Whether it holds up on a genuinely large monorepo with native build artifacts and symlinks is untested by anything in this research; it's a feature to try cautiously on a low-stakes project first, which is also what the dry-run restore step seems designed to encourage.

What changed vs. before — and the blurred line the launch page doesn't draw

General-purpose Mac cleaners like CleanMyMac treat your whole disk as undifferentiated clutter: system caches, browser data, language files, "junk" — categories a non-developer user recognizes. DevCleaner's whole premise, and its FAQ says this explicitly when asked how it differs from CleanMyMac, is that it "knows developer caches... and labels what's safe per toolchain instead of treating every folder like temp files." That's a legitimate differentiation for the classic build-tool caches: a general cleaner genuinely doesn't know that ~/Library/Developer/Xcode/DerivedData is safe to nuke while ~/Library/Developer/Xcode/DeviceSupport is not.

But the 1.8/1.9 expansion into AI tool caches muddies exactly the distinction DevCleaner is selling. .cursor and .claude editor caches are the same kind of thing as a JetBrains index — metadata and compiled artifacts that rebuild transparently. Ollama and LM Studio model weights are not. A quantized 70B model can be tens of gigabytes, took real time and bandwidth to pull down, and in many cases isn't reproducible instantly on a residential connection the way a Gradle cache is. Listing "Ollama: downloaded LLM models" in the same 23-ecosystem grid as "pip cache" — without the page stating which risk tier model weights land in — is the single biggest ambiguity in DevCleaner's current pitch. If those are filed under Warning (not pre-selected), the safety model holds up. If a future release starts treating them as Safe because "the app can just re-download it," that's a materially different risk than losing a build cache, and it deserves to be called out rather than folded into the same "reclaim gigabytes" framing as everything else. As of this research, the product page doesn't specify the tier for AI model weights explicitly enough to settle the question either way — which is itself worth flagging.

Why developers should care

Cost. The free tier is genuinely functional, not a crippled trial: scanning, Quick Clean, Ghost Projects/Project Artifacts discovery, and restoring a hibernated project are free forever with no account. Pro — Auto Clean, Smart Triggers (clean on app quit), and batch Project Hibernation — is $29 once (activatable on up to 3 Macs) or $19.99/year if you'd rather subscribe. Pricing a one-time purchase below roughly 1.5 years of the subscription option is a deliberately anti-subscription-fatigue stance, and it's worth noting because most 2026-era dev tools default to recurring billing by design.

DX. No account, no cloud sync, no telemetry dashboard to configure — you download a 4MB app and it works. For a category of tool whose entire value proposition is "trust me with delete permissions on your home directory," minimal friction to start is also minimal friction to abandon if something feels off, which is a reasonable trade.

Security and trust. This is the category's real cost, and it's not DevCleaner-specific: any tool that walks your home directory and deletes files needs your trust, and DevCleaner asks for that trust without a public source repository to audit. The FAQ's claims about a "hard deny-list" for credentials and session files are reassuring in wording but unverifiable from the outside. If you're the kind of developer who reads the diff before merging a dependency bump, that's a real gap — not a dealbreaker, but a reason to start with manual category selection rather than Auto Clean on day one.

Lock-in. Effectively none. It's a local utility with local config; there's no data to migrate out of and no subscription trap if you stop paying (Pro features simply stop, Free features keep working).

There's a broader economic point worth naming, too. DevCleaner is a single-purpose, bootstrapped utility competing in a category where the incumbent — CleanMyMac — is a much larger, subscription-first product with a marketing budget and a general-consumer audience to fund it. DevCleaner can't out-market that, so it's competing on specificity instead: knowing what a .claude cache is, what an Xcode archive costs to lose, what a stale Android emulator snapshot looks like. That's a defensible niche as long as the maker keeps pace with what developers are actually installing — which, per the version history, is exactly what's happened so far. It's also a fragile one: the moment a general cleaner adds a "developer mode" with even half this granularity, DevCleaner's differentiation narrows to Project Hibernation and whatever ecosystem coverage it ships next.

Practical use cases

Reclaiming space before a big local model download or a large Xcode/Android SDK update, when you need headroom now and don't want to hand-audit ~/Library/Developer yourself.
Auditing what your AI coding tools are actually costing you in disk, if you've adopted three or four agentic editors (Cursor, Windsurf, Claude Code) plus a local-inference setup and have never actually measured the aggregate footprint.
Archiving side projects you're not actively shipping via Project Hibernation instead of leaving node_modules folders rotting on disk indefinitely or deleting a repo you might want back.
Onboarding a new machine or doing periodic hygiene as a Homebrew-adjacent habit — run Quick Clean monthly the way you'd run brew cleanup.

Limitations the launch page doesn't emphasize

macOS only. No Windows, no Linux — which quietly excludes a large share of backend and DevOps engineers who don't touch a Mac.
No public source code, for a tool whose entire function is deleting files based on internal path tables you can't inspect.
The AI-model-weights ambiguity described above — the page doesn't clearly separate "cache that regenerates in seconds" from "multi-gigabyte download that doesn't."
Thin, self-reported social proof. The five Product Hunt launch-day quotes and the 5.0-star in-app rating are both drawn from small samples (the star rating explicitly comes from 13 total ratings); treat both as early signal, not a verdict.
Solo-maintainer risk. One person, three products, no visible team. That's not a criticism of the software's current quality, but it's a real bus-factor consideration for anything you'd want long-term support on.
The headline "23.7 GB of build artifacts" claim on the landing page is DevCleaner's own marketing number, not an independently measured average — treat it as an anchor for what's possible on a heavy dev machine, not a guarantee of what you'll personally reclaim.

Competitive comparison

Tool	Scope	Dev-toolchain awareness	Price	Open source
DevCleaner	Dev caches + AI tool caches, project hibernation	High — 23 ecosystems, risk-tiered	Free core / $29 lifetime Pro	No
CleanMyMac	Whole-system cleanup	Low — treats most folders as generic junk	Subscription	No
DaisyDisk	Visual disk-usage mapping	None — shows you what's big, doesn't judge safety	One-time purchase	No
OmniDiskSweeper	Visual disk-usage mapping	None	Free	No
k-angama/macOS-dev-cache-cleaner	Dev caches (Xcode, Gradle, CocoaPods, npm/Yarn/Bun, browsers, design apps, workspaces)	Moderate — fixed category list, transparently documented	Free	Yes

The open-source alternative is the most useful comparison point precisely because it's transparent about exactly what it touches — its cache-path tables live in a single readable Swift file — at the cost of not covering AI tool caches or offering anything like Project Hibernation. If auditability matters more to you than breadth or polish, that trade is worth knowing about before you reach for DevCleaner.

Independent read

DevCleaner is a well-scoped, honestly priced utility solving a real and growing problem — and the growing part is the actual news here. Developer machines in 2026 don't just accumulate Xcode and Gradle cruft anymore; they accumulate Cursor indexes, Claude Code session data, and locally-hosted model weights, and general Mac cleanup tools have no idea any of that exists. DevCleaner shipping scanners for .claude, .cursor, Codex, and Ollama within weeks of each other in July 2026 is a decent signal that a solo maker is tracking where developer disk usage is actually heading, faster than the incumbents in the category are.

The trust question is the real open issue, and it's not really about DevCleaner specifically — it's structural to the category. A closed-source app with delete permissions on your home directory asks for a kind of trust that a documented risk model and warm launch-day quotes can gesture at but not fully substitute for. That's a reasonable trade for most people cleaning up Gradle caches. It's a less obviously reasonable trade the moment "delete" extends to a 40GB model you'd have to re-download on a slow connection, and the product page doesn't yet draw that line as clearly as its own safety-tier framework implies it should.

Who should try it, wait, or skip it

Try it now if you're a Mac-based developer running multiple heavyweight toolchains (Xcode plus Node plus Docker plus a couple of AI coding agents) and you want a fast, free way to see the aggregate damage before deciding what to delete by hand.

Wait if you're specifically trying to manage local LLM model storage — until DevCleaner's page explicitly states the risk tier it assigns to Ollama/LM Studio weights, do that cleanup manually and only let DevCleaner touch the classic build caches.

Skip it if you're not on macOS, if closed-source software with filesystem-delete access is a hard no for your threat model, or if your disk problem is general clutter rather than developer-specific — in which case a visual tool like DaisyDisk or a system-wide cleaner is the better fit.

Given how quickly the scanner list has grown to cover AI coding tools, the more interesting question by year-end might not be whether DevCleaner is worth using today, but whether "AI tool cache management" becomes its own recognized subcategory the way "dev cache cleaner" barely exists as one right now.

What's actually eating your disk in 2026 — is it still classic build artifacts, or have local model weights and agentic-editor caches become the bigger line item on your machine?

Sources:

ElectricSQL vs PowerSync vs Zero vs Triplit: Every One of These Sync Engines Has Already Reinvented Itself

Jason Lee — Tue, 11 Aug 2026 06:30:39 +0000

Local-first sync engines have quietly become one of the more consequential infrastructure decisions a web team can make in 2026. Not because the pitch is new — "local reads and writes that feel instant, synced in the background" has been the local-first dream since the Ink & Switch essay popularized it years ago — but because the field of tools claiming to deliver it has matured enough to be a real, load-bearing choice, and unstable enough that picking wrong is expensive.

Four names keep coming up when developers evaluate this space right now: ElectricSQL, PowerSync, Zero from Rocicorp, and Triplit. Every single one of them has already pivoted, rebuilt, or lost its funded team once. That's not a knock — it's the most useful fact about this category, and it's the one most comparison posts skip in favor of feature checklists. This piece covers the checklists too, but the throughline is: you're not just picking an architecture, you're picking a bet on which vendor is still standing behind their sync protocol in eighteen months.

Why this comparison matters right now

Three trends converged to make sync engines a live decision instead of a research curiosity. Collaborative, Figma- and Notion-style UX is now a baseline expectation for SaaS products, not a differentiator — which means "real-time, multi-user, works offline" moved from nice-to-have to table stakes for a much larger set of apps than before. Second, a wave of VC-funded startups built genuinely different answers to the same problem between 2022 and 2025, so there's no longer just Firebase-or-roll-your-own; there are several credible, opinionated products competing for the same integration point in your stack. Third — and this is the part that makes 2026 specifically the moment to care — several of those products have already changed shape under their early adopters, which means the risk profile of this decision is now visible instead of theoretical.

There's also a quieter driver worth naming: AI-assisted coding has made rewriting a data layer cheap enough that developers are willing to try, discard, and re-try a sync engine mid-project in a way that would have been unthinkable when a migration meant weeks of manual plumbing. That changes the calculus — it means more teams are actually evaluating these tools empirically instead of picking one off a landing page and living with the consequences, which is exactly why the production evidence below is more useful now than it would have been two years ago.

The clearest illustration of the vendor-risk problem is a first-hand account from a developer building a real-time, Figma-like collaborative font editor, documented on their blog in March 2026. Their requirements were specific and common: real-time multiplayer editing, tens of thousands of records per project shared across tens of collaborators (not millions), fast local-first writes, and minimal custom sync plumbing. They tried Triplit, then ElectricSQL, then Livestore, then Zero — in that order, over roughly a year — before landing on something that worked, using an AI coding agent to accelerate each rewrite. That's not an outlier story about one indecisive engineer; it's a fairly representative tour of the category, and it's referenced throughout this piece because it's the closest thing to ground truth this space currently has: a builder who actually shipped on each of these, rather than a landing page describing what each one promises.

Their detour through Livestore is worth a beat even though it's not one of the four tools profiled here: Livestore runs largely on Cloudflare's D1 as the backing SQLite store, performed well, and is dogfooded in a real production app called Overtone. It turned out to be a poor fit for the font editor for one specific, architectural reason — Livestore currently models one user to one SQLite instance, which makes sharing data across users workable only with workarounds. That's a useful data point on its own: it's evidence that "sync engine" isn't one problem with four solutions, it's a family of related problems (per-user offline data, cross-user shared data, presence, conflict resolution) and each tool optimizes for a different subset of them. Livestore's per-user model is excellent for Spotify-like apps with lots of private data and little cross-user sharing; it's the wrong tool entirely for a Figma-like app, which is exactly the kind of mismatch a feature table won't surface but a production migration will.

What each tool actually does

ElectricSQL is, as of its current iteration, a read-path sync engine for Postgres. It streams filtered subsets of Postgres tables — called Shapes — to clients over plain HTTP. It deliberately does not sync writes: you build your own API for that, the same way you always have. The pitch is "keep your existing backend, add live-updating reads on top of it," which makes it the lowest-commitment option of the four if you already run Postgres and mostly need read-side reactivity (dashboards, activity feeds, live lists).

PowerSync is full bidirectional sync: server data flows down into a real, persistent SQLite database on the client (web, mobile, or desktop), and client writes flow back up through a local upload queue that a developer wires into their own API. It supports Postgres via logical replication, MongoDB via change streams, and MySQL via binlogs as source databases. The pitch is "your app works completely offline, indefinitely, and syncs cleanly when it reconnects" — a mobile-first promise, and one PowerSync has been iterating on since well before this current wave of competitors existed.

Zero, built by Rocicorp — the team behind the earlier Replicache — takes a query-driven approach. Instead of syncing whole tables or maintaining static sync-rule definitions, you write ordinary-looking queries in your application code, and Zero figures out what needs to be synced into a normalized local datastore to satisfy them. Reads and writes hit that local store first and reconcile with the server in the background, with the server treated as authoritative — it can accept or reject mutations. The pitch is "instant, reactive UI with minimal custom sync plumbing," aimed squarely at web apps built on a modern TypeScript stack.

Triplit bundles sync, a real-time query engine, and the database itself into one package — the "batteries included" option, requiring the least separate infrastructure to get a first prototype running. It ships its own TypeScript-native query and schema API, runs an embedded triple store under the hood, and was explicitly designed so a solo developer could add real-time, offline-capable data to an app without standing up a separate replication service. The catch, covered in detail below, is that the team building it no longer works on it as a funded product.

It's also worth being precise about what "sync engine" excludes here. None of these four tools are general real-time messaging systems (think Pusher or Ably) or CRDT text-editing libraries (think Yjs) — they're specifically about keeping a client-side copy of structured, queryable data consistent with a server-side database, which is a narrower and, for most CRUD-shaped apps, more directly useful problem than generic pub/sub.

How each is actually built

The architectural fork that matters most here isn't features, it's how much of the sync problem each tool is willing to own.

ElectricSQL runs as a standalone Elixir service that connects to Postgres via logical replication, reads the write-ahead log, and serves Shapes to clients over HTTP using long polling. Because it's plain HTTP, Shape data is cacheable by a CDN for fan-out to many clients — a genuinely nice property for read-heavy, high-fan-out apps. There's no mandatory client-side database; data can live as an in-memory materialized map, or you can pair Electric with PGlite, the same team's embeddable Postgres build for the browser, if you want a fuller local Postgres. What Electric conspicuously does not do is decide what happens to a write — that's entirely your API's problem, though the team's own TanStack DB integration tries to soften the DIY write path.

PowerSync runs a separate sync service (self-hosted or via PowerSync Cloud) that also connects via logical replication, but stores its own operational bucket data in a pluggable persistent store (currently MongoDB). On the client, PowerSync maintains a genuine local SQLite database, and writes go into a durable upload queue that your app processes with a developer-defined uploadData() function — so conflict resolution is still your responsibility, but the plumbing for offline durability is handled for you. PowerSync originally organized synced data into "buckets" defined by Sync Rules (parameter queries plus data queries); it has since layered "Sync Streams" on top as a more reusable, parameterized way to define the same thing.

Zero's server-side component replicates from your database and serves a normalized client datastore backed by IndexedDB in the browser. What's different is the authorization model: because what syncs is expressed as a query rather than a static rule or a whole-table shape, per-row access control can be expressed as constraints on those same queries, instead of a separate permissions DSL layered on top. In production use, this reportedly integrates cleanly with Drizzle ORM and keeps the client bundle small — but it ships without built-in multiplayer presence (live cursors, "who's online"), which has to be built as separate infrastructure if your app needs it.

Triplit collapses the sync layer and the database into one embedded, batteries-included system, trading architectural purity for the fastest path from zero to a working real-time prototype.

Client platform coverage is another quiet differentiator worth checking before you commit. PowerSync's SDKs reflect its mobile-first origins, with native support spanning web, iOS/Android, Flutter, React Native, and Kotlin Multiplatform — a direct consequence of the offline-for-hours-or-days use case it was built for. Electric and Zero are, today, primarily JavaScript/TypeScript-and-web-first projects; you can reach mobile through the same web runtime patterns (React Native, Capacitor-style wrappers), but neither has the breadth of native mobile SDKs PowerSync does. If your roadmap includes a native mobile app in the next year, that gap is worth weighing more heavily than any of the sync-protocol differences above it.

What changed — and why it's the real story

This is the part every landing page leaves out, and it's arguably more decision-relevant than any architecture diagram.

ElectricSQL rebuilt itself from the ground up in July 2024. The original ElectricSQL was a CRDT-based, full offline-write system with automatic conflict resolution — a much larger, more ambitious scope. The team found it too complex to make stable and reliable, stopped development on it entirely, and shipped a deliberately smaller "electric-next" (now just "Electric Sync") that dropped CRDTs and, with them, automatic write-conflict resolution. If you adopted Electric before mid-2024 expecting offline writes to just work, that promise no longer exists in the current product.

Rocicorp's Zero is literally attempt number three at this problem from the same team, following Replicache's mutator-and-rebase model (conceptually similar to git rebase: local mutations apply optimistically, then get replayed on top of whatever the server says is canonical). Replicache is being superseded by Zero, which is a reasonable evolution — but it means anyone who built on Replicache is on a product whose own creators have moved on to a different architecture.

Triplit's shift is the sharpest one. In October 2025, Supabase announced that Triplit co-founder Matt Linkous was joining Supabase — explicitly described as bringing his offline-first expertise to help Supabase build third-party integrations with, notably, Electric, Zero, and PowerSync (i.e., Triplit's own competitors), not to fold Triplit into the Supabase product. Supabase's own framing is worth reading carefully: the stated plan is to further open-source the Triplit codebase and document what they learned, but there's no funded team shipping Triplit going forward. It's now community-maintained. That's the acquihire pattern familiar from other categories, applied here for the first time to a sync engine developers were building production apps on.

PowerSync's change is smaller in comparison — Sync Rules evolving into the newer Sync Streams abstraction — but it's a real API surface change for anyone who adopted the earlier model, and a reminder that even the most "mature" option in this group is still actively reworking its core abstractions.

Put the four side by side and a pattern emerges that no single vendor's changelog will state outright: nobody in this category has shipped a stable, unchanged core abstraction for more than about two years. That's not necessarily a red flag — it's a young category still finding its shape, and rapid iteration is how PowerSync earned its "most mature" reputation in the first place. But it does mean "which architecture is best" is the wrong first question. The better first question is "how much of my application logic is expressed in this tool's abstractions, and how painful is it if those abstractions change again" — which is precisely the question the font-editor migration account above answers empirically, four times over, in a single project.

Why developers should actually care

Cost. Electric and PowerSync both offer a genuine open-source, self-hostable path plus a metered managed cloud service, so cost scales with usage and you retain an exit option. Zero's hosting story is younger and less turnkey — most teams currently self-host the zero-cache replication service themselves. Triplit's cost calculus changed overnight in October 2025: there's no vendor cloud tier backed by a funded company to lean on, so the real cost is now internal engineering time to maintain and patch it yourself.

Latency and DX. This is where the production account matters most: the same developer who found Electric's long-polling transport "slow and brittle" in practice, and its DIY write path "an uphill battle" even with TanStack DB's help, found Zero's local-first reads/writes "basically flawless" after a migration, with a notably small client footprint. That's one data point, not a benchmark suite — but it's a real production comparison, which is more than most vendor pages offer.

Lock-in. All four of these tools embed themselves deep in your data layer: your ORM choice, your permission model, and often your write-path shape all end up coupled to the sync engine's opinions. Migrating later is not a config change — the account referenced throughout this piece did it four times in about a year, using an AI coding agent to accelerate the rewrite each time, and it still cost real calendar time.

Security. Electric's Shapes are, functionally, an HTTP endpoint serving filtered rows — which means access control has to be deliberately designed into how you define and gate each Shape (the project ships a dedicated Auth guide for exactly this reason); getting it wrong risks over-broad data exposure, especially since Shape responses are CDN-cacheable by design. PowerSync and Zero push more of the authorization decision through logic you control on the write path and, for Zero, through the query definitions themselves.

Maintainability. The single biggest maintainability risk in this category right now isn't a bug — it's vendor continuity. Triplit is the cautionary tale, but Electric's own 2024 rebuild shows that even actively-funded teams will drop major architectural promises (CRDT-based offline writes) if they can't make them reliable at scale. Concretely, that risk shows up as work: when the font-editor developer walked away from Electric after roughly two months of trying to make the DIY write path and long-polling transport perform acceptably, and later migrated a working Zero integration into place "shortly" with an AI coding agent doing much of the mechanical translation, the lesson wasn't "AI makes migrations free" — it was that the choice of engine still determined whether that two months was spent on your product or on fighting your infrastructure. A maintainability-conscious pick is one where, if the vendor disappears tomorrow, the abstraction you're left holding is simple enough to maintain yourself; that argument favors Electric's narrower scope and PowerSync's longer track record over Zero's younger, more ambitious surface area and Triplit's now-orphaned one.

Practical use cases

ElectricSQL fits teams with an existing Postgres-backed app who want incremental, low-commitment live reads — dashboards, activity feeds, collaborative-but-mostly-read views — without touching their existing write API. The project's own demos (an agentic system called "Burn," and a project-management app called "Linearlite") both lean into this read-heavy pattern paired with PGlite.
PowerSync fits mobile and field-work apps that must function with zero connectivity for extended periods — logistics, healthcare, industrial — where a team can accept running a dedicated sync service in exchange for the most battle-tested offline story of the four.
Zero fits TypeScript-first web teams building new collaborative SaaS from scratch, especially those already using Drizzle, who want instant local reads and writes without hand-building a caching layer, and who are willing to build presence/multiplayer cursor infrastructure separately.
Triplit fits prototypes, hackathons, and small internal tools where getting to a real-time demo fast matters more than a five-year support horizon — with the explicit expectation that you may need to migrate off it later.

The limitations marketing tends to omit

Electric's "simple, Postgres-native" pitch is real, but "simple" is doing a lot of work — it's simple because it refuses to own your write path or your conflict resolution at all, which is a very different promise from "handles sync for you." PowerSync's "most mature" positioning is earned, but that maturity comes bundled with the most infrastructure to operate: a separate sync service, a pluggable storage backend to run, and a rules/streams DSL to keep in sync with your schema. Zero's "instant, reactive" story is credible in early production use, but it's the youngest of the four in the field, has no built-in presence layer, and its self-hosting story is less proven than PowerSync's. Triplit's "full-stack, batteries-included" copy predates October 2025 and, as of this writing, doesn't foreground that the founding team has moved on to work on integrations at a different company.

Comparison table

Dimension	ElectricSQL	PowerSync	Zero	Triplit
Sync direction	Read-only (server → client)	Bidirectional	Bidirectional	Bidirectional
Client storage	In-memory map, or PGlite for full local Postgres	Real local SQLite	Normalized store over IndexedDB	Embedded database
Write path	Your own API — Electric doesn't touch writes	Local upload queue → your `uploadData()` → your API	Server-authoritative mutators; server can accept/reject	Built into the database itself
Conflict resolution	N/A (no write sync)	Developer-implemented	Server-authoritative reconciliation	Built-in
Source databases	Postgres (logical replication)	Postgres, MongoDB, MySQL	Postgres-based replication	Self-contained
Transport	HTTP long polling, CDN-cacheable	Persistent sync service connection	Continuous background sync	Internal protocol
Backend to run	Elixir Electric service	PowerSync sync service + storage backend	`zero-cache` replication service	None separate — it's embedded
Hosting options	Self-host (OSS) or Electric Cloud	Self-host (OSS) or PowerSync Cloud	Mostly self-hosted today	Self-hosted / community only
Team/backing (2026)	Actively funded, rebuilt core once (2024)	Actively funded, longest track record	Actively funded, Rocicorp's third attempt	Founders acquihired by Supabase (Oct 2025); community-maintained
Best fit	Postgres shops adding live reads incrementally	Offline-critical mobile/field apps	New TypeScript web apps wanting instant local UX	Fast prototypes, low long-term commitment

An independent read

Strip away the marketing and the single most predictive variable in this comparison isn't sync protocol elegance — it's how much of the hard problem (writes, conflicts, offline durability) each tool is actually willing to own, and how stable the team behind that ownership has proven to be. Electric's honesty about not owning writes is refreshing but means you're still building a real system yourself. PowerSync owns the most and has the track record to back the claim, at the cost of running more infrastructure. Zero is the most ambitious technically — collapsing sync into ordinary queries is a genuinely elegant idea — but it's asking you to bet on a young product from a team that has now built three different sync engines, which cuts both ways: they've learned a lot, and they've also walked away from two previous approaches. Triplit is no longer a fair fight; treat anything you build on it today as disposable.

Who should pick what

If you already run Postgres, mostly need live-updating reads, and can live with hand-rolling (or TanStack-DB-assisting) your write path — ElectricSQL. If you're shipping to field workers or mobile users who need the app to keep working with no connectivity for hours or days, and your team can operate an extra service — PowerSync. If you're a TypeScript-first web shop starting fresh, want the least custom sync code, and are comfortable building presence features yourself on a newer stack — Zero. If you're prototyping, demoing, or building something you expect to rewrite within a year regardless — Triplit is genuinely fine, just don't put it on your production critical path without budgeting for that rewrite.

None of these are wrong choices in the abstract. They're different bets on who does the hard work — you, the vendor, or nobody — and, as of 2026, on which of these vendors is still around to help when it breaks.

Discussion: If you've shipped a real app on one of these — or migrated between them like the developer referenced above — what actually broke in production that the docs didn't warn you about: the conflict resolution, the auth model, the ops burden of running the sync service, or something else entirely?

Sources:

Your AI Coding Agent Ships Fast. Coldtea Bets You Need Something Watching What It Breaks.

Jason Lee — Tue, 11 Aug 2026 03:35:28 +0000

Your AI coding agent can now ship a feature in the time it takes you to get coffee. That's the pitch every agentic IDE has been selling for the past year. Coldtea launched on Product Hunt this week with a different pitch: fine, but who's watching what it just shipped? It landed at #1 Product of the Day with 517 upvotes, which by Product Hunt standards is a strong but not runaway result — enough to prove the question resonates, not enough on its own to prove the answer is right.

I went through the product page, docs, pricing, the Product Hunt launch thread, and a competitive comparison from a rival QA vendor to figure out whether "self-driving software delivery" is a real category or a repackaging of tools that already exist.

What happened

Ohans Emmanuel, Coldtea's maker, launched the product this week with a specific framing: the AI coding tools market has spent two years optimizing for how fast an agent can write code, and almost no time on what happens after that code ships. Coldtea's answer is to bundle three things that are normally three separate tools into one local environment: a multi-agent terminal, a visual QA agent, and an AI production monitor.

That bundling is the actual news here, not any single feature. Terminal-based coding agents (Claude Code, Codex, Cursor's agent mode) are commodity at this point. Visual regression testing exists. Production monitoring exists. What's new is packaging all three around a single premise — that shipping fast without watching the downstream consequences is now the bottleneck, not writing the code.

What it actually does

Coldtea is an agentic IDE that runs locally, next to your repository, with three connected layers:

Terminal and coding agents. You run the coding agents you already use — Claude Code, Codex, or others — in parallel panes with shared context, so one agent's session state is readable by another without manually copying output between them. According to the maker's Product Hunt comments, the terminal runs your actual login shell, preserving your existing aliases, PATH, and environment — there's reportedly nothing to configure to get standard shell behavior. Agents in different panes can message each other, which the maker points to as useful for a reviewer-agent/implementer-agent split.

Visual QA agents. These drive your real, running application — not a mocked component tree — across iOS, Android, and web, and are meant to catch visual and behavioral regressions before a human or a user does. This is the layer meant to replace (or sit alongside) manual click-through QA after an agent-generated PR.

AI production monitoring. After a deploy, monitoring agents watch production and, per the pricing page, can investigate incidents and open a pull request describing what broke, in plain language, rather than just paging someone with a stack trace.

How it's built

The core design choice is co-location: Coldtea runs on your machine next to the repo, not as a separate SaaS dashboard you check after the fact. That matters for the workflow it's targeting — the visual QA and monitoring agents aren't bolted onto a CI pipeline as an afterthought, they share the same environment and, per the product's framing, the same context as the coding agents that generated the change in the first place.

This is architecturally different from the two most obvious alternatives. Playwright-based agent tooling generates standard, selector-bound test code that a coding agent can write but that a human then has to maintain when the UI changes. BrowserUse does LLM-driven exploration without pre-authored scripts, which is useful for smoke tests but is explicitly nondeterministic — not something you gate a CI pipeline on. Coldtea's visual QA agents sit closer to the second model (agent-driven, not script-authored) but are scoped specifically to regression detection tied to a shipped change, not open-ended exploration.

What changed vs. the alternatives

Before a tool like this existed, the realistic options for a team using AI coding agents were: write and maintain Playwright/Cypress tests by hand (or have the agent write them, then maintain them by hand anyway), bolt on a separate visual-regression tool like Applitools for screenshot diffing, and handle production monitoring with a conventional APM tool that has no idea an AI agent just shipped the change that caused the incident.

Coldtea's bet is that stitching those three together, with shared context about what the coding agent actually changed, produces a materially better signal than three disconnected tools each looking at a slice of the problem. A production monitor that knows "this error started three minutes after PR #482 merged, which touched the checkout flow" can localize a root cause faster than one that just sees an error rate spike.

Whether that shared-context claim holds up under real production load is not something you can verify from a Product Hunt launch page — it's the single biggest unverified assumption in the pitch, and worth testing directly if you're evaluating this seriously rather than taking the framing at face value.

Why developers should care

If your team has adopted AI coding agents for a meaningful share of PRs, you've likely already run into the actual failure mode Coldtea is targeting: agents are good at producing code that compiles and passes the tests they wrote, and much less reliable at knowing whether the resulting UI still looks and behaves the way a human expects. That gap is currently plugged by manual QA, which does not scale at the rate agents can produce PRs — so either QA becomes the bottleneck, or teams ship with less scrutiny than they used to and find out about regressions from users.

The cost and lock-in questions matter here more than the feature list. Coldtea doesn't replace your coding agent — it runs alongside Claude Code or Codex, which means adopting it isn't an either/or decision against tools you've already standardized on. That's a materially lower-risk adoption path than a tool that wants to replace your existing agent.

Practical use cases

A team shipping multiple agent-generated PRs a day that currently has no visual regression coverage at all, relying purely on unit/integration tests plus manual spot-checks before release.
A solo builder or small team that wants production monitoring with plain-language root-cause hints tied to recent deploys, without standing up a full observability stack.
Teams running multiple coding agents in parallel (e.g., a reviewer agent and an implementer agent) who want shared terminal context instead of manually relaying output between sessions.

Limitations the launch page doesn't emphasize

Credit-based pricing adds a variable cost on top of your existing agent spend. The free tier gives 2,000 agentic credits a month (~200 test runs), and a web QA run costs 10 credits while a mobile run costs 100 — meaning mobile-heavy test suites burn through the free tier roughly 10x faster than web-only ones. Serious usage likely means the $120/month Agentic Testing Pro add-on (10,000 credits, ~1,000 runs) on top of the $20/user Pro plan, which is a real recurring cost most teams evaluating "AI speeds up development" pitches don't initially budget for.

The nondeterminism problem doesn't fully disappear. Visual QA agents that "drive your real app" rather than run fixed scripts inherit some of the same nondeterminism tradeoff that BrowserUse-style exploratory testing has — useful for catching regressions a human would notice, riskier as a hard CI gate compared to Playwright's deterministic, selector-bound approach. Coldtea doesn't publish flake-rate data, so this is a claim to verify in your own evaluation, not something to take on faith.

Production monitoring opening pull requests automatically is powerful and also a new trust surface. An AI system that both watches production and can open a PR in response to what it finds is a meaningfully different risk profile from a passive alerting tool — worth scoping permissions carefully rather than granting broad merge or auto-deploy rights out of the gate.

It's genuinely new (launched this week), with a Product Hunt vote count in the hundreds, not thousands. That's a fine signal of initial interest, not evidence of production-hardening at scale. Early adopters should expect the rough edges that come with a week-old product, not the maturity of a tool with years of production usage behind it.

Competitive context

	Coldtea	Shiplight AI	Playwright + agent	BrowserUse	Applitools
Scope	Coding agents + visual QA + prod monitoring, bundled	Agent-authored intent-based tests	Agent-generated deterministic scripts	LLM-driven exploratory testing	Visual regression (screenshot diff) only
Test authorship	Agent-driven, tied to your coding agent's changes	Agent-authored YAML, git-native	Agent-generated, human-maintained	None — live exploration	Human-authored, AI-assisted comparison
CI-gate suitable	Not clearly established (no flake data)	Yes — self-healing intent tests	Yes — deterministic	No — explicitly nondeterministic	Yes — for visual-only checks
Production monitoring	Included, can open PRs	Not offered	Not offered	Not offered	Not offered
Entry price	Free (2,000 credits/mo); Pro $20/user + usage	Free; Pro $60/mo	Free, open source	Free (LLM cost only)	Quote-based, free trial

The honest read: Coldtea is the only one of these bundling production monitoring with QA, which is a genuinely different value proposition than any single-purpose competitor. But if you specifically need a hard, deterministic CI gate today, Shiplight's self-healing intent-based tests or plain Playwright are the more proven choice — Coldtea's visual QA layer hasn't published the reliability data to make that same claim yet.

Decision framework

Try it this week if you're already running Claude Code or Codex heavily, have no visual regression coverage at all, and want to see whether the shared-context claim between coding, QA, and monitoring agents actually reduces the time to root-cause a regression. The free tier is genuinely usable for evaluation — 200 web test runs a month costs nothing.

Wait if you need CI-gating reliability today and can't tolerate flaky visual checks blocking merges — there's no published flake-rate data to evaluate that claim against yet, so treat any CI-gate use as provisional until you've measured it yourself.

Budget for it explicitly, don't assume it's a rounding error if you're mobile-heavy — 100 credits per mobile run versus 10 for web means mobile test suites will hit paid tiers fast.

Scope the production-monitoring PR permissions narrowly regardless of team size — an agent that can both diagnose production and open a PR in response is worth a deliberate permissions review, not a default "grant everything" setup.

Would you trust an AI monitoring agent to open a PR in response to a production incident it diagnosed itself, or does that specific capability need a human in the loop before it ships more broadly?

Sources: