DEV Community: stack_versus

Supabase vs Firebase: How the Two Backends Compare (2026)

stack_versus — Sat, 22 Aug 2026 00:05:11 +0000

A feature-by-feature and pricing comparison of two hosted app backends, based on each vendor's own documentation as of July 29, 2026.

Supabase and Firebase both give developers a hosted backend so you can ship an app without standing up your own servers. Each bundles a database, user authentication, file storage, serverless functions, and realtime updates behind a single dashboard and a set of client libraries.

Where they part ways is the foundation. Supabase builds every project on a Postgres relational database and, per its documentation, is open source with a self-hosting option. Firebase, part of Google, centers on Firestore and its Realtime Database and folds in a wide suite of mobile-focused services such as analytics, crash reporting, and messaging. This comparison lays out what each vendor documents today, where the real trade-offs sit, and how to pick based on your project.

At a glance

In short

Short version: Both are hosted backends with authentication, storage, functions, and realtime. Choose Supabase for a Postgres/SQL foundation, open-source portability, and built-in vector search; choose Firebase for Firestore's document model and Google's deep mobile tooling (analytics, Crashlytics, A/B testing, messaging). Supabase posts fixed plan tiers from $0 to $599/month, while Firebase bills by usage with a $300 new-account credit (as of 2026-07-29).

Head to head

Key differences side by side.

Feature	Supabase	Firebase
Database model	Full Postgres relational database on every project, with SQL and Row Level Security (as of 2026-07-29)	Firestore and Realtime Database (document-oriented), plus a SQL Connect product (as of 2026-07-29)
Open source & self-hosting	Documented as open source; self-hosting guide provided (as of 2026-07-29)	Not covered on the pages we read (2026-07-29)
Authentication	Built-in Auth with Row Level Security and multiple providers (as of 2026-07-29)	Authentication with multiple identity providers; Phone Number Verification (as of 2026-07-29)
Serverless functions	Edge Functions, globally distributed (as of 2026-07-29)	Cloud Functions (as of 2026-07-29)
File storage	Storage integrated with Postgres and Row Level Security (as of 2026-07-29)	Cloud Storage (as of 2026-07-29)
Realtime updates	Realtime data sync and database change streams (as of 2026-07-29)	Realtime Database; Cloud Messaging (as of 2026-07-29)
AI / vector search	Built-in pgvector to store, index, and search embeddings (as of 2026-07-29)	Firebase AI Logic and generative AI products (as of 2026-07-29)
Instant data APIs	Auto-generated REST and GraphQL APIs (as of 2026-07-29)	Not covered on the pages we read (2026-07-29)
Mobile app operations (analytics, crash reporting, A/B testing)	Not covered on the pages we read (2026-07-29)	Google Analytics, Crashlytics, A/B Testing, Remote Config, Performance Monitoring, Test Lab (as of 2026-07-29)
Web/app hosting	Not covered on the pages we read (2026-07-29)	Hosting and App Hosting (as of 2026-07-29)
Free starting tier	$0/month Free plan: 500 MB database, 50,000 monthly active users, 1 GB file storage (as of 2026-07-29)	$300 credit for new billing accounts; free service allowances published on Firebase's pricing page (as of 2026-07-29)
Migration guides from the other platform	Guides for migrating from Firebase Auth, Firebase Storage, and Firestore (as of 2026-07-29)	Not covered on the pages we read (2026-07-29)

Supabase and Firebase: the public release and download record on 2026-07-28

Measured on 2026-07-28	Supabase supabase/supabase-js · @supabase/supabase-js	Firebase firebase/firebase-js-sdk · firebase
Latest release — GitHub REST API	v2.111.0, published 2026-07-28	firebase@12.15.0, published 2026-06-16
Commits, weekly average — GitHub REST API	12.4 a week (149 commits in the 12 weeks to 2026-07-28)	8.2 a week (99 commits in the 12 weeks to 2026-07-28)
Most recent commit — GitHub REST API	2026-07-28	2026-07-28
Downloads from npm, last 30 days — npm registry download API	89,614,029 (2026-06-25~2026-07-24)	35,004,307 (2026-06-25~2026-07-24)

As observed on 2026-07-28, the npm package registry recorded 89,614,029 downloads of @supabase/supabase-js over the preceding 30 days against 35,004,307 for firebase, while the two projects' public GitHub source repositories showed weekly commit averages of 12.4 and 8.2 respectively across the twelve weeks ending that same date. The download totals come from a package registry and the commit rates from public source repositories, not from either vendor's own status page, so they measure distribution volume and development cadence rather than anything a reader directly experiences. For someone weighing the two libraries, the figures reasonably suggest that Supabase's client is currently being installed and changed at a higher rate, which can point to active maintenance and present momentum. They do not, however, establish reliability, quality of support, or overall product quality, and they do not show how many people actually use either product, since registry downloads are inflated by automated builds, mirrors and reinstalls and commit counts say nothing about the value of what was changed.

Where these numbers come from: on 2026-07-28 (2026-07-28T16:34:36Z) we called the public endpoints listed below and recorded what they returned. Nothing here is taken from either vendor's marketing pages, and anyone can repeat the same calls. Repository figures describe the named repository — for a closed-source platform that is its official CLI or SDK, not the platform itself. What these figures do not tell you: Commit counts include merges, dependency bumps and documentation changes, and a monorepo will always show more commits than a single-purpose repository, so this measures how busy the named repository is — not progress, quality, or how much of it reaches the product. The commit date says the repository is being worked on, nothing about what changed. Downloads count installs by machines — CI runs and mirrors included — so they track how widely a package is pulled, not how many people use the product. None of them measures reliability, support or how either product feels to use.

Supabase — GitHub REST API · GitHub releases API · npm registry · the official JavaScript client library
Firebase — GitHub REST API · GitHub releases API · npm registry · the official JavaScript SDK

The core difference: data model and openness

Supabase's site is explicit that every project is a full Postgres database, the relational engine that speaks SQL and enforces access rules through Row Level Security (supabase.com, as of 2026-07-29). You get tables, joins, constraints, and the wider Postgres extension ecosystem, including pgvector for storing and searching embeddings.

Firebase's documented data stores are Firestore and the Realtime Database, both organized around documents and collections rather than SQL tables (firebase.google.com, as of 2026-07-29). Firebase also lists a SQL Connect product, so the platform is not limited to one model. The practical effect is that a document model like Firestore tends to favor flexible, denormalized reads, while Postgres favors structured, relational queries with joins and constraints.

Openness is the other axis. Supabase's documentation covers self-hosting, and its site describes the platform as open source, which gives you the option to run the stack on your own infrastructure rather than staying on a managed provider. If avoiding a single-vendor dependency matters to you, that portability is worth weighing.

Feature matrix

Coverage summary of the table below — counted from the same rows.

Feature	Supabase	Firebase
Managed database — Supabase: Postgres (relational). Firebase: Firestore and Realtime Database (document). Both as of 2026-07-29.	✅	✅
Authentication — Both list built-in auth with multiple identity providers (as of 2026-07-29).	✅	✅
Serverless functions — Supabase Edge Functions; Firebase Cloud Functions (as of 2026-07-29).	✅	✅
File storage — Supabase Storage; Firebase Cloud Storage (as of 2026-07-29).	✅	✅
Realtime data — Supabase Realtime; Firebase Realtime Database (as of 2026-07-29).	✅	✅
Built-in vector / AI features — Supabase pgvector; Firebase AI Logic (as of 2026-07-29).	✅	✅

✅ full · 🟡 partial/paid · ❌ not supported

Features side by side

Both platforms cover the backend basics. Supabase lists built-in Authentication with Row Level Security, Edge Functions for server-side code, Storage for large files, Realtime data sync, and instant REST and GraphQL data APIs (supabase.com and supabase.com/docs, as of 2026-07-29). Firebase lists Authentication with multiple identity providers, Cloud Functions, Cloud Storage, its Realtime Database, and Cloud Messaging (firebase.google.com, as of 2026-07-29).

Firebase's catalog leans heavily into app operations beyond the database. Its site groups a set of run-time products that includes Google Analytics, Crashlytics, A/B Testing, Remote Config, Performance Monitoring, In-App Messaging, App Distribution, and Test Lab (firebase.google.com, as of 2026-07-29). If your priority is shipping and instrumenting a mobile app, that breadth of built-in analytics and quality tooling is a meaningful draw.

Supabase, for its part, publishes migration guides for teams coming from Firebase Auth, Firebase Storage, and Firestore, alongside guides for Postgres-family sources such as Amazon RDS, Neon, and Heroku (supabase.com/docs, as of 2026-07-29). Client libraries are documented for JavaScript, Flutter, Python, C#, Swift, and Kotlin.

Pricing

Prices below were checked against each vendor's official pricing page on 2026-08-12. Vendors change pricing without notice — the linked page is authoritative.

Supabase Free$0/month (as of 2026-07-29)

500 MB database size
50,000 monthly active users
1 GB file storage
5 GB egress + 5 GB cached egress
Unlimited API requests
Community support
Free projects paused after 1 week of inactivity; limit of 2 active projects

See Supabase pricingSupabase ProFrom $25/month (as of 2026-07-29)

100,000 monthly active users, then $0.00325 per MAU
8 GB disk per project, then $0.125 per GB
250 GB egress, then $0.09 per GB
100 GB file storage, then $0.0213 per GB
Daily backups retained 7 days; 7-day log retention
Email support
$10/month compute credits (covers one Micro instance); add-ons scale to 64 cores / 256 GB RAM

See Supabase pricingSupabase TeamFrom $599/month (as of 2026-07-29)

Everything in Pro
SOC 2 and ISO 27001
SSO for the Supabase dashboard
Project-scoped and read-only access
Daily backups retained 14 days; 28-day log retention
Priority email support & SLAs
HIPAA available as a paid add-on

See Supabase pricingSupabase EnterpriseCustom (contact sales) (as of 2026-07-29)

Designated support manager
Uptime SLAs
BYO Cloud supported
24x7x365 premium enterprise support
Private Slack channel
Custom security questionnaires

Contact SupabaseFirebase (usage-based)Usage-based; $300 credit for new billing accounts (as of 2026-07-29)

Billed by consumption across services (Firestore, Cloud Functions, Cloud Storage, and more)
$300 credit for a new billing account to try features
Per-service rates and free allowances are published on Firebase's pricing page
Estimate cost from your own reads, writes, storage, and function calls

Visit Firebase

Pricing: what each vendor publishes

Supabase posts fixed monthly plan tiers and adds usage-based compute on top. The Free plan is $0/month and includes a 500 MB database, 50,000 monthly active users, 1 GB of file storage, and 5 GB of egress; free projects are paused after a week of inactivity, and you can keep two active projects (supabase.com/pricing, as of 2026-07-29).

The Pro plan starts at $25/month, with 100,000 monthly active users included (then $0.00325 per extra user), 8 GB of disk per project, 250 GB of egress, daily backups retained for 7 days, and email support. Paid plans include $10/month in compute credits that cover one Micro instance, and compute add-ons scale up to 64 cores and 256 GB of RAM. The Team plan starts at $599/month and adds SOC 2 and ISO 27001, dashboard SSO, 14-day backup retention, and priority support with SLAs; Enterprise is custom-quoted (all figures supabase.com/pricing, as of 2026-07-29).

Firebase bills on a usage model and gives new billing accounts $300 in credit to explore its features (firebase.google.com, as of 2026-07-29). Its per-service rates are published on Firebase's pricing page. Because Firebase charges by how much of each product you consume, the fair way to compare cost is to estimate your own reads, writes, storage, and function calls and price them there against Supabase's posted tiers.

Which should you choose?

If your app is relational at heart, if you want SQL and Row Level Security, or if the option to self-host and stay portable matters, Supabase fits that shape. Its documented pgvector support also makes it a straightforward pick when you need to store and search embeddings for AI features.

If you are building a mobile app and want analytics, crash reporting, A/B testing, and messaging wired in from the same console, Firebase's breadth of app-operations tooling is the stronger match, especially if you are already invested in Google's ecosystem. Firestore's document model also suits apps that need flexible records that sync across clients.

Many teams can succeed on either. When the decision is close, let the data model lead: Postgres and Supabase for structured, relational workloads, and Firestore and Firebase for document-oriented, mobile-first apps. Estimate cost against your own usage rather than a headline number.

Migration and lock-in

Switching costs are worth thinking about before you commit. Supabase publishes migration guides specifically for moving from Firebase Auth, Firebase Storage, and Firestore, which lowers the effort of moving in that direction (supabase.com/docs, as of 2026-07-29). Because Supabase is documented as open source with a self-hosting guide, you also keep the option to run the stack yourself rather than staying on the managed service.

Moving data between a document store and a relational schema is not automatic in either direction. You will typically remodel collections into tables (or the reverse) and rewrite queries, so budget engineering time for the remodel regardless of which way you go.

Pros & cons

SupabasePros

Every project is a full Postgres relational database with SQL and Row Level Security (supabase.com, as of 2026-07-29)
Documented as open source with a self-hosting option (supabase.com/docs, as of 2026-07-29)
Built-in pgvector for storing and searching embeddings
Auto-generated REST and GraphQL APIs
Fixed plan tiers posted up front, from a $0 Free plan to a $599/month Team plan (supabase.com/pricing, as of 2026-07-29)
Migration guides for teams coming from Firebase Auth, Storage, and Firestore

Cons

Free projects are paused after a week of inactivity and capped at two active projects (supabase.com/pricing, as of 2026-07-29)
Total cost combines a plan tier with usage-based compute add-ons, so scaling spend takes estimation
A relational model means document-style data has to be modeled into tables, which can be a shift for teams used to a document database

FirebasePros

Firestore and Realtime Database offer a flexible, document-oriented model that syncs across clients (firebase.google.com, as of 2026-07-29)
Broad app-operations suite in one console: Google Analytics, Crashlytics, A/B Testing, Remote Config, Performance Monitoring, Cloud Messaging, Test Lab (firebase.google.com, as of 2026-07-29)
Part of Google's ecosystem, with $300 credit for new billing accounts to start
Documented products span build and run: Authentication, Cloud Functions, Cloud Storage, Hosting, App Hosting, Extensions, Firebase AI Logic

Cons

Usage-based billing across services means cost depends on consumption and takes per-workload estimation
Per-service rates live across Firebase's pricing page rather than a single flat plan tier, so budgeting requires modeling reads, writes, storage, and function calls
A document data model requires remodeling if you later move to a relational/SQL system

Verdict

There is no single winner here, because the two platforms optimize for different foundations. The selection criteria used are data-model fit, ecosystem and tooling, openness and portability, and posted pricing.

Pick Supabase when you want a relational Postgres database with SQL and Row Level Security, when open source and a self-hosting escape hatch matter, or when you need pgvector-backed embeddings for AI features. Its plan pricing is posted up front, from a $0 Free tier to a $599/month Team tier, with usage-based compute on top (supabase.com/pricing, as of 2026-07-29).

Pick Firebase when you are shipping a mobile-first app and want Firestore's document model together with Google Analytics, Crashlytics, A/B Testing, Remote Config, and Cloud Messaging in one console (firebase.google.com, as of 2026-07-29). Price it against your expected per-service usage using Firebase's pricing page. For structured, relational, or portability-sensitive projects, Supabase is the more natural home; for instrumented mobile apps inside Google's ecosystem, Firebase is.

FAQ

Is Supabase or Firebase free?

Both offer a no-cost way to start. Supabase has a $0/month Free plan with a 500 MB database, 50,000 monthly active users, and 1 GB of file storage, though free projects pause after a week of inactivity and are capped at two active projects (supabase.com/pricing, as of 2026-07-29). Firebase gives new billing accounts $300 in credit to try its features, and its ongoing free service allowances are listed on Firebase's pricing page (firebase.google.com, as of 2026-07-29).

Is Supabase a drop-in replacement for Firebase?

Not automatically. They use different data models (Postgres tables versus Firestore documents), so moving requires remodeling data and rewriting queries. Supabase does publish migration guides for Firebase Auth, Firebase Storage, and Firestore to ease that path (supabase.com/docs, as of 2026-07-29).

Which is better for a mobile app?

Firebase documents a broad set of mobile-focused services in one console, including Google Analytics, Crashlytics, A/B Testing, Cloud Messaging, and Test Lab (firebase.google.com, as of 2026-07-29), which many mobile teams value. Supabase can back a mobile app too and provides client libraries for Flutter, Swift, and Kotlin (supabase.com/docs, as of 2026-07-29); the choice often comes down to whether you want that built-in app-operations tooling.

Can I self-host either one?

Supabase's documentation includes a self-hosting guide and describes the platform as open source, so you can run the stack on your own infrastructure (supabase.com/docs, as of 2026-07-29). Firebase's deployment and hosting model was not covered on the pages we read, so consult Firebase's own documentation for its options.

Sources

Originally published at https://utilverse.info/compare/supabase-vs-firebase-which-backend-platform-should-you-choose-in-2026/.

Which Open-Source Notion Alternatives Are Actually Being Developed? AppFlowy vs AFFiNE (2026)

stack_versus — Fri, 21 Aug 2026 00:28:00 +0000

A practical look at two of the most-starred open-source Notion alternatives, AppFlowy and AFFiNE, and how to read their public GitHub signals to judge which are still under active development.

Plenty of projects call themselves "the open-source Notion alternative." Fewer stay under steady development once the initial excitement fades, and an abandoned repository is a real risk if you plan to build a workspace, a wiki, or a team knowledge base on top of it. The good news is that development activity is one of the few things you can check yourself, in public, before committing.

This comparison focuses on the two most-starred contenders on GitHub, AppFlowy (AppFlowy-IO/AppFlowy) and AFFiNE (toeverything/AFFiNE), and reads their repository signals as observed on 2026-08-21. The question is not which has the nicer feature list; it is which one shows the clearer evidence of ongoing work.

At a glance

In short

Short answer (as of 2026-08-21): Of the two most-starred open-source Notion alternatives, AFFiNE shows the clearer signs of active development — a live canary branch with continuing commits and the larger commit history (11,465 commits on its GitHub repository). AppFlowy is a large, established project (75.8k stars), but its recent commit cadence had slowed to roughly 9 commits across the trailing 52 weeks, with its latest commit dated 2026-08-11 and 103 pull requests open. Treat AppFlowy's "active" status as check-before-you-depend-on-it rather than a flat yes. If a still-actively-developed project is your deciding factor, AFFiNE is the safer pick today; verify both on GitHub on the day you decide.

Pros & cons

AppFlowyPros

Very large community: 75.8k stars and 5.9k forks on GitHub as of 2026-08-21
Cross-platform via Flutter and Rust, with native desktop builds (macOS, Windows, Linux) and mobile apps listed on the App Store and Play Store
Publishes a ROADMAP.md and a public roadmap
AGPL-3.0 licensed with self-hosting documented in the repository

Cons

Recent commit cadence on GitHub had slowed to roughly 9 commits over the trailing 52 weeks, with the latest commit dated 2026-08-11 (as of 2026-08-21)
Carried 103 open pull requests and 896 open issues as of 2026-08-21
Its "actively developed" status is marginal on recent-activity signals; verify current activity before you depend on it

AFFiNEPros

Active canary development branch with ongoing commits
Larger commit history: 11,465 total commits on GitHub as of 2026-08-21
Documents Docker-based self-hosting in the README
Lists both a LICENSE and a LICENSE-MIT file; 71.7k stars as of 2026-08-21

Cons

The repository listing showed no roadmap file as of 2026-08-21
The pages we read did not cover native mobile apps
Carried 106 open pull requests and 605 open issues as of 2026-08-21

52 weeks of commits, week by week (measured 2026-08-21)

Repository	2025-08-22 → 2025-11-21	2025-11-21 → 2026-02-20	2026-02-20 → 2026-05-22	2026-05-22 → 2026-08-21	52-week total
AppFlowy	7	0	1	1	9
AFFiNE	135	206	237	185	763
Outline	325	432	537	719	2,013
Docmost	61	116	191	73	441
SiYuan	1,121	1,213	1,303	3,995	7,632

Reading each project's public GitHub statistics endpoint on 2026-08-21, we tallied weekly commit counts over the same trailing 52 weeks for every row: SiYuan logged 7,632 commits in that span while AppFlowy logged just 9, with the others between them (Outline 2,013, AFFiNE 763, Docmost 441). The shape over time is as telling as the totals — Outline and SiYuan trended upward into the most recent 13-week window (Outline 325→432→537→719; SiYuan's latest quarter alone reaching 3,995), whereas AppFlowy's activity was near-dormant and Docmost's most recent quarter (73) fell back below its peak. For someone deciding whether to build on one of these tools, a steady or rising cadence with a recent commit suggests the code is still being actively maintained and is less likely to be abruptly abandoned, which matters most for security fixes and issue response. It establishes none of the things a user actually cares about, however: commit volume is not a measure of code quality, of meaningful progress rather than churn, of how many people run the software, or of whether any given project will still exist a year from now.

Weekly commit counts for the last 52 weeks, from each repository's own GitHub statistics endpoint, grouped into four 13-week windows. Every repository is measured over the same 52 weeks, so the columns are directly comparable. Commit counts include merges, dependency bumps and documentation edits, and a monorepo will always show more commits than a single-purpose repository — this measures how busy a repository is, not progress, quality, or how much of the work reaches users. Collected by this site on 2026-08-21 (2026-08-21T00:12:28Z) by calling the public APIs ourselves — 15 of 15 requests returned data. These are our own readings, not figures supplied by any vendor.

How to judge whether an open-source project is still being developed

Star counts tell you a project was once popular. They do not tell you whether anyone is still shipping code. To answer "is this actually being developed," a few public signals on the GitHub repository page carry more weight:

Recent commit cadence. A single fresh commit is reassuring, but the trailing-year rhythm matters more. GitHub's activity view shows roughly how many commits landed over the last 52 weeks.
Latest commit date. When was the most recent change merged into the default branch?
Active development branch. Some projects do their live work on a branch such as canary or main; a moving branch is a healthy sign.
Open pull requests versus merges. A large stack of open pull requests that is not being cleared can indicate maintenance has slowed.
Roadmap and changelog. A published roadmap or changelog signals ongoing planning.

None of these is decisive on its own. Read them together, and check them yourself on the day you decide, because activity can change quickly.

AppFlowy: a large community with a slowing recent cadence

AppFlowy is one of the best-known projects in this space. Its GitHub repository showed 75.8k stars, 5.9k forks and 7,210 total commits as of 2026-08-21, and it is licensed under AGPL-3.0. It is built with Flutter and Rust, ships desktop builds for macOS, Windows and Linux, and lists native mobile apps on the App Store (iPhone) and the Play Store (Android). The repository also carries a ROADMAP.md file and links to a public roadmap.

The caution is in the recent rhythm. On the AppFlowy GitHub repository page on 2026-08-21, the trailing-52-week activity was light — on the order of nine commits over the last year — with the most recent commit dated 2026-08-11. At the same time the repository listed 103 open pull requests and 896 open issues. A big historical codebase plus a fresh commit is not the same as steady, continuous development, so AppFlowy's "active" status is better treated as "verify before you depend on it" than a flat yes.

AFFiNE: an active development branch and a heavier commit history

AFFiNE shows the stronger set of development signals. Its GitHub repository listed 71.7k stars, 5.2k forks and 11,465 total commits as of 2026-08-21, and it does its live work on a canary branch that showed ongoing commit activity. The repository includes its BlockSuite editor framework alongside a TypeScript codebase, and it also carries Rust tooling (Cargo.toml, Cargo.lock and a rust-toolchain file). On licensing, the repository lists both a LICENSE and a LICENSE-MIT file. Self-hosting is documented in the README, which describes deploying your own instance with Docker.

By the signals that matter for the "still being developed" question — a moving development branch, the larger commit history, and continuing recent commits — AFFiNE reads as actively developed. As of 2026-08-21 it listed 106 open pull requests and 605 open issues.

AppFlowy vs AFFiNE: development signals side by side

The comparison table sets the two repositories against each other on the signals a reader would use to answer the query. A few notes on how to read it: a higher star count reflects popularity rather than development, so those rows are left unscored; commit totals and recent cadence speak more directly to whether work is ongoing. Where the pages we read did not cover something for one product, that cell is marked "Not covered on the pages we read" and left unscored rather than counted against either side.

The pattern that emerges is consistent. AFFiNE leads on the activity-focused rows (total commits and recent cadence), while AppFlowy leads on published planning artifacts (a roadmap file) and lists native mobile apps that the AFFiNE pages we read did not cover.

What both projects share

Both are open-source and self-hostable, which is the reason people look at them as Notion alternatives in the first place. AppFlowy is distributed under AGPL-3.0 and documents self-hosting in its repository; AFFiNE lists a LICENSE and a LICENSE-MIT file and documents Docker-based self-hosting in its README. Both also mix a scripting/UI layer with Rust: AppFlowy pairs Flutter with Rust, while AFFiNE's repository includes Cargo and rust-toolchain files alongside its TypeScript and BlockSuite code. If your priority is owning your data on your own infrastructure, either project supports that path as documented on their repository pages on 2026-08-21.

Verdict

Both AppFlowy and AFFiNE are substantial, open-source, self-hostable Notion alternatives, and both have historically large codebases. But the question here is narrow: which is actually being developed right now. On that measure the two are not equivalent as of 2026-08-21.

AFFiNE answers the question with a clearer yes. Its repository showed a live canary development branch with ongoing commits and the larger overall commit history (11,465 commits). If continued active development is the deciding factor, it is the safer choice today.

AppFlowy is harder to score. It has the bigger community and a public roadmap, and it did receive a recent commit (2026-08-11). Yet its trailing-52-week cadence had thinned to roughly nine commits while 103 pull requests sat open, which is a slowdown rather than a stop. Do not assume it is being maintained at the same pace as AFFiNE; check the AppFlowy GitHub repository's recent activity before you build on it. Because activity on both projects can shift week to week, treat this as a snapshot and re-check the commit history on GitHub on the day you commit.

FAQ

Is AppFlowy still being actively developed?

As of 2026-08-21, AppFlowy's GitHub repository showed a recent commit dated 2026-08-11, but its trailing-52-week cadence had slowed to roughly nine commits, with 103 open pull requests and 896 open issues. That points to a large, established project whose recent development has thinned rather than stopped, so it is worth checking the repository's current activity before you depend on it.

Is AFFiNE actively maintained?

By the public signals on its GitHub repository as of 2026-08-21, yes: it does live work on a canary branch that showed ongoing commits and has the larger commit history of the two (11,465 total commits). Development activity can change, so re-check the repository on the day you decide.

Can I self-host both AppFlowy and AFFiNE?

Both document a self-hosting path on their repository pages as of 2026-08-21. AppFlowy includes a self-hosting section in its repository, and AFFiNE's README describes deploying your own instance with Docker. Both are open-source: AppFlowy under AGPL-3.0, and AFFiNE lists a LICENSE and a LICENSE-MIT file.

Which should I choose if I want the one most likely to keep shipping updates?

On recent-development signals as of 2026-08-21, AFFiNE is the stronger bet because of its active canary branch and larger, continuing commit history. AppFlowy remains a viable option with a bigger community and a public roadmap, but confirm its current commit cadence on GitHub first.

Sources

Originally published at https://utilverse.info/compare/which-open-source-notion-alternatives-are-actually-being-developed-appflowy-vs-affine-2026/.

PlanetScale vs Neon: Managed Database Platforms Compared (2026)

stack_versus — Thu, 20 Aug 2026 00:14:37 +0000

How PlanetScale's Postgres-and-Vitess performance play compares with Neon's serverless, agent-ready Postgres, with current pricing and features as of 2026-07-29.

PlanetScale and Neon are both fully managed cloud database platforms that speak PostgreSQL, yet they were built around different bets. PlanetScale pairs managed Postgres with Vitess, the MySQL-compatible, horizontally sharded engine created at YouTube, and runs both on locally-attached NVMe storage. Neon is serverless Postgres, now a Databricks company, that autoscales with traffic and ships a set of application and agent primitives around the database.

The figures and features here come from each vendor's own documentation and pricing pages and reflect what those pages showed on 2026-07-29. Every price or limit is dated and traceable to the page it came from. Pricing on both platforms changes, so verify the current numbers on the vendor sites before you commit.

At a glance

In short

Both PlanetScale and Neon are managed, PostgreSQL-compatible database platforms with branching, but they solve different problems. Choose PlanetScale if you need a MySQL-compatible Vitess engine with horizontal sharding, locally-attached NVMe performance (Metal), or a high-availability cluster with a 99.99% SLA. Choose Neon if you want serverless Postgres that autoscales with traffic plus bundled app and agent primitives (managed auth, functions, object storage, and an AI Gateway). Prices and features cited are as of 2026-07-29.

Head to head

Key differences side by side; the stronger option is tinted green.

Feature	PlanetScale	Neon
Database engines offered	PostgreSQL and MySQL-compatible (Vitess)	Serverless PostgreSQL
Horizontal sharding / scale-out engine	Vitess horizontal sharding across many nodes via VTGate	Not covered on the pages we read (2026-07-29)
Scaling model	Choose a cluster size; autoscaling storage on the EBS option	Advanced automatic compute autoscaling with traffic
Database branching	Branching, deploy requests, non-blocking schema changes	Instant branching
Storage architecture	Local NVMe (Metal, marketed as unlimited IOPS) or network-attached EBS	Storage-compute separation (Lakebase architecture)
High availability	1 primary + 2 replicas across 3 AZs; 99.99% SLA on HA config	Not covered on the pages we read (2026-07-29)
Bundled app primitives (auth, functions, object storage, AI gateway)	Not covered on the pages we read (2026-07-29)	Managed auth, serverless functions, S3-compatible object storage, AI Gateway
Bring-your-own-cloud / deployment	Multi-tenant, single-tenant, or your own AWS/GCP (PlanetScale Managed, Enterprise)	Not covered on the pages we read (2026-07-29)
Agent / MCP tooling	MCP support; agent-based optimization messaging	MCP, AI Gateway, npx neon init, neon inspect db
Starting price (self-serve)	Postgres single node from $5/mo; Metal from $50/mo (2026-07-29)	Not covered on the pages we read (2026-07-29)
Company / backing	PlanetScale (maintainers of Vitess)	A Databricks company

PlanetScale and Neon: the public release record on 2026-07-28

Measured on 2026-07-28	PlanetScale planetscale/cli	Neon neondatabase/neonctl
Latest release	v0.307.0, published 2026-07-24	v2.27.0, published 2026-06-22
Commits, weekly average	18.8 a week (225 commits in the 12 weeks to 2026-07-28)	10.8 a week (129 commits in the 12 weeks to 2026-07-28)
Most recent commit	2026-07-27	2026-06-23

In the twelve weeks to 2026-07-28, PlanetScale's command-line client averaged 18.8 commits a week while Neon's neonctl averaged 10.8, figures taken from each project's public source repository on GitHub, where the commit history is openly readable; those same repositories recorded PlanetScale's latest release, v0.307.0, published 2026-07-24, against Neon's v2.27.0 from 2026-06-22, with the Neon tool additionally distributed through the npm package registry. Read together, these values observed on 2026-07-28 suggest that, over this window, the PlanetScale client saw more frequent and more recent development activity than the Neon client, which someone weighing the two tools might treat as a rough indication of maintenance pace. They establish nothing beyond that: they are not a measure of reliability, support responsiveness, or product quality, and they say nothing about how many people actually use either tool.

Where these numbers come from: on 2026-07-28 (2026-07-28T16:45:14Z) we called the public endpoints listed below and recorded what they returned. Nothing here is taken from either vendor's marketing pages, and anyone can repeat the same calls. Repository figures describe the named repository — for a closed-source platform that is its official CLI or SDK, not the platform itself. What these figures do not tell you: Commit counts include merges, dependency bumps and documentation changes, and a monorepo will always show more commits than a single-purpose repository, so this measures how busy the named repository is — not progress, quality, or how much of it reaches the product. The commit date says the repository is being worked on, nothing about what changed. None of them measures reliability, support or how either product feels to use.

PlanetScale — GitHub REST API · GitHub releases API · the official command-line client, measured instead of the serverless driver so both sides are the same kind of tool
Neon — GitHub REST API · GitHub releases API · the official command-line client, measured instead of the serverless driver so both sides are the same kind of tool

PlanetScale and Neon at a glance

PlanetScale presents itself as a high-performance relational database platform. According to planetscale.com (2026-07-29), it offers two engines, PlanetScale Postgres and Vitess (MySQL-compatible), both running on locally-attached NVMe drives that the company markets as delivering "unlimited IOPS" and ultra-low latency. Every cluster is deployed with one primary and at least two replicas across three availability zones for high availability.

Neon describes itself as "the Postgres backend designed for apps and agents" (neon.com, 2026-07-29). It is serverless Postgres with storage-compute separation, which Neon calls its Lakebase architecture, plus advanced autoscaling, instant branching, and instant restore. Around the core database, Neon bundles managed authentication, serverless functions, S3-compatible object storage that branches, and an AI Gateway for calling multiple models through one API. Neon is a Databricks company.

In short, PlanetScale leans toward raw performance and horizontal scale-out, including MySQL through Vitess, while Neon leans toward a serverless Postgres platform with bundled application and agent primitives, aimed at app and agent developers.

Feature matrix

Coverage summary of the table below — counted from the same rows.

Feature	PlanetScale	Neon
Managed PostgreSQL	✅	✅
Database branching — PlanetScale documents branching plus deploy requests and non-blocking schema changes; Neon markets instant branching (as of 2026-07-29).	✅	✅
Autoscaling — Neon advertises advanced compute autoscaling; PlanetScale's pricing page describes autoscaling storage on its EBS option (2026-07-29).	🟡	✅
MCP / agent integration — Both expose Model Context Protocol; Neon adds an AI Gateway and CLI/agent tooling (2026-07-29).	✅	✅
Self-serve sign-up (no sales call) — PlanetScale's Base plan requires no contract or sales interaction; Neon offers self-serve sign-up and one-command setup (2026-07-29).	✅	✅

✅ full · 🟡 partial/paid · ❌ not supported

Database engines and scaling

The engine choice is the clearest dividing line. PlanetScale supports both PostgreSQL and MySQL through Vitess. Vitess scales MySQL horizontally with explicit sharding, distributing data across many nodes behind a single connection routed through a component called VTGate. PlanetScale states that Vitess was built at YouTube to scale MySQL to petabytes on 70,000 nodes across 20 data centers, and that it now powers databases at Slack, GitHub, HubSpot, Etsy, and Block, among others (planetscale.com, 2026-07-29). For workloads that outgrow a single large instance, that horizontal-sharding path is PlanetScale's signature capability.

Neon's page centers on serverless PostgreSQL that scales automatically. Neon advertises advanced autoscaling that sizes instances up and down with load, along with the ability to scale and restore multi-terabyte databases quickly (neon.com, 2026-07-29). Its architecture separates storage from compute, which is what makes instant branching and autoscaling possible.

The practical read: choose PlanetScale when you need a MySQL-compatible engine or explicit horizontal sharding, and choose Neon when you want Postgres that expands and contracts with traffic without hands-on instance sizing.

Branching, autoscaling, and agent tooling

Database branching appears on both sides. It lets you spin up isolated copies of a database for development, testing, or CI. PlanetScale documents branching alongside deploy requests, query insights, and non-blocking schema changes for its engines (planetscale.com/docs, 2026-07-29). Neon markets instant branching and instant restore as central to its developer workflow (neon.com, 2026-07-29).

Autoscaling is where the scope differs. Neon advertises advanced autoscaling of compute that adjusts automatically to traffic. PlanetScale's pricing page describes autoscaling storage on its Amazon EBS option, with IOPS and bandwidth configurable in the app, while compute capacity is set by choosing a cluster size (planetscale.com/pricing, 2026-07-29).

Both vendors are courting AI and agent developers. Each supports the Model Context Protocol (MCP) for connecting agents to the database. On its homepage Neon adds an AI Gateway, one-command setup with npx neon init, and a neon inspect db helper for debugging from an agent or CLI, positioning itself as designed for apps and agents. PlanetScale's messaging highlights using agents to optimize and shard databases (neon.com and planetscale.com, 2026-07-29).

Pricing

Prices below were checked against each vendor's official pricing page on 2026-08-12. Vendors change pricing without notice — the linked page is authoritative.

PlanetScale Postgres — Single node (Base)From $5/mo (as of 2026-07-29)

Development and low-traffic production workloads
Resource-based Base plan; upsize or downsize anytime, no sales call
100 GB egress included, then $0.06/GB

PlanetScale pricingPlanetScale Postgres — High Availability (PS-5 example)$15/mo (as of 2026-07-29)

1 primary + 2 replicas across 3 availability zones
PS-5: 1/16 vCPU, 512 MB memory, 10 GB storage per node (3 nodes)
99.99% SLA on the HA configuration
100 GB egress included, then $0.06/GB

PlanetScale pricingPlanetScale MetalFrom $50/mo (as of 2026-07-29)

Locally-attached NVMe drives, marketed as unlimited IOPS
High-performance high-availability clusters
Runs Postgres or Vitess

PlanetScale pricingPlanetScale Vitess (Base)Resource-based, priced by cluster size (as of 2026-07-29)

MySQL-compatible with horizontal sharding for massive scale
Runs on network-attached storage or PlanetScale Metal
Self-serve Base plan

PlanetScale pricingPlanetScale EnterpriseCustom (contact sales)

Bring your own cloud — your AWS or GCP account (PlanetScale Managed)
Migration assistance and private Slack support
Additional regions and architecture consultation
Available via AWS and Google Cloud marketplaces

Contact PlanetScaleNeonFree tier · paid plans are usage-basedLaunch and Scale are pay-as-you-go — compute, storage and transfer metered hourly with no monthly minimum.

Serverless PostgreSQL with autoscaling and instant branching
Bundled managed auth, functions, S3-compatible object storage, and AI Gateway
MCP and agent tooling (npx neon init, neon inspect db)
Specific plan prices and limits are published on Neon's pricing page

Neon pricing

Pricing and plans

PlanetScale publishes resource-based pricing at planetscale.com/pricing. The Base plan is self-serve, with no contract or sales call, and lets you upsize or downsize instances as needed. As of 2026-07-29, PlanetScale Postgres starts at $5/month for a single node aimed at development and low-traffic production. A high-availability example cluster, labeled PS-5 (1/16 vCPU, 512 MB memory, and 10 GB storage per node, three nodes total), is listed at $15/month. Metal, which uses high-performance local NVMe storage, starts at $50/month. Each includes 100 GB of egress bandwidth, with additional egress billed at $0.06/GB. Vitess on the Base plan is priced by cluster size and runs on network-attached storage or Metal.

Bring-your-own-cloud deployments, migration help, private Slack support, additional regions, and architecture consultation sit under PlanetScale's Enterprise plan with custom pricing. PlanetScale is also available on the AWS and Google Cloud marketplaces (planetscale.com/pricing, 2026-07-29).

Neon sets its plan prices on its own pricing page. For current tiers, quotas, and limits, read neon.com/pricing directly. The dollar figures in this section are the ones PlanetScale publishes on its pricing page (2026-07-29); for Neon, its pricing page is the authoritative source for up-to-date amounts.

High availability, storage, and deployment

High availability is built into PlanetScale by default. Every cluster runs one primary plus at least two replicas across three availability zones, with automated failovers and managed version upgrades, and the HA configuration carries a 99.99% SLA (planetscale.com and planetscale.com/pricing, 2026-07-29). Storage comes in two forms: network-attached Amazon EBS with autoscaling storage for smaller, lower-I/O databases, or PlanetScale Metal, which uses locally-attached NVMe drives the company markets as offering unlimited IOPS for its fastest nodes.

For deployment, PlanetScale offers multi-tenant and single-tenant options, and its Enterprise offering, PlanetScale Managed, can run inside your own AWS or GCP account (planetscale.com/docs, 2026-07-29).

Neon's homepage emphasizes instant restore for fast recovery and storage-compute separation as the basis of its serverless model (neon.com, 2026-07-29). Specifics such as its high-availability guarantees, region coverage, and deployment options are not detailed on that homepage, so confirm them in Neon's documentation before you decide.

Pros & cons

PlanetScalePros

Two engines: managed PostgreSQL plus MySQL-compatible Vitess with horizontal sharding for very large workloads
Vitess lineage powers major sites (Slack, GitHub, HubSpot, Etsy, Block) per planetscale.com (2026-07-29)
PlanetScale Metal uses locally-attached NVMe, marketed as unlimited IOPS, for high performance
High availability by default: 1 primary + 2 replicas across 3 AZs, 99.99% SLA on the HA config
Transparent, self-serve Base pricing from $5/mo for Postgres (2026-07-29); Enterprise supports bring-your-own-cloud

Cons

Pricing is tied to provisioned resources; the lowest listed Postgres option is $5/mo and Metal starts at $50/mo (2026-07-29)
Vitess sharding concepts (VTGate, shard keys) are more than a small app needs
Bring-your-own-cloud, migration help, and additional regions require the Enterprise plan and a sales conversation

NeonPros

Serverless PostgreSQL with advanced autoscaling that grows and shrinks with traffic
Instant branching and instant restore for fast dev/test and recovery workflows
Bundled app primitives: managed auth, serverless functions, S3-compatible object storage, and an AI Gateway
Agent-native tooling: MCP support, one-command setup (npx neon init), and neon inspect db
Backed by Databricks

Cons

Built around PostgreSQL; if you specifically need MySQL or Vitess-style horizontal sharding, PlanetScale is the more direct fit
The breadth of bundled primitives can be more surface area than you need if you only want a plain database
Check neon.com/pricing for current tiers, quotas, and limits before committing

Verdict

Pick PlanetScale when your requirements point to a MySQL-compatible engine, horizontal sharding for very large workloads (its Vitess lineage powers GitHub, Slack, and others), locally-attached NVMe performance via Metal, or a high-availability setup with a 99.99% SLA. Its Base plan is transparent and self-serve, starting at $5/month for a single-node Postgres (planetscale.com/pricing, 2026-07-29).

Pick Neon when you want serverless PostgreSQL that autoscales with traffic and a bundled set of primitives around it: managed auth, serverless functions, S3-compatible object storage, and an AI Gateway, with instant branching and a workflow aimed at application and agent developers (neon.com, 2026-07-29).

Because both speak PostgreSQL, a Postgres application can realistically target either platform, which keeps the switching cost between them relatively low. The usual deciding factors are the engine and scale model (Vitess and MySQL sharding versus serverless autoscaling) and how much of the surrounding application stack you want the database vendor to provide. Check the latest pricing and limits on each vendor's site before you commit.

FAQ

Is PlanetScale a MySQL or a PostgreSQL database?

Both. PlanetScale offers PlanetScale Postgres and Vitess, its MySQL-compatible engine with horizontal sharding, per planetscale.com (2026-07-29).

Does Neon support MySQL?

Neon is a serverless PostgreSQL platform (neon.com, 2026-07-29). If you specifically need a MySQL-compatible engine or Vitess-style horizontal sharding, PlanetScale is the more direct fit.

How much does PlanetScale cost?

On the self-serve Base plan, PlanetScale Postgres starts at $5/month for a single node, a high-availability PS-5 example is $15/month, and Metal starts at $50/month, each including 100 GB of egress with additional egress at $0.06/GB (planetscale.com/pricing, 2026-07-29). Enterprise pricing is custom.

Can I move a Postgres app between Neon and PlanetScale?

Both are PostgreSQL-compatible, so a Postgres application can target either platform. PlanetScale also offers hands-on migration assistance on its Enterprise plan (planetscale.com/pricing, 2026-07-29). Confirm version and extension compatibility for your specific app before migrating.

Sources

Originally published at https://utilverse.info/compare/planetscale-vs-neon-which-cloud-database-fits-your-app/.

What Happened to the Small Dev Tool Repositories We Tracked?

stack_versus — Wed, 19 Aug 2026 00:13:52 +0000

A field guide to why a GitHub project goes quiet — archived, transferred, deleted, or made private — and how to read each signal and recover access.

You bookmark a small command-line tool or a niche library, and months later the commits have stopped, the address 404s, or the page now carries a gray "archived" banner. The question behind "what happened to the small dev tool repositories we tracked" is rarely about drama and usually about mechanics: on GitHub, a repository that goes silent is almost always in one of a few defined states, each with its own signature and its own recovery path.

This guide maps those states to what GitHub actually documents. It draws on GitHub's own pages for archiving and transferring repositories (GitHub Docs, observed 2026-08-15), so you can tell a paused-but-preserved project from one that has moved, and know what you can still do with each.

The short version

Before you start

A small dev tool going quiet on GitHub is usually one of four documented states: archived (read-only but still there and cloneable), transferred (moved to a new owner, with the old link automatically redirecting), deleted, or made private. Archival keeps everything readable and searchable; a transfer preserves issues, pull requests, stars, and watchers and redirects old links to the new home. If a moved tool's old owner/name won't host a new repo, that is name retirement blocking reuse of the address — not the project being gone. Details from GitHub Docs, observed 2026-08-15.

What we recorded, and what the same check says on 2026-08-15

Project	What we watched	What we recorded, and when	Same check on 2026-08-15
catnip	`wandb/catnip`	repository returned 404 on 2026-08-06	not found (404)
uzi	`devflowinc/uzi`	no commits recorded as of 2026-08-01	live, last commit 2025-06-04
omnara ↻	`omnara-ai/omnara`	no commits recorded as of 2026-08-01	live, last commit 2026-08-15 ≠
omnara ↻	`omnara-ai/omnara`	commits resumed, seen 2026-08-15	live, last commit 2026-08-15
herdr	`ogulcancelik/herdr`	redirected to herdrdev/herdr, seen 2026-08-01	redirects to herdrdev/herdr; last commit 2026-08-15
goose	`block/goose`	redirected to aaif-goose/goose, seen 2026-08-01	redirects to aaif-goose/goose; last commit 2026-08-14
paneflow	`ArthurDEV44/paneflow`	redirected to arthjean/paneflow, seen 2026-08-01	redirects to arthjean/paneflow; last commit 2026-07-21
catnip	`npm:catnip`	npm name owned by alextewpin/catnip, checked 2026-08-01	npm package points at alextewpin/catnip
uzi	`npm:uzi`	npm name owned by icholy/uzi, checked 2026-08-01	npm package points at icholy/uzi
Sculptor	`npm:sculptor`	npm name owned by twolfson/sculptor, checked 2026-08-01	npm package points at twolfson/sculptor
omnara	`npm:omnara`	npm name owned by omnara/omnara-voice, checked 2026-08-01	npm package points at omnara/omnara-voice
CCManager	`npm:ccmanager`	npm name matches kbwo/ccmanager, checked 2026-08-01	npm package points at kbwo/ccmanager
happy	`npm:happy`	npm name matches slopus/happy, checked 2026-08-01	npm package points at slopus/happy

≠ marks a row where today's check no longer matches what we recorded. Those rows are not errors in the record — they are the record working. ↻ marks a project we logged more than once, at different moments; each row is one log entry, not one request, so a project that changed state appears on more than one row while still being a single repository.

Each comparison here sets one of our own previously logged API responses against the identical call repeated on 2026-08-15: for uzi [devflowinc/uzi] we had recorded "no commits recorded as of 2026-08-01," yet the same check on 2026-08-15 returned "live, last commit 2025-06-04," while for catnip [wandb/catnip] our logged "repository returned 404 on 2026-08-06" was matched by "not found (404)" today. These are not vendor announcements or press reports but raw responses we captured on the stated dates versus the same endpoints queried again on 2026-08-15, and several shifted in between — omnara [omnara-ai/omnara], logged as having "no commits recorded as of 2026-08-01," now returns "live, last commit 2026-08-15." For anyone who depends on small, young projects, the reasonable takeaway is that a repository's reachability, redirect target, and commit activity can each change from one check to the next, so a single reading is a snapshot rather than a durable fact and is worth re-verifying before relying on it. It does not, however, establish why any of these values changed, whether a project that went quiet or returned a 404 was abandoned, or anything about the intentions of any maintainer — only that the two readings, taken on the dates shown, differed.

13 log entries covering 12 distinct repositories and packages. The middle column is our own log: what the GitHub REST API and the npm registry returned when we called them on the date shown, while checking candidates for other articles. The right column is the same call repeated for this article. A 404 does not distinguish a deleted repository from one made private, and a redirect is followed automatically by most clients, which is exactly why moves go unnoticed. Collected by this site on 2026-08-15 (2026-08-15T01:54:29Z) by calling the public APIs ourselves — 11 of 12 requests returned data. These are our own readings, not figures supplied by any vendor.

The four states behind a quiet repository

When a project you follow stops moving, the cause usually falls into one of four buckets, and the page itself gives you the clue:

Archived — the repository is still there, still cloneable, but flagged read-only and marked as no longer actively maintained.
Transferred — ownership moved to another user or organization, and the old address redirects to the new one.
Deleted — the repository was removed by its owner; the address returns a not-found response.
Made private — the code still exists but is no longer publicly visible, so it also reads as "gone" from the outside.

The two states GitHub documents in the most detail are archival and transfer, and they are the two most likely to leave a project looking abandoned when it is actually intact. The sections below work through each.

Archived: read-only, but still there

Archiving is a common and often-benign reason a small tool stops accepting changes. A maintainer archives a repository to make it read-only for all users and to signal that it is no longer actively maintained (GitHub Docs, Archiving repositories, 2026-08-15). It is a status, not a deletion — the code, history, and discussion stay in place.

When a repository is archived, a wide set of its contents becomes read-only at once: issues, pull requests, code, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, code scanning alerts, comments, and permissions (GitHub Docs, Archiving repositories, 2026-08-15). To change any of that, the owner has to unarchive it first.

What can you still do with an archived tool? Contributors with access can fork or star the project, but collaborators and teams can no longer be added or removed while it stays archived (GitHub Docs, Archiving repositories, 2026-08-15). So a fork remains the practical route if you want to keep building on an archived tool. Archived repositories also remain searchable — you can search for them, and for issues and pull requests inside them.

One billing detail is easy to miss: on a legacy per-repository billing plan, an archived repository is still charged unless the account moves to a newer product (GitHub Docs, Archiving repositories, as of 2026-08-15). Archiving pauses activity; it does not automatically pause that legacy cost.

Transferred: the project moved, and the old link follows

The second common reason a tracked tool seems to vanish is a transfer. An owner can transfer a repository to another personal account or to an organization, and the new owner can immediately administer its contents, issues, pull requests, releases, projects, and settings (GitHub Docs, Transferring a repository, 2026-08-15). The name can change during the move as well, which is why a project sometimes reappears under both a new owner and a new name.

The reassuring part for anyone holding old links: after a transfer, all links to the previous repository location are automatically redirected to the new location (GitHub Docs, Transferring a repository, 2026-08-15). A moved repository leaves a working trail back to its old path, so a bookmark or a documentation link generally still lands you on the project — just at its new home.

Plenty else travels with the repository. Its issues, pull requests, wiki, stars, and watchers are transferred too, and the original owner is added as a collaborator on the transferred repository while other collaborators remain in place (GitHub Docs, Transferring a repository, 2026-08-15). A few conditions gate the move: the person transferring needs administrator access, the target account must not already have a repository with the same name or a fork in the same network, and a repository forked from a private upstream network cannot be transferred on its own.

The confirmation step is specific to who receives it. When you transfer a repository you own to another personal account, the new owner gets a confirmation email with instructions for accepting the transfer, and if they do not accept within one day the invitation expires (GitHub Docs, Transferring a repository, as of 2026-08-15). Transfers into an organization instead require permission to create a repository in that organization.

Name retirement: what it actually blocks

Some transfers trigger an extra rule that is often misread as "the old address is dead." It is not that. If a transferred repository contained an action listed on GitHub Marketplace, or had more than 100 clones or more than 100 uses of GitHub Actions in the week before the transfer, GitHub permanently retires that OWNER/REPOSITORY-NAME combination (GitHub Docs, Transferring a repository, as of 2026-08-15).

Retirement is about reuse, not about redirects. It means nobody can create a new repository at that old owner-and-name path: attempting it returns the error "The repository REPOSITORY_NAME has been retired and cannot be reused" (GitHub Docs, Transferring a repository, 2026-08-15). The redirect from the transfer still carries visitors to the project's new location. In effect, retirement protects that trail — because the redirect is only lost if a new repository or fork is created at the old path, and retirement prevents exactly that creation for qualifying, high-traffic tools.

So if a popular small tool moved and its old owner/name now refuses to host a brand-new project, that is retirement doing its job, not evidence the tool disappeared. Follow the redirect and you should still reach it.

How to find out what happened, and recover access

A quick sequence usually resolves the mystery:

Open the old URL and watch the response. A redirect means the project transferred and moved — note the new owner and name. A gray archived banner means it is read-only but intact. A not-found response points to deletion, a rename with no surviving redirect, or a switch to private.
Search GitHub for the name. Archived repositories stay searchable, so a project that archived rather than vanished should still surface (GitHub Docs, Archiving repositories, 2026-08-15).
Check your own clones and forks first. If you already cloned the tool, you hold its full history locally regardless of the upstream state, and a fork keeps a usable copy you can keep developing.
For an archived project you want to extend, fork it — that path stays open even while the original is read-only.

None of these steps depends on the maintainer answering an issue, which matters precisely because archived and transferred repositories restrict or relocate the places you would normally ask.

Bottom line

Most "abandoned" small repositories are not lost — they changed state. Archival makes a project read-only while leaving its code, history, and discussions in place and searchable; you can still fork it to keep building (GitHub Docs, Archiving repositories, 2026-08-15). A transfer moves ownership but carries the issues, pull requests, stars, and watchers along, and old links are automatically redirected to the new location (GitHub Docs, Transferring a repository, 2026-08-15).

Name retirement is the detail most likely to be misread. For qualifying high-traffic or Marketplace tools, GitHub permanently retires the old OWNER/REPOSITORY-NAME so it cannot be reused to create a new repository (GitHub Docs, Transferring a repository, as of 2026-08-15) — which blocks reuse of the address, not the redirect to the project's new home. Practically: open the old URL and read the response, search for the name, and lean on your own clones and forks. That resolves the large majority of tools that merely went quiet.

FAQ

Can I still use a repository that's been archived?

Yes. An archived repository is read-only but fully present — its code, history, releases, and issues stay readable, and you can still fork or star it. To make changes, the owner has to unarchive it first, or you can fork it and continue from your copy (GitHub Docs, Archiving repositories, 2026-08-15).

If a tool moved to a new owner, will my old links break?

Generally no. After a repository is transferred, all links to the previous location are automatically redirected to the new location, so bookmarks and documentation links keep working (GitHub Docs, Transferring a repository, 2026-08-15). The redirect is only lost if a new repository or fork is later created at the old path.

Why does the old owner/name of a moved tool say it's 'retired'?

For a transferred repository that held a GitHub Marketplace action, or had more than 100 clones or more than 100 uses of GitHub Actions in the prior week, GitHub permanently retires that owner-and-name combination so it can't be reused to create a new repository (GitHub Docs, Transferring a repository, as of 2026-08-15). It blocks creating something new at the old address; it does not remove the redirect to the project's new home.

What moves with a repository when it's transferred?

Its issues, pull requests, wiki, stars, and watchers transfer with it, and the new owner can immediately administer the contents, releases, projects, and settings. The original owner is added as a collaborator, and existing collaborators remain (GitHub Docs, Transferring a repository, 2026-08-15).

Sources

Originally published at https://utilverse.info/compare/what-happened-to-the-small-dev-tool-repositories-we-tracked/.

25% of Requests to Our New Site Probed for Software and Files We Do Not Have

stack_versus — Tue, 18 Aug 2026 00:35:40 +0000

We logged 30,644 requests to a static site over 28 days. 7,567 of them asked for WordPress, .env files and PHP shells that have never existed here.

Put a server on the public internet and something will knock on it within the hour. Everyone knows this in the abstract. We had the chance to put a number on it: this site is new, unlinked, and static — no PHP, no database, no admin panel — so anything asking for those is unambiguously a probe.

Over 28 days this domain received 30,644 requests. 7,567 of them — about 25% — were for paths that have never existed here. Below is what they wanted, how often, and what a small site should actually do about it.

The short version

Before you start

Of 30,644 requests over 28 days, 7,567 (25%) targeted software this static site does not run — 1,818 distinct paths from 382 addresses, about 270 a day. 61% arrived with no user agent. Nothing here needs a fix beyond keeping .env and .git out of the web root.

What we measured, and how

This is a static site: pre-rendered HTML files served by nginx. There is no PHP interpreter, no database, no CMS, no admin login. That turns the access log into a clean instrument — every request for a .php file is, by definition, someone probing for software that is not here.

We took every log line for this domain from 2026-07-19 to 2026-08-15 (28 days) — 30,644 requests — and kept the ones where nginx parsed a path and answered not-here (404, plus 403 and 410). From those we removed requests for paths the site does publish — a handful of articles were retired and still get followed: 126 requests. Malformed requests that nginx rejected with a 400 before any path was parsed are excluded too, and reported separately further down. What remains is 7,567 requests for things that never existed here.

Nothing here is a vulnerability report. We are publishing what arrived, not what worked — a static site has almost no attack surface for any of it, which is rather the point of showing it.

25% of all traffic was looking for software we do not run

7,567 of 30,644 requests — about 25% — went to paths that have never existed on this domain. That is roughly 270 per day, spread across 1,818 distinct paths from 382 addresses.

The largest single family was uploaded php shells: 3,934 requests across 814 paths.

This site has no inbound links to speak of and one page in Google's index. Nobody knows it exists. The scanning found it anyway, because scanning does not work by knowing — it works by walking address space and trying everything on everything.

What it was looking for

What it was looking for	In plain terms	Requests	Distinct paths
Uploaded PHP shells	Filenames from earlier break-ins elsewhere	3,934	814
Everything else	Assorted one-off paths	1,537	503
WordPress	A CMS this site does not run	1,084	219
Secrets and config files	Leaked keys, tokens, repository internals	861	244
Admin panels	Database and server consoles	67	8
Remote code execution	Known RCE paths in web frameworks	61	20
Backups and dumps	Whole-site archives left in web roots	23	10

Every request to this domain between 2026-07-19 and 2026-08-15 (28 days) that was answered 404, 403 or 410, excluding paths this site actually publishes. Classification is a fixed set of path patterns applied identically to every request; a path matches the first family it fits.

The most-requested things that are not here

Requested path	Requests
`/wp-admin/install.php`	145
`/wp-content/plugins/hellopress/wp_filemanager.php`	59
`/this_is_a_new_hello_world.php`	57
`/1.php`	44
`/classwithtostring.php`	43
`/222.php`	43
`/.env`	40
`/images.php`	36
`/.git/config`	35
`/media.php`	34
`/admin.php`	34
`/8.php`	34
`/mac.php`	32
`/BDKR28WP.php`	31
`/mgrr.php`	30

The most-requested paths that do not exist here. None of this software runs on this domain — the site is static HTML behind nginx.

Two patterns are worth naming. The WordPress paths are the obvious ones — install scripts, login pages, plugin files — and they arrive whether or not you run WordPress, because guessing is cheaper than checking. The random-looking .php filenames are the more interesting group: those are the names of web shells uploaded during other people's breaches. Scanners try them everywhere on the chance that a host was compromised earlier and the back door is still sitting there.

Then there are the config files. Requests for .env and .git/config are not looking for a way in — they are looking for credentials someone committed by accident. That is a filesystem hygiene problem, not a web-server one, and it is the one item on this list that a static site can still get wrong.

Most of it does not even pretend to be a browser

4,630 of these requests (61%) arrived with no user agent at all. Others carried a user-agent string that was not a user agent — one of the most frequent was a URL, apparently copy-pasted into the wrong field of whatever tool was doing the scanning.

Separately, 3,044 requests were malformed badly enough that nginx answered 400 before any path was parsed — protocol noise, TLS probes, and requests aimed at whatever else might be listening on the port.

None of this is sophisticated, and that is the useful part of the finding. The background traffic of the public internet is not targeted attacks; it is a very large amount of very cheap guessing.

What this changes about running a small site

Do not read 404 counts as a problem with your site. Ours are dominated by software we have never installed. If you set up alerting on 404 rate, you will be alerting on the weather.

The static-site security argument is real, and this is what it looks like. Almost every request above needs an interpreter to be dangerous. There isn't one. That is not cleverness on our part — it is a consequence of the hosting choice, and it is available to anyone.

The exception is files, not code. .env, .git, and stray backups are readable by a static server as happily as any other file. Keeping them out of the web root is the one defence on this list that a static site still has to get right on purpose.

Look before you buy tooling. This measurement cost one log file and an afternoon. Whatever a WAF vendor tells you about your threat profile, your own access log has already recorded the answer.

Bottom line

The practical conclusion is smaller than the numbers suggest. A quarter of our traffic is looking for a way in and almost none of it has any effect, because there is nothing on the other side to execute it. If you are choosing between a static site and a CMS for a small project, this is the security half of that trade-off made concrete.

The part that does deserve attention is the file-based probing. Nobody is going to break into a folder of HTML, but a stray .env in the web root is readable by anyone who asks — and, as the table above shows, they ask constantly.

FAQ

Is any of this dangerous to a static site?

Almost none of it. Requests for PHP files, admin panels and RCE paths need code execution to matter, and a static server has none. The exception is requests for files — .env, .git, backups — which a static server will serve happily if they are in the web root. Keep them out of it.

Why is a site nobody knows about being scanned at all?

Scanners do not work from a list of known sites. They walk IP ranges and certificate transparency logs and try common paths on whatever answers. Obscurity is not a filter — being reachable is the only qualification.

Should I block these requests?

Blocking costs effort and buys little when the requests already return 404 instantly. Rate-limiting is worth it if the volume affects your logs or bandwidth. The higher-value work is making sure nothing sensitive is reachable in the first place.

Do these numbers apply to my site?

The composition probably does; the volume depends on your host and address range. The measurement is three lines of log parsing, so check rather than assume — that is the whole argument of this article.

Sources

Originally published at https://utilverse.info/compare/what-actually-knocks-on-a-brand-new-static-site/.

How Actively Are Self-Hosted Analytics Tools Maintained? How to Check for Yourself

stack_versus — Mon, 17 Aug 2026 00:39:08 +0000

A practical guide to judging whether a self-hosted analytics project is still actively developed, using the public signals every open-source repository exposes.

If you are planning to self-host your website analytics, maintenance activity is one of the first things worth checking. A tool you run on your own server needs security patches, dependency updates and bug fixes to stay safe and useful, and an open-source project that has gone quiet leaves you carrying that burden alone.

The good news is that maintenance activity is not a matter of guesswork. Open-source analytics tools are developed in public, so the same signals a developer uses to judge any repository apply here: how recently code was committed, how often releases ship, how many issues and pull requests are open, and how the project handles the split between its hosted service and its self-hostable edition. This guide walks through those signals and reads them against a live example, Plausible Analytics, using figures observed on its GitHub repository on 2026-08-17.

The short version

Before you start

Maintenance activity is easy to verify because open-source analytics tools develop in public. Read the releases feed, recent commits, and open issues and pull requests together rather than trusting any single number. As a live example, Plausible's GitHub repository showed roughly 28.6k stars, 4,352 commits, 24 open issues and 32 open pull requests as of 2026-08-17; its README states the hosted cloud updates multiple times per week while the self-hostable Community Edition ships as a long-term release twice per year. Watch for the split between the fast-moving hosted service and the slower stable self-hosted edition, which is normal and does not mean a project is neglected.

52 weeks of commits, week by week (measured 2026-08-17)

Repository	2025-08-18 → 2025-11-17	2025-11-17 → 2026-02-16	2026-02-16 → 2026-05-18	2026-05-18 → 2026-08-17	52-week total
Plausible	189	116	190	138	633
Umami	333	374	482	341	1,530
Matomo	154	186	245	323	908
PostHog	3,453	4,552	7,437	13,241	28,683

On 2026-08-17 we queried each project's public GitHub statistics endpoint ourselves and tallied weekly commit counts across the same 52 weeks, binned into four 13-week windows. Over that span PostHog's repository logged 28,683 commits — rising window over window from 3,453 to 13,241 — while Plausible recorded 633 and Umami 1,530, and Matomo's 908 climbed steadily from 154 to 323 in the most recent quarter. For someone weighing whether to depend on one of these tools, that shape is a rough signal of ongoing maintenance activity and its trend: all four show commits within the last few days of the 2026-08-17 snapshot, and none has visibly stalled. It says nothing, however, about code quality, whether those commits represent real progress or churn, how many people actually run the software, or whether any of these projects will still be maintained a year from now — commit volume also reflects team size and workflow, so the raw counts are not comparable as a measure of effort.

Weekly commit counts for the last 52 weeks, from each repository's own GitHub statistics endpoint, grouped into four 13-week windows. Every repository is measured over the same 52 weeks, so the columns are directly comparable. Commit counts include merges, dependency bumps and documentation edits, and a monorepo will always show more commits than a single-purpose repository — this measures how busy a repository is, not progress, quality, or how much of the work reaches users. Collected by this site on 2026-08-17 (2026-08-17T00:31:57Z) by calling the public APIs ourselves — 12 of 12 requests returned data. These are our own readings, not figures supplied by any vendor.

What "actively maintained" means for a self-hosted tool

For software you host yourself, maintenance covers more than new features. The things that matter most are security fixes, updates to underlying dependencies, and compatibility with current database and runtime versions. A project can look feature-complete and still be risky to run if nobody is shipping patches when a vulnerability is disclosed.

There is also a distinction that trips people up. Many analytics tools offer a paid hosted service alongside a free self-hostable edition, and the two often move at different speeds. The hosted version can receive changes continuously while the self-hosted build is cut into stable releases at a slower, predictable cadence. Both can be actively maintained even though the version you install lags behind what runs on the vendor's cloud.

The GitHub signals that reveal maintenance activity

Because these projects develop in the open, you can assess them without installing anything. When you open a repository, look for the following.

Recent commits and total commit count. The date of the most recent commit tells you whether work is ongoing right now. A high lifetime commit count shows sustained effort over the years.
Release cadence. Check the releases feed for how regularly tagged versions ship. This is the version you would actually deploy, so its rhythm matters more than raw commit noise.
Open issues and pull requests. An active project usually has a steady flow of both. A large backlog is not automatically bad; it often reflects an engaged user base. What you want to see is that issues and pull requests are being triaged and merged, not left untouched.
Contributor breadth and stars. Stars and forks indicate community interest, while the mix of contributors hints at whether the project depends on a single person or has a broader base.
Security policy. A published security policy and a channel for reporting vulnerabilities signal that the maintainers take patching seriously.

No single number settles the question. Read several together, and weight the release feed and recent commits most heavily.

A worked example: reading Plausible's repository

Plausible Analytics is a good project to practise on because its repository is public and busy. On its GitHub page as of 2026-08-17, the repository showed about 28.6k stars and 1.8k forks, with 4,352 commits recorded against the master branch (github.com/plausible/analytics). At that same observation, the issues tab listed 24 open issues and the pull requests tab listed 32 open pull requests.

Read those together and a picture forms. The commit total reflects years of sustained work; the copyright notice on the repository runs from 2018 to the present (github.com/plausible/analytics, as of 2026-08-17), which lines up with a project that has been developed steadily rather than abandoned. A live flow of open issues and pull requests points to ongoing triage and contribution rather than a dormant codebase.

The project also documents its own release rhythm, which is the single most useful maintenance signal for a self-hoster. According to the repository's README (as of 2026-08-17), the hosted Plausible Analytics Cloud is "continuously developed and improved with new features and updates multiple times per week," while the self-hostable Plausible Community Edition is described as "a long term release published twice per year so latest features and improvements won't be immediately available."

Why the cloud and self-hosted editions move at different speeds

The gap between those two cadences is deliberate, and understanding it will save you from misreading a healthy project as a slow one. A twice-yearly stable release for the self-hostable edition does not mean development has stalled; it means the maintainers batch continuous work into long-term releases that are meant to be dependable on your own server.

Plausible's README is explicit that the self-hosted Community Edition is a free, community-supported build, and that some capabilities are held back from it. As of 2026-08-17, the README lists marketing funnels, ecommerce revenue goals, SSO and the sites API as premium features that are not included in the Community Edition, which the project frames as a way to support its long-term sustainability. When you evaluate any self-hosted analytics tool, separate two questions: is the project actively maintained, and does the free self-hostable edition include the specific features you need. A project can score well on the first while still gating features you want behind the paid tier.

Why maintenance matters more for privacy-focused analytics

Analytics software sits in the request path of every page on your site and processes visitor data, so staleness carries real consequences. Outdated dependencies can turn into security exposure, and compliance expectations shift over time. Plausible positions itself as a privacy-first, cookie-free tool and states in its README that it is compliant with GDPR, CCPA and PECR (github.com/plausible/analytics, as of 2026-08-17). Claims like those only hold if someone keeps the code current as regulations and browsers evolve, which is exactly why maintenance activity is not a cosmetic concern for this category.

There is a data-portability angle too. The README notes that self-hosting gives you direct access to the raw data in the underlying ClickHouse database (as of 2026-08-17). That control is valuable, and it also means the responsibility for backups, upgrades and security rests with you, so choosing a well-maintained upstream project reduces how much of that burden you inherit.

How to check any self-hosted analytics tool before you commit

Run the same short checklist against any candidate before you deploy it.

Open the releases feed first. Confirm that tagged releases ship on some regular cadence and that a recent one exists.
Scan recent commits. A repository with commits in the last days or weeks is being worked on now.
Sample the open issues and pull requests. Look for maintainer replies and merged pull requests, which show the project is responsive.
Find the security policy. A documented way to report vulnerabilities is a sign the project is run responsibly.
Confirm the license and the edition split. Check which license governs the code and whether the free self-hostable edition covers the features you actually need.

You can apply this method to more than one project. Plausible's repository is at github.com/plausible/analytics, and Umami, another open-source, self-hostable analytics tool, keeps its repository at github.com/umami-software/umami; open each one and read the same signals side by side before deciding what to run.

Bottom line

You do not have to take a vendor's word for how actively its analytics tool is maintained, because the evidence is public. The most reliable read comes from the release feed, the date and volume of recent commits, and the flow of open issues and pull requests, judged together rather than one at a time. Weight the release cadence highest, since that is the version you will actually install.

Plausible works well as a reference point. As of 2026-08-17 its GitHub repository carried 4,352 commits and about 28.6k stars, with 24 open issues and 32 open pull requests, and its README documents a hosted edition updated multiple times per week alongside a self-hostable Community Edition released twice per year. Expect that same two-speed pattern from other tools in this space, treat a slower stable self-hosted cadence as normal, and always confirm separately that the free self-hostable edition includes the features you need before you commit a server to it.

FAQ

Is Plausible Analytics actively maintained?

The public signals point that way. As of 2026-08-17 its GitHub repository showed about 28.6k stars, 4,352 commits, 24 open issues and 32 open pull requests, and its README describes a hosted cloud updated multiple times per week and a self-hostable Community Edition released twice per year (github.com/plausible/analytics).

How often does the self-hosted version of Plausible get updated?

According to its GitHub README as of 2026-08-17, the self-hostable Plausible Community Edition is a long-term release published twice per year, so new features that appear on the hosted cloud are not immediately available in the self-hosted build.

Does an open-source license tell you whether a project is maintained?

No. A license describes the legal terms for using, modifying and redistributing the code. Whether developers are still shipping changes is a separate question, and you answer it from the release feed, recent commit dates, and the flow of merged pull requests.

Which signals should I check first when evaluating a self-hosted analytics tool?

Start with the releases feed to see whether tagged versions ship regularly, then scan recent commits for current activity, then sample open issues and pull requests to confirm maintainers are responding. Finish by checking the security policy, the license, and which features the free self-hostable edition actually includes.

Sources

Originally published at https://utilverse.info/compare/how-actively-are-self-hosted-analytics-tools-maintained-how-to-check-for-yourself/.

How Active Are Agent Sandbox Tools? Reading 52 Weeks of Commits

stack_versus — Sun, 16 Aug 2026 00:38:00 +0000

A practical guide to reading a coding-agent sandbox project's commit history: what GitHub's 52-week graph shows, what the repository's total count does not, and which signals to check alongside it.

Ask how active an open-source coding-agent sandbox is, and the quickest answer people reach for is a commit count. GitHub keeps a year-long view of that history one click away, on a repository's Insights tab and in the contribution squares on a contributor's profile. The catch is that the large number most people quote sits elsewhere on the page and measures something different.

This guide covers where the 52-week commit signal lives, what it can and cannot tell you about a project's pace, and which other signals fill the gaps. It uses the clawk repository as a worked example, since its numbers make the distinction easy to see.

The short version

Before you start

The trailing-52-week commit graphs live under a repository's Insights tab, not in the big number on its front page. That front-page figure is the all-time commit total on the default branch; the Insights view shows only the last year and tells you whether work is recent and steady. As of 2026-08-15, clawk's repository listed 33 lifetime commits, 974 stars, and 36 forks while describing itself as under active development (github.com/clawkwork/clawk), a reminder that a low all-time count and an active project can sit together. Before ranking any agent sandbox by activity, check the recency and spread of its commits, glance at issue and release cadence, and keep popularity metrics separate.

52 weeks of commits, week by week (measured 2026-08-15)

Repository	2025-08-16 → 2025-11-15	2025-11-15 → 2026-02-14	2026-02-14 → 2026-05-16	2026-05-16 → 2026-08-15	52-week total
clawk	0	0	0	33	33
Sculptor	0	0	0	1,822	1,822
Container Use	18	0	1	8	27
herdr	0	0	431	978	1,409
CCManager	149	148	92	28	417

Measured on 2026-08-15, these are weekly commit counts pulled directly from each repository's public GitHub statistics endpoint over the same trailing 52 weeks, bucketed into four 13-week windows. Over that window Sculptor recorded a 52-week total of 1,822 commits against CCManager's 417 as of 2026-08-15, but the shape matters more than the totals: Sculptor's entire count landed in the final 13-week window (0, 0, 0, then 1,822) while CCManager's activity tapered steadily across the year (149 → 148 → 92 → 28), and herdr climbed from 431 to 978 across its last two windows — a reasonable reader weighing whether to depend on one of these might read a recent, sustained cadence as a project still being actively maintained rather than dormant. What none of these figures establish is code quality, genuine forward progress, how many people actually use any of these tools, or whether a burst of recent commits will persist into next year; a high count can reflect churn or a one-time import just as easily as healthy momentum.

Weekly commit counts for the last 52 weeks, from each repository's own GitHub statistics endpoint, grouped into four 13-week windows. Every repository is measured over the same 52 weeks, so the columns are directly comparable. Commit counts include merges, dependency bumps and documentation edits, and a monorepo will always show more commits than a single-purpose repository — this measures how busy a repository is, not progress, quality, or how much of the work reaches users. Collected by this site on 2026-08-15 (2026-08-15T01:55:50Z) by calling the public APIs ourselves — 15 of 15 requests returned data. These are our own readings, not figures supplied by any vendor.

Where the 52-week commit signal actually lives

On GitHub, the trailing-year view of commits shows up in two places. The Insights tab holds it: Insights → Contributors draws a per-contributor weekly bar chart over roughly the last 52 weeks, and the commit-frequency graph under the same tab charts weekly commit volume for the whole repository. The green contribution squares on an individual's profile cover a similar window.

Reading those views is mostly about shape and recency. Are the most recent weeks filled in, or blank? Do commits spread across the year, or bunch into a single burst? A steady band of weekly bars reads as ongoing maintenance. A tall spike twelve months ago followed by empty weeks reads as a project that has slowed or stopped. Neither picture tells you about code quality, but both tell you whether someone is still showing up.

Why the number on the repo's front page isn't the yearly one

Open any repository and the file browser shows a commit total near the top. For clawk that read 33 commits as of 2026-08-15 (github.com/clawkwork/clawk). That figure counts the default branch for the entire life of the project. It is cumulative and it is all-time.

The 52-week graphs behave differently. They only cover the trailing year, and they reset as old weeks roll off the back. Quoting the front-page total as if it described "activity this year" blends two separate measurements. A five-year-old project carrying thousands of lifetime commits might have added only a handful in the last twelve months. A three-month-old project might show a small lifetime total that happens to be entirely recent.

The practical move is to read the two figures together: the front-page total tells you how large the project has grown over its life, and the Insights graph tells you when that work happened.

clawk as a worked example

clawk is a macOS tool that boots a disposable Linux virtual machine for a coding agent so the agent can install packages and run code without touching the host (github.com/clawkwork/clawk). As of 2026-08-15 its repository page listed 33 commits on the default branch, 974 stars, and 36 forks, with 0 open issues and 0 open pull requests.

The README describes the project as "Pre-1.0 and under active development, and evolving quickly," and warns that breaking changes are expected between releases (github.com/clawkwork/clawk, as of 2026-08-15). Set those numbers beside that description and the reading is clear for a young project: a low all-time commit total does not by itself mean the work has halted. To confirm the direction, you would open the Insights tab and check whether those 33 commits land in recent weeks or sat quiet for months.

Stars and forks (974 and 36 here, as of 2026-08-15) measure attention and reuse; how often the code changes is a separate question, so keep those numbers in their own column when you take notes.

Signals to check when the commit graph is thin or missing

A commit graph can mislead in both directions, and sometimes you cannot see one at all. A few situations call for other evidence:

Squash-merge workflows collapse a whole feature branch into one commit on the default branch, so the visible count understates how much work went in.
Monorepos and bot accounts push the count the other way, with automated dependency bumps padding the weekly bars.
A rewritten or force-pushed history can reset what the graph displays.
Hosted or beta products may present a product page instead of a repository. Imbue, for example, lists Sculptor as a beta product on its site (imbue.com/product/sculptor, as of 2026-08-15). A product page on its own carries no commit graph, so gauging cadence there means locating the project's changelog, release notes, or public issue tracker.

When the commits are hard to read, weigh release frequency, the date of the most recent commit, the ratio of closed to open issues, and how quickly maintainers reply in discussions. Any one of these can correct a commit graph that is flattering or unfair.

A repeatable way to size up activity

The same short routine works across tools:

Open the repository, note the all-time commit total and the date of the most recent commit.
Open Insights and look at the 52-week commit graph for recency and spread, not just height.
Scan open and closed issues and pull requests for how responsive maintainers are.
Skim releases or the changelog to judge how regularly versions ship.
Record stars and forks as popularity, kept apart from your activity read.

Run those five checks and a single commit number stops standing in for the whole story.

Bottom line

Commit counts are a fair first read on a coding-agent sandbox's health, as long as you read the right number. The trailing-52-week graphs under a repository's Insights tab show whether work is recent and evenly spread; the all-time total on the front page sizes the project but says little about the last twelve months by itself. clawk shows how easily the two get confused: 33 lifetime commits as of 2026-08-15 alongside a README calling the project actively developed (github.com/clawkwork/clawk).

Before you rank any tool by activity, confirm the recency and spread of its commits, look at how issues and releases move, and keep popularity numbers like stars in a column of their own. For anything distributed mainly as a hosted or beta service, such as Sculptor's product listing on imbue.com as of 2026-08-15, turn to changelogs and release notes where a commit graph may not be published.

FAQ

Where does GitHub show the last 52 weeks of commits?

Under a repository's Insights tab. The Contributors view charts each contributor's weekly commits over roughly the trailing year, and the commit-frequency graph shows weekly volume for the whole repo. The contribution squares on a contributor's profile cover a similar window.

Is the commit number on a repository's main page the last year's total?

No. That figure is the all-time commit count on the default branch across the project's whole life. The 52-week view is separate and lives under the Insights tab, covering only the trailing year.

Does a low commit count mean an agent sandbox is inactive?

Not on its own. clawk listed 33 lifetime commits as of 2026-08-15 while its README described the project as under active development. Check whether the commits are recent and how often releases ship before drawing a conclusion.

Do stars and forks measure how active a project is?

They measure attention and reuse. clawk showed 974 stars and 36 forks as of 2026-08-15, which reflects how many people noticed it; that is separate from how often the code changes.

Sources

Originally published at https://utilverse.info/compare/how-active-are-agent-sandbox-tools-reading-52-weeks-of-commits/.

Google Indexed 1 of Our 43 Pages. DuckDuckGo Sent More Visitors.

stack_versus — Sat, 15 Aug 2026 00:04:29 +0000

Search Console has 43 of our URLs on record. 1 is indexed. Meanwhile DuckDuckGo has sent 38 visits to Google's 10.

Almost every article about getting indexed is written by someone whose site is already indexed. This one is not. This site has been visible to search since 2026-07-03 — 43 days, about 6 weeks. Google Search Console has 43 of our URLs on record: 1 is in the index.

We are publishing the numbers anyway, because the interesting part is not the failure — it is what happened around it. The pages were crawled. Search visitors did arrive. They just did not arrive from where the advice says they will.

The short version

Before you start

Search Console, 43 URLs checked: 1 indexed, 17 crawled and not indexed, 25 still unknown to Google. Referrers: DuckDuckGo 38 visits vs Google 10. Bot requests outnumbered human pageviews by about 15.2× last week. Crawl access and search presence are separate problems, and only one of them has a technical fix.

What we measured, and how

The first request in our access log is dated 2026-06-28 — infrastructure and setup traffic, before any article existed. Content went up in the days that followed, and Search Console has data for this property from 2026-07-03 — 43 days ago. It is a small English-language technical site with no backlink campaign, no social push, and no paid promotion. That makes it a clean specimen for one question: what happens to a new site's pages after search engines find them?

Two sources, both first-party. Indexing status comes from Google Search Console for this property, covering 2026-07-03 to 2026-08-14. Traffic comes from our own nginx access logs, processed by the same bot-exclusion rules we use for every number on this site — a user-agent filter, a probe filter, and a behavioural filter, applied identically to every request. Numbers below were generated on 2026-08-15 08:45.

One caveat stated up front: these are small numbers. A few dozen search visits is not a sample you should generalise from. What it is good for is showing the shape of a new site's first months, which is rarely published because it is not flattering.

43 URLs checked in Search Console. 1 indexed.

Search Console has 43 URLs on record for this property — every page we have published, plus a few that have since been retired. 1 is indexed. 17 were crawled and then not indexed. For the remaining 25, Google's own answer is “URL is unknown to Google” — it has not reached them yet. They are all in a submitted sitemap; submitting a sitemap asks Google to discover URLs, it does not oblige it to, and working through one takes as long as it takes.

The direction of travel is the interesting part. In the previous snapshot the crawled-but-not-indexed bucket held 1 URL; it now holds 17. Google is working through the site steadily — reading pages, then declining to keep them. Crawling is not the bottleneck. Judgement is.

This is worth separating from the usual advice, because the usual advice is about the wrong step. Sitemaps, internal links, clean HTML and fast responses all buy you crawling. We have crawling. What we do not have is a verdict in our favour, and there is no technical lever for that.

Every URL, and what Google says about it

Search Console status	URLs
URL is unknown to Google	25
Crawled - currently not indexed	17
Submitted and indexed	1

Every URL Search Console currently reports for this property, as of 2026-08-14. Statuses are Google's own wording.

Our first search visitors came from DuckDuckGo, not Google

Here is the result we did not expect. Across the life of the site, DuckDuckGo has sent 38 visits, against 10 from Google. That is roughly 3.8×.

The likely mechanism is visible in the table below: DuckDuckGo and several of the other referrers draw wholly or partly on Bing's index rather than Google's. We cannot see inside either index, so we are not claiming Bing indexed more of this site — only that these visits arrived through a different index with a different threshold, while Google's verdict on the same pages was the one shown above.

It also means the standard framing — get indexed by Google, then traffic follows — describes only one of several doors. The others are smaller, but on a new site they open first.

Where the visits actually came from

Referrer	Where its results come from	Visits sent
DuckDuckGo	Bing index + own crawler	38
Google	Google index	10
Bing	Bing index	9
Kagi	Blended, incl. Bing	7
Brave Search	Own index	7
Ecosia	Mixed sources	2
ChatGPT	Answer engine	2
Perplexity	Answer engine	2

Referrer hosts recorded in our own access logs across the life of the site, after the same bot-exclusion rules used everywhere on this dashboard. 463 visits arrived with no referrer at all and 6 came from hosts that are not search engines; neither is counted above.

The traffic is mostly not human

Over the last seven days this site served 270 human pageviews and 4,116 requests we classified as bots — about 15.2× more machine than human. Lifetime human pageviews stand at 809.

We mention it because it is the single easiest way to fool yourself with analytics. Raw log lines, or any counter with a weak bot filter, will show a new site growing nicely while the humans stay flat. We learned this the hard way: an earlier count on this site put one article at 198 views; the same article measured with the proper filter was 88. Same log, same day, different filter.

If your traffic graph is going up and your search referrers are not, check what is in the number before you celebrate it.

What we take from this

Crawled-but-not-indexed is the normal state of a new site, not a bug to fix. Google documents that it does not index every page it crawls. Our numbers are what that policy looks like from underneath.

Do not measure progress in crawl volume. This site is crawled constantly and indexed once. The two numbers are barely related, and only one of them sends visitors.

Check the other engines. Most of our search visits came from engines other than Google. That is a channel most new-site advice does not mention, and it costs nothing to verify in your own referrer log.

Publish the shape of your own data. Everything above came from a log file and a free Search Console property. The reason this data is rare is not that it is hard to collect — it is that it looks like failure, so people keep it private.

Bottom line

If you launched a site recently and Search Console is showing you a wall of “Crawled - currently not indexed”, this is what that looks like on another site with the same problem. It is not a misconfiguration, and no sitemap tweak resolves it.

What we would do differently with hindsight is spend less time on crawl plumbing — which was working from week one — and more time checking referrers from engines other than Google, because those were sending visitors while we were staring at the indexing report.

FAQ

Why would Google crawl a page and then not index it?

Google states that crawling and indexing are separate steps and that it does not index every page it crawls. 'Crawled - currently not indexed' means the page was fetched and assessed, and Google chose not to store it. It can change later without any action from you.

Does submitting a URL for indexing help?

It can get a page crawled sooner. It does not commit Google to indexing it — the URL Inspection tool's own wording is that submission requests a crawl, not an index entry. On this site, requesting indexing reliably produced a crawl and did not produce an index entry.

Is DuckDuckGo traffic worth anything?

It is real search traffic with real intent, and on this site it arrived earlier than Google's. Its volume is much smaller than Google's would be at scale, so treat it as an early signal that your content is findable, not as a substitute for Google.

How do you separate bots from humans in these counts?

Three layers, applied to every log line the same way: a user-agent list, a known-probe path filter, and a behavioural check on request patterns. No filter is perfect — a determined crawler with a browser user agent will be counted as human — so read these as best-effort, not exact.

Sources

Originally published at https://utilverse.info/compare/google-indexed-one-page-duckduckgo-sent-the-visitors/.

Which Crawlers Actually Visit a Brand-New Site? We Measured Ours

stack_versus — Fri, 14 Aug 2026 00:05:20 +0000

We logged every request to this site for 25 days — 27,906 of them — and counted who showed up. AI crawlers outnumbered Googlebot by about 8.4 to 1.

Most advice about crawlers is written from the outside — what Google says it does, what a vendor's dashboard reports. We had a simpler option available: this site is new and small, so we read our own server logs and counted.

Between 2026-07-19 and 2026-08-12 this domain received 27,906 requests. Below is every crawler that identified itself, how often it came, how much of the site it walked, and whether it bothered with our sitemap. The result that surprised us most: the busiest crawlers were not search engines at all.

The short version

Before you start

Over 25 days, language-model crawlers made 1,304 requests to this site against Googlebot's 155 — about 8.4:1. The single busiest crawler was Amazonbot (623 requests). Meanwhile, as of 2026-08-12, Search Console reported 1 of 48 URLs actually indexed. Crawl volume and search presence turned out to be unrelated.

What we measured, and how

This site is small and new: the first request in our logs is dated 2026-06-28, and it has a few dozen articles. That makes it a useful specimen — it has no backlink profile, no brand, and nothing to attract crawlers except being on the public web.

We took every line of the nginx access log for this domain between 2026-07-19 and 2026-08-12 — 27,906 requests in total — and classified each one by user agent. Classification uses a fixed list of user-agent tokens applied identically to every line, so the same log always produces the same table; a request counts once per hit. We report requests and distinct URLs separately because a crawler that hits one URL two hundred times is doing something very different from one that walks the whole site.

Two caveats worth stating plainly. User agents are self-reported and can be forged, so these counts describe what identified itself as each crawler, not verified identity. And this is one small site — the ratios here are a data point, not an industry average.

AI crawlers came far more often than Google did

The headline result: crawlers that collect for language models made 1,304 requests — 31% of all identified crawler traffic — while Googlebot made 155, a ratio of about 8.4:1. The AI side is not one bot but many: ClaudeBot (358), PerplexityBot (236), OAI-SearchBot (227), GPTBot (208), meta-externalagent (105).

Google's own crawling was modest in both volume and reach — 155 requests across 70 distinct URLs. For a site of this size that is a light touch.

If you have been assuming that a new site's server load is mostly search engines discovering you, that assumption is out of date. On this site the language-model crawlers are the main audience, and they arrived without being invited.

The busiest crawler was Amazonbot, not a search engine

Amazonbot (Amazon) was the single most active crawler at 623 requests across 408 distinct URLs — more than any search engine in the sample.

This is the part that surprises people who have not looked at their own logs: the crawler budget of a small site is spent on companies that will never send it a visitor. Only a handful of the crawlers below have any path to sending you traffic at all.

Who actually reads sitemap.xml

Sitemaps are supposed to be how you tell crawlers what exists. In practice most crawlers in our sample never asked for ours.

ClaudeBot — 111 requests for sitemap.xml
bingbot — 48 requests for sitemap.xml
GPTBot — 25 requests for sitemap.xml
AhrefsBot — 6 requests for sitemap.xml
Googlebot — 2 requests for sitemap.xml

Googlebot requested it 2 times in 25 days. Whatever governs how much Google crawls a new site, repeatedly re-reading its sitemap is not part of it.

Being crawled is not being indexed

The gap between crawling and indexing is the number that matters, and it is stark. As of 2026-08-12, Search Console reported 48 URLs known for this site: 1 indexed, 17 crawled but not indexed, and 30 not yet processed. Googlebot has read the pages. It has decided not to keep them.

That distinction is worth internalising before you spend a week on technical SEO. Crawl access is the cheap part — robots.txt, a sitemap, and clean HTML get you that in a day. Whether anything is kept is a judgement about the content, and no amount of crawl plumbing changes it.

The traffic side reflects the same thing from the other end. Over the same period our top search referrers were duckduckgo.com (31), google.com (10), bing.com (9), kagi.com (7), search.brave.com (6). The engine that indexed the least is not the one sending the most.

Every crawler we saw

Crawler	Operated by	Requests	Unique URLs	sitemap.xml	First seen
Amazonbot	Amazon	623	408	0	2026-07-23
bingbot	Microsoft Bing	594	88	48	2026-07-19
Applebot	Apple	526	271	0	2026-07-19
ClaudeBot	Anthropic	358	119	111	2026-07-19
SemrushBot	SEO tool	318	51	1	2026-07-19
PerplexityBot	Perplexity	236	99	0	2026-07-19
OAI-SearchBot	OpenAI (search)	227	109	0	2026-07-19
GPTBot	OpenAI (training)	208	121	25	2026-07-19
Googlebot	Google Search	155	70	2	2026-07-19
YandexBot	Yandex	144	70	1	2026-07-19
AhrefsBot	SEO tool	137	107	6	2026-08-01
meta-externalagent	Meta	105	58	1	2026-07-19
Claude-User	Anthropic (user fetch)	88	7	0	2026-07-21
DuckDuckBot	DuckDuckGo	80	17	0	2026-07-19
DotBot	SEO tool	67	36	0	2026-08-06
Google-Extended	Google (AI training)	66	60	0	2026-08-05
MJ12bot	SEO tool	52	46	0	2026-08-04
facebookexternalhit	Meta (link preview)	51	3	0	2026-07-19
DataForSeoBot	SEO tool	46	43	1	2026-08-04
Censys	Internet scanner	25	2	0	2026-07-22
GoogleOther	Google (non-search)	17	16	0	2026-08-11
Bytespider	ByteDance	16	6	0	2026-07-19
internet-measurement	Internet scanner	4	2	0	2026-08-05

Every request to this site between 2026-07-19 and 2026-08-12 (25 days), read from our own nginx access logs. “Operated by” names the company the user agent claims; crawlers marked as training or answer engines collect for language models rather than a search index.

What we would tell a new site owner

Three things follow from this data, and none of them is a growth hack.

Read your own logs before you read advice about logs. The ratios here were not what we expected, and they were free to obtain. Whatever your site is, the answer for your site is already sitting in /var/log/nginx.

Decide deliberately about AI crawlers. They are the majority of crawl load in this sample. robots.txt can allow or disallow them individually — that is a real choice with real trade-offs, not a default to drift into.

Do not read crawl volume as progress. Being crawled thousands of times told us nothing about whether the content was worth keeping. The indexing numbers answered that, and they answered it differently.

Bottom line

If you run a small site and have never opened your access log, this is the cheapest hour of analysis available to you. Ours said that the crawler traffic we were implicitly optimising for — Google discovering pages — was a small minority of what actually arrived, and that being crawled heavily told us nothing about whether our pages were worth keeping.

We publish the full table above so the claim is checkable rather than asserted. The method is three lines of log parsing; run it on your own site and you will get a different answer, which is rather the point.

FAQ

Do these numbers apply to my site?

Not directly. This is one small, new, English-language technical site with no backlink profile, measured over 25 days. Treat the ratios as a prompt to check your own logs, not as a benchmark.

Can user agents be faked?

Yes. User agents are self-reported. These counts describe traffic that identified itself as each crawler. Verifying identity requires reverse-DNS or published IP ranges, which we did not apply here — so treat named counts as upper bounds.

Does blocking AI crawlers help SEO?

There is no evidence in this data either way. Blocking a language-model crawler changes who can read your content; it does not change how a search engine judges it. Decide it on licensing and bandwidth grounds, not ranking ones.

Why is crawled-but-not-indexed so common on new sites?

Google states that crawling and indexing are separate steps and that it does not index every page it crawls. On a new site with little established value, the not-indexed bucket is where most pages sit until that changes.

Sources

Originally published at https://utilverse.info/compare/which-crawlers-actually-visit-a-new-site-we-measured-ours/.

What Developer Tools Actually Cost: A Checked Price Index

stack_versus — Thu, 13 Aug 2026 00:05:24 +0000

36 plans across 25 products, each read from the vendor's own pricing page on 2026-08-12 — with the source link and the date attached to every figure.

Almost every “X vs Y” article you can find will tell you to check current pricing on the vendor's site. That advice is correct and completely useless: it hands the work back to you, which is the work you came to have done.

So we did it. On 2026-08-12 we opened the official pricing page for every product below and recorded what it showed — 36 plans across 25 products. Each row carries the figure, the billing term where the vendor stated one, and a link to the page it came from. Where we could not read a figure, the row says so instead of guessing.

The short version

Before you start

36 plans, 25 products, one date: 2026-08-12. Every price below was read from the vendor's official page that day, with a source link on each row. Notable movers since older comparisons: Hetzner's June increase, Windsurf's move under Cognition, Copy.ai's shift upmarket, and Render dropping per-seat billing.

How this list was built

On 2026-08-12 we opened the official pricing page of every product below and wrote down what it showed. Not a vendor summary, not last year's blog post — the page itself, on that date. Where a figure could not be read from the official page we say so rather than filling the gap with a guess; 1 entry is marked that way.

Two things this list deliberately does not do. It does not convert currencies — where a vendor quotes in euros or localises by region, that is what you see, because the conversion is not ours to assert. And it does not rank anything: this is a reference table, not a recommendation.

Prices move. Anything here is a snapshot with a date attached, and the linked official page is always the authority. We would rather publish a dated figure you can check than an undated hedge that tells you nothing.

What changed recently

Checking every page on one day surfaced several changes that older comparisons still have wrong. These are the ones worth knowing before you budget:

Hetzner raised cloud prices on 15 June 2026. The increases were uneven: dedicated-vCPU CCX13 went from €15.99 to €42.99 a month and shared-vCPU CPX22 from €7.99 to €19.49, while the entry CX23 moved only €3.99 → €5.49 and Arm CAX11 €4.49 → €5.99. Hetzner is still inexpensive at the entry tier, but on the larger plans the gap against other hosts is much narrower than 2025-era comparisons suggest.
Windsurf is now part of Cognition. windsurf.com redirects to devin.ai. Pro moved from $15 to $20 in March 2026 when credits were replaced by daily and weekly quotas, and a $200/month Max tier appeared.
Copy.ai has moved upmarket. Alongside a $29/month Chat plan, its go-to-market tiers now start at $1,000 a month. If you remember it as a cheap writing assistant, that is no longer the product being sold.
Render dropped per-seat billing. Flat $25/month Pro and $499/month Scale plans replaced the old $19 and $29 per-member tiers.
Sourcegraph's public pricing is enterprise-only, starting at $16K. The standalone individual Cody tiers are no longer sold there.
Postman renamed its tiers to Solo, Team and Enterprise; the old Basic/Professional names persist in a lot of published comparisons.

None of this is exotic. It is simply what a single day of reading official pages turns up, and it is the reason we date every figure.

AI coding

Product	Plan	Price	Source
Amazon Q Developer	Amazon Q Developer	Free · Pro $19 / user / month free tier is capped at 50 agentic requests per month	official page
Claude / Claude Code	Claude Code — via API (pay-as-you-go)	Token-based — no subscription billed per token through the Anthropic Console	official page
Claude / Claude Code	Claude Code — via Claude Max	from $100 / month Max 5x and Max 20x usage tiers	official page
Claude / Claude Code	Claude Code — via Claude Pro	$20 / month ($17 annual) Claude Code is included in every paid Claude plan	official page
Cursor	Cursor	Free Hobby · Pro $20/mo · Teams $40/user/mo Enterprise is custom-quoted	official page
GitHub Copilot	GitHub Copilot	Free · Pro $10 · Pro+ $39 · Business $19 · Enterprise $39 per user/mo a $100/mo Max tier also exists	official page
Sourcegraph Cody	Sourcegraph Cody	Enterprise only — from $16K Sourcegraph's public pricing page now lists only an Enterprise tier; the standalone Cody free/individual plans are no longer sold there.	official page
Tabnine	Tabnine	Code Assistant $39 · Agentic Platform $59 per user/mo annual subscription; Tabnine-provided model access can add token costs	official page
Windsurf / Devin (Cognition)	Windsurf	Free · Pro $20/mo · Max $200/mo Windsurf is now part of Cognition (Devin); Pro rose from $15 and credits became quotas on 2026-03-19.	official page

Hosting

Product	Plan	Price	Source
DigitalOcean	DigitalOcean — Basic Droplets	from $4 / month 512MB/1vCPU $4 · 1GB $6 · 2GB $12 · 4GB/2vCPU $24	official page
DigitalOcean	DigitalOcean — Optimized Droplets + managed services	from $42 / month (CPU-Optimized 4GB) General Purpose 8GB/2vCPU $63. Managed databases, Kubernetes and App Platform are billed separately.	official page
Ghost(Pro)	Ghost(Pro) — managed	Starter $18 · Publisher $29 · Business $199 per month billed yearly	official page
Hetzner Cloud	Hetzner Cloud — shared & Arm VMs (CX / CPX / CAX)	from €5.49 / month (CX23) Arm CAX11 €5.99; CPX22 €19.49. Germany/Finland, excl. VAT, after the 2026-06-15 increase.	official page
Hetzner Cloud	Hetzner — dedicated vCPU & bare-metal servers	from €42.99 / month (CCX13) CCX23 €85.99 · CCX33 €138.49. The 2026-06-15 adjustment raised dedicated-vCPU plans sharply (CCX13 was €15.99).	official page
Neon	Neon	Free tier · paid plans are usage-based Launch and Scale are pay-as-you-go — compute, storage and transfer metered hourly with no monthly minimum.	official page
Render	Render — Paid instances & team plans	Pro $25/mo flat · Scale $499/mo flat Render dropped per-seat billing in 2026 — Pro ($25 flat) replaced Professional ($19/member) and Scale ($499 flat) replaced Organization ($29/member); legacy workspaces migrated on 2026-08-01.	official page

Dev tools

Product	Plan	Price	Source
Insomnia	Insomnia — Paid (Pro / Enterprise)	Pro $12 · Enterprise $45 per user/mo Enterprise is self-serve up to 50 users	official page
Jira	Jira — Standard / Premium	Standard from $7.53 · Premium $13.53 per user/mo	official page
Linear	Linear — Paid tiers (Basic / Business)	Basic $10 · Business $16 per user/mo billed yearly	official page
Postman	Postman — Paid plans	Solo $9 · Team $19 · Enterprise $49 per user/mo billed annually. Postman renamed its tiers — the old Basic/Professional names are gone.	official page

Passwords & security

Product	Plan	Price	Source
1Password	1Password Families	$4.49 / month billed annually	official page
1Password	1Password Individual	$2.99 / month billed annually	official page
1Password	1Password Teams Starter Pack / Business	Teams Starter Pack $24.95/mo · Business $8.99/user/mo Starter Pack covers 10 members; both billed annually	official page
Bitwarden	Bitwarden Paid (Personal / Business / Enterprise)	Premium $1.65/mo · Families $3.99/mo · Teams $4 · Enterprise $6 per user/mo billed annually	official page
NordVPN	NordVPN — tiered plans	Basic $68.85 · Plus $82.35 · Complete $97.35 per year NordVPN advertises lower per-month averages ($4.59 / $5.49 / $6.49) that do not equal these totals divided by 12. VPN promotional terms and prices change frequently.	official page
Proton Pass	Proton Pass Family / Unlimited	not verified Proton loads prices dynamically per currency — Family and Unlimited rates could not be read from the public page on 2026-08-12, so no figure is asserted here.	official page
Proton Pass	Proton Pass Plus	$2.99 / month on the 12-month plan ($35.88/year)	official page

Productivity

Product	Plan	Price	Source
Copy.ai	Copy.ai — Paid tiers	Chat $29/mo ($24 annual); GTM plans from $1,000/mo Copy.ai has moved upmarket — Growth $1,000 · Expansion $2,000 · Scale $3,000 per month, billed annually.	official page
Jasper	Jasper — Creator / Pro (paid)	Pro $69/seat/mo ($59 annual) Jasper no longer lists a Creator tier; Business is custom-quoted.	official page
Notion	Notion Business (Recommended)	₩30,000 per member / month Notion localises pricing by region — see the note on the Plus plan.	official page
Notion	Notion Plus	₩14,000 per member / month Notion localises pricing by region and served ₩ to our request on 2026-08-12 — check notion.com/pricing in your own region for the local figure.	official page
Obsidian	Obsidian Enterprise	Commercial license $50 / user / year required when Obsidian is used for work at a company of 2+ people; a one-time $25 Catalyst license is separate and optional.	official page
Obsidian	Obsidian Publish (add-on)	$8 / site / month billed annually; $10 on monthly billing	official page
Obsidian	Obsidian Sync (add-on)	$4 / user / month billed annually; $5 on monthly billing	official page
Otter.ai	Otter Business	$30 / user / month ($19.99 annual)	official page
Otter.ai	Otter Pro	$16.99 / user / month ($8.33 annual)	official page

A note on regional pricing

One entry behaved differently from the rest: Notion served our request prices in Korean won rather than US dollars. That is not an error in the table — it is how the vendor localises, and it is a useful reminder that a single quoted figure can be wrong for your region even when it is right for whoever wrote it down.

Where you see a currency other than USD below, it is the currency the official page actually showed us. Check your own region before you plan a budget around it.

Bottom line

Use this as a starting map, not a quote. The value of a dated index is that you can see at a glance which products are in which price band, and then confirm the one you care about on the linked page — a far shorter job than pricing a shortlist from scratch.

If a figure here is stale, the date tells you so immediately. That is the whole point of publishing the observation date next to the number instead of writing “confirm current pricing on the vendor's site.”

FAQ

How current are these prices?

Every figure was read from the vendor's official pricing page on 2026-08-12. Vendors change prices without notice, so treat the date as part of the number and follow the source link for the current figure.

Why are some prices in euros or won?

Because that is what the official page showed. We do not convert currencies — an exchange rate we picked would be our assertion, not the vendor's price. Some vendors also localise pricing by region, so your figure may differ.

Why are some entries marked 'not verified'?

Some vendors load prices dynamically per currency or account, and the figure could not be read from the public page. We would rather leave a gap than publish a number we did not see.

Are annual and monthly prices the same?

Usually not. Where a vendor advertises both, the note column says which billing term the figure belongs to. Annual billing is commonly 15–25% cheaper, but the discount varies enough that it is worth checking rather than assuming.

Sources

Originally published at https://utilverse.info/compare/what-developer-tools-actually-cost-a-checked-price-index/.

Container Use vs Sculptor: Sandboxed Parallel Coding-Agent Environments Compared

stack_versus — Wed, 12 Aug 2026 00:06:05 +0000

A feature-by-feature comparison of Container Use and Sculptor, two open-source tools for running coding agents in parallel with isolated git worktrees.

Both Container Use and Sculptor solve the same core problem: letting AI coding agents work in isolation so several can run at once without stepping on each other. Container Use, from Dagger, gives each agent a sandboxed container on its own git branch. Sculptor, from Imbue, wraps parallel agents in a workspace UI where every agent gets its own worktree, terminal, and diff view.

They overlap heavily in intent but differ in shape — one leans on containers and a command-line git workflow, the other on a desktop workspace app with a plugin system. This comparison walks through how each is positioned, how they isolate work, how they integrate with agents, and what each one costs, drawing on the vendors' own documentation and repositories as observed on 2026-08-02.

At a glance

In short

Both run coding agents in parallel using isolated git worktrees, and both are open source. Choose Container Use if you want a container-backed sandbox reviewed through ordinary git commands and terminal drop-in, with named integrations for Claude Code, Cursor, and VSCode. Choose Sculptor if you want a local desktop workspace that shows every agent's diff in one window, works with any model provider, and is extensible via JavaScript/TypeScript plugins — noting it is marked beta. Sculptor's page states it is free with no subscription beyond your model provider; Container Use's introduction page did not list a price as of 2026-08-02 (verify its LICENSE).

Head to head

Key differences side by side; the stronger option is tinted green.

Feature	Container Use	Sculptor
Positioning	Sandboxed dev environments for coding agents (container-use.com, 2026-08-02)	Extensible, parallel coding workspace you own, marked beta (imbue.com, 2026-08-02)
Isolation model	Fresh container per agent on its own git branch, via Dagger + git worktrees	Isolated worktree per workspace with its own branch, terminal, and diff
Review workflow	Standard git: git checkout to review an agent's work	One window shows every active agent's diff; git fetch && git checkout from your repo
Primary interface	CLI + terminal drop-in for direct intervention	Desktop workspace app surfacing all agents in one view
Model/provider flexibility	Not covered on the pages we read (2026-08-02)	Works with any model or provider; switch models mid-session via Pi (imbue.com, 2026-08-02)
Extensibility / plugins	Not covered on the pages we read (2026-08-02)	Build plugins in JavaScript/TypeScript; swap harness with Pi Coding Agent (imbue.com, 2026-08-02)
Named agent integrations	Claude Code, Cursor, VSCode listed in Agent Integration docs (container-use.com, 2026-08-02)	Bring your own Claude plan or a supported open-source model (imbue.com, 2026-08-02)
GitHub stars (as of 2026-08-02)	3.9k stars, 199 forks (dagger/container-use)	212 stars, 13 forks (imbue-ai/sculptor)
Install methods	Homebrew, shell script, or build from source	Download from the product page; runs locally on your computer

Feature matrix

Feature	Container Use	Sculptor
Git worktree isolation — Both isolate each agent on its own branch	✅	✅
Container-based sandbox — Container Use uses Dagger containers; Sculptor's page describes worktree/local isolation, not containers, as of 2026-08-02	✅	❌
One-window multi-agent UI — Sculptor surfaces all agents in one workspace; Container Use routes review through git/CLI	❌	✅
Plugin system (JS/TS) — Not covered on the pages we read (2026-08-02)	❌	✅
Model/provider switching — Not covered on the pages we read (2026-08-02)	❌	✅
Open source on GitHub — dagger/container-use and imbue-ai/sculptor	✅	✅
Free with no subscription — Not covered on the pages we read (2026-08-02)	🟡	✅

✅ full · 🟡 partial/paid · ❌ not supported

Pricing

Confirm current pricing on each vendor's site.

Container UseOpen-source project on GitHub; no price listed on its introduction page as of 2026-08-02

Distributed via GitHub (dagger/container-use)
Install via Homebrew, shell script, or build from source
Repository includes a LICENSE file — verify terms before commercial use

Container Use docsSculptorFree, local, open source; no subscription required beyond your model provider (as of 2026-08-02)

Runs on your computer, not Imbue's servers
Bring your own Claude plan or a supported open-source model
Source available on GitHub (imbue-ai/sculptor)
Marked beta on the product page

Sculptor product page

Pros & cons

Container UsePros

Container-per-agent sandbox via Dagger plus git worktrees for branch isolation
Full command history and logs of what agents actually did
Direct terminal drop-in to intervene when an agent gets stuck
Review via standard git checkout, no special tooling
Larger public GitHub following (3.9k stars as of 2026-08-02)

Cons

Introduction page did not list pricing or license terms as of 2026-08-02 — check the repo's LICENSE
Plugin system and model-switching not described on the pages we read

SculptorPros

Free, local, open source with no subscription beyond your model provider (as of 2026-08-02)
Works with any model or provider; switch models mid-session via Pi
Extensible with JavaScript/TypeScript plugins; swappable harness
One window surfaces every active agent, terminal, and diff
Runs locally so your code stays in your repo

Cons

Marked beta on the product page as of 2026-08-02
Smaller public GitHub following (212 stars as of 2026-08-02)

Container Use and Sculptor: the public release record on 2026-08-02

Measured on 2026-08-02	Container Use dagger/container-use	Sculptor imbue-ai/sculptor
Latest release	v0.4.2, published 2025-08-19	sculptor-v0.42.0, published 2026-07-10
Commits, weekly average	0.1 a week (1 commits in the 12 weeks to 2026-08-02)	150.7 a week (1,808 commits in the 12 weeks to 2026-08-02)
Most recent commit	2026-06-12	2026-08-01

As recorded on 2026-08-02 from each project's public source repository on GitHub, Container Use averaged 0.1 commits a week over the preceding 12 weeks, with its most recent commit dated 2026-06-12, while Sculptor averaged 150.7 commits a week over the same span, its latest commit dated 2026-08-01. Both figures are commit-activity counts pulled from the GitHub REST API — a measure of how often code was changed in each public repository, not a vendor's status page or a package registry's download tally. Taken at face value, they suggest that Sculptor was under active, near-daily development in mid-2026 whereas Container Use had gone largely quiet, a distinction worth weighing for anyone who values ongoing maintenance and responsiveness to new issues. What these numbers do not establish is which tool is more reliable, better supported, higher in product quality, or more widely used, since commit frequency speaks only to development pace and says nothing about outcomes or adoption.

Where these numbers come from: on 2026-08-02 (2026-08-02T00:00:18Z) we called the public endpoints listed below and recorded what they returned. Nothing here is taken from either vendor's marketing pages, and anyone can repeat the same calls. Repository figures describe the named repository — for a closed-source platform that is its official CLI or SDK, not the platform itself. What these figures do not tell you: Commit counts include merges, dependency bumps and documentation changes, and a monorepo will always show more commits than a single-purpose repository, so this measures how busy the named repository is — not progress, quality, or how much of it reaches the product. The commit date says the repository is being worked on, nothing about what changed. None of them measures reliability, support or how either product feels to use.

Container Use — GitHub REST API · GitHub releases API · Dagger's own repository for the project
Sculptor — GitHub REST API · GitHub releases API · Imbue's own repository for the project

What each tool is

Container Use describes itself as "sandboxed dev environments for coding agents," built to let agents "run safely in parallel without requiring babysitting" (Container Use documentation, container-use.com, as of 2026-08-02). Under the hood it leverages Dagger for containerized workflows and Git worktrees for branching. Each agent gets a fresh container in its own git branch, so you can run multiple agents without conflicts, experiment, and discard failures. The project also emphasizes visibility — a complete command history and logs of what agents actually did — and direct intervention, letting you drop into an agent's terminal and take control.

Sculptor is presented as an "extensible, parallel coding workspace you own" and is marked beta on Imbue's product page (imbue.com/product/sculptor, as of 2026-08-02). It is an open-source app for running coding agents in parallel that runs on your computer rather than Imbue's servers. Its pitch centers on three ideas: it is free and local, it is extensible (you can build plugins in JavaScript or TypeScript and swap the agent harness with Pi Coding Agent), and it works with any model or provider with no lock-in.

How they isolate parallel work

The two tools converge on git worktrees as the isolation primitive, but frame it differently.

Container Use pairs Dagger-based containers with git worktrees: "Each agent gets a fresh container in its own git branch," and review happens through a standard git workflow — "just git checkout <branch_name> to review any agent's work" (container-use.com, as of 2026-08-02). The emphasis is on a container-per-agent sandbox plus branch-based review from your normal terminal.

Sculptor centers the same idea in a UI. "Each workspace is an isolated worktree with its own branch, terminal, and diff view," and the product page states you can "run 5+ agents on 5+ tickets at the same time. Nothing bleeds between" (imbue.com/product/sculptor, as of 2026-08-02). Sculptor also keeps out of your editor: agents push to a local git remote and you "git fetch && git checkout from your normal repo." The difference in feel is that Sculptor surfaces every active agent in one window with visible diffs, while Container Use routes review through git commands and terminal drop-in.

Agent and model integration

Container Use documents an Agent Integration step for configuring it with a coding agent, naming Claude Code, Cursor, and VSCode as examples (container-use.com, as of 2026-08-02). Installation is available via Homebrew, a shell script, or building from source.

Sculptor states it "works with any model, any provider" with "no model lock-in," and lets you "enable Pi and choose any provider or switch models mid-session" (imbue.com/product/sculptor, as of 2026-08-02). It also describes bringing your own Claude plan or a supported open-source model. On extensibility, Sculptor's page says you can build plugins in JavaScript or TypeScript and "swap the agent harness entirely with Pi Coding Agent," and that skills "run as full agents with their own tools," able to read your codebase and spawn parallel subagents.

Container Use's introduction page did not list a plugin system or model-provider switching as of 2026-08-02; if that matters to your decision, confirm it against the project's own documentation, since the introduction is only one page of a larger docs set.

Project maturity and community

As of 2026-08-02, the Container Use repository (dagger/container-use on GitHub) showed 3.9k stars and 199 forks, with 324 commits and open issues and pull requests visible on the repo. Sculptor's product page reported 212 GitHub stars and 8 contributors, and the imbue-ai/sculptor repository showed 212 stars and 13 forks (GitHub, as of 2026-08-02). By these public counts, Container Use has the larger star and fork base, while Sculptor is explicitly labeled beta on its product page.

Both projects are open source and hosted on GitHub, with Container Use offering Discord, GitHub, and a YouTube playlist for community support, and Sculptor pointing users to review its source and contribute on GitHub.

Which to choose

Pick based on the surface you want to work from. If you prefer a command-line, container-backed sandbox where you review agent output through ordinary git commands and drop into terminals when needed, Container Use fits that workflow and its Agent Integration docs name Claude Code, Cursor, and VSCode. If you want a desktop workspace that shows every active agent, diff, and terminal in one window and lets you extend it with JavaScript/TypeScript plugins or swap the harness, Sculptor is built around that model — with the caveat that it is still in beta.

On cost, Sculptor's page states it is free, local, and open source with no subscription required beyond your model provider (imbue.com/product/sculptor, as of 2026-08-02). Container Use is distributed as an open-source project on GitHub; its introduction page did not list a price or subscription as of 2026-08-02, so verify licensing terms in the repository's LICENSE file before adopting it commercially.

Verdict

Container Use and Sculptor answer the same question — how do you let several coding agents work at once without collisions — and both settle on git worktrees plus branch-based review. The practical split is interface and philosophy. Container Use is container-first and CLI-first: Dagger gives each agent a sandboxed container, you review with git checkout, and you drop into a terminal to intervene. Its public following is larger, with 3.9k GitHub stars as of 2026-08-02.

Sculptor is workspace-first: a local, open-source app that puts every active agent, terminal, and diff in one window, works with any model provider, and invites extension through JavaScript/TypeScript plugins. Its product page states it is free with no subscription beyond your model provider (imbue.com/product/sculptor, as of 2026-08-02), which makes cost easy to reason about — with the reminder that it is still beta.

If your team already lives in the terminal and wants container-grade sandboxing, start with Container Use. If you want a visual command center for many agents and value the ability to swap models and extend the tool, try Sculptor. Because both are open source and free to install, the lowest-risk move is to run each against a couple of real tickets and see which review loop fits how you already work.

FAQ

Are Container Use and Sculptor free?

Sculptor's product page states it is free, local, and open source, with no subscription required beyond your model provider (as of 2026-08-02). Container Use is distributed as an open-source project on GitHub; its introduction page did not list a price as of 2026-08-02, so check the repository's LICENSE file for exact terms.

Do both tools use git worktrees?

Yes. Container Use pairs Dagger containers with git worktrees, giving each agent a fresh container on its own branch. Sculptor makes each workspace an isolated worktree with its own branch, terminal, and diff view (both as of 2026-08-02).

Which coding agents do they work with?

Container Use's documentation names Claude Code, Cursor, and VSCode as examples in its Agent Integration step. Sculptor says it works with any model or provider, lets you switch models mid-session via Pi, and supports bringing your own Claude plan or a supported open-source model (both as of 2026-08-02).

Which is more established?

By public GitHub counts on 2026-08-02, Container Use showed 3.9k stars and 199 forks, while Sculptor showed 212 stars and is labeled beta on its product page. Star counts reflect visibility, not a quality ranking — evaluate both against your own workflow.

Sources

Originally published at https://utilverse.info/compare/container-use-vs-sculptor-sandboxed-parallel-coding-agent-environments-compared/.

Cezar vs Sculptor: Two MIT-Licensed Parallel Coding-Agent Tools Compared

stack_versus — Tue, 11 Aug 2026 00:05:58 +0000

A feature-by-feature comparison of Cezar and Sculptor — two tools for running parallel AI coding agents — covering the agents and models they drive, where they run, platforms, and setup.

Cezar and Sculptor answer the same basic wish: run more than one AI coding agent at a time and keep track of what each one does. They come at it from different directions. Cezar, from open-mercato, is a command-line tool that opens a browser cockpit for orchestrating agent tasks inside your own repository. Sculptor, from Imbue, is a downloadable coding workspace currently labeled beta.

This comparison walks through what each project's own pages describe as of 2026-08-09: the agents and models they drive, where they run, how you install them, and what they cost. Where a page we read did not cover something, we say so instead of guessing.

At a glance

In short

Short version (as of 2026-08-09): Cezar (open-mercato) and Sculptor (Imbue) are both MIT-licensed, free-to-install tools for running AI coding agents in parallel. Cezar is a command-line tool with a browser cockpit that drives multiple agent CLIs (Claude Code, Codex, and experimental OpenCode), runs on your machine or an Ubuntu VPS, and adds autonomous queues and variant runs. Sculptor is a downloadable Mac/Linux workspace focused on Claude models (plus experimental Pi) that needs a paid Claude or Claude Max subscription. Choose Cezar for multi-backend orchestration and self-hosting; choose Sculptor for a simpler Claude-focused desktop app.

Head to head

Key differences side by side; the stronger option is tinted green.

Feature	Cezar	Sculptor
What it is	Parallel coding-agents orchestrator with a local browser cockpit (open-mercato)	Extensible, parallel coding workspace you own, in beta (Imbue)
License	MIT (as of 2026-08-09)	MIT (as of 2026-08-09)
Agents / models it drives	Claude Code (default), Codex, and OpenCode (experimental)	Claude 4.8/4.7/4.6 Opus, 4.6 Sonnet, 4.5 Haiku, plus experimental Pi
Supported platforms	Runs via Node 20+; documented Ubuntu VPS deployment and a mobile-friendly cockpit	Mac (Apple Silicon) and Linux; the page states no Windows or mobile support
Install path	npx cezar-cli (no extra config if the Claude CLI and gh are logged in)	Download
API key / subscription	No API key used; shells out to agent CLIs you are already logged into (e.g. Claude Pro/Max)	Free and MIT, but a paid Claude or Claude Max subscription is required
Remote / self-hosting	Documented server-install on Ubuntu VPS, multi-domain cockpits, reverse-proxy support	Not covered on the pages we read (2026-08-09)
Parallel execution model	Isolated git worktrees; run a task as ×2/×3 variants and compare diffs	Described on its page as a parallel coding workspace
Autonomous / queue mode	Autonomous flag plus a fire-and-forget task queue	Not covered on the pages we read (2026-08-09)
Per-run telemetry	Live status, cost and peak memory per run	Not covered on the pages we read (2026-08-09)

Feature matrix

Feature	Cezar	Sculptor
MIT license — Both projects state MIT on their pages as of 2026-08-09.	✅	✅
Runs coding agents in parallel — Cezar orchestrates across isolated worktrees; Sculptor's page describes a parallel coding workspace.	✅	✅
Claude support — Cezar defaults to the Claude Code CLI; Sculptor lists Claude 4.8/4.7/4.6 Opus, 4.6 Sonnet and 4.5 Haiku (as of 2026-08-09).	✅	✅
Non-Claude agent/model option — Cezar: Codex, plus OpenCode marked experimental. Sculptor: experimental Pi. Per each project's page as of 2026-08-09.	✅	🟡

✅ full · 🟡 partial/paid · ❌ not supported

Pricing

Confirm current pricing on each vendor's site.

CezarFreeMIT licensed; no API key used (github.com/open-mercato/cezar, as of 2026-08-09)

Runs locally via npx cezar-cli; cockpit at http://localhost:4321
Drives your logged-in agent CLIs — Claude Code (default), Codex, or OpenCode (experimental)
Requires Node 20+ and at least one logged-in agent CLI (e.g. a Claude Pro/Max login)
Documented Ubuntu VPS deployment for remote, mobile-friendly access

View on GitHubSculptor (beta)Free, open source, MIT licensed; requires a paid Claude or Claude Max subscription (imbue.com/product/sculptor, as of 2026-08-09)

Supports Claude 4.8/4.7/4.6 Opus, 4.6 Sonnet, 4.5 Haiku, plus experimental Pi
Installs via Download on Mac (Apple Silicon) and Linux
Described as an extensible, parallel coding workspace you own

View Sculptor

Pros & cons

CezarPros

Drives multiple agent CLIs (Claude Code default, Codex, OpenCode experimental), mixable per step
Runs on your machine with no accounts, database or cloud; state kept as readable files under .ai/cezar/
Documented Ubuntu VPS deployment, multi-domain cockpits, reverse-proxy support and remote access
Parallel isolated worktrees, ×2/×3 variant runs, an autonomous queue, and live cost/status/peak memory per run
MIT-licensed and uses no API key (as of 2026-08-09)

Cons

Needs Node 20+ and at least one logged-in agent CLI before it can do anything
The OpenCode backend is marked experimental
More moving parts (CLI, cockpit, git worktrees) than a single downloadable app

SculptorPros

Free, open source and MIT-licensed (as of 2026-08-09)
Supports the current Claude family (4.8/4.7/4.6 Opus, 4.6 Sonnet, 4.5 Haiku) plus experimental Pi
Simple install via Download on Mac (Apple Silicon) and Linux
Positioned as a parallel coding workspace you own

Cons

Marked beta on its product page as of 2026-08-09
Requires a paid Claude or Claude Max subscription
The product page lists no Windows or mobile support as of 2026-08-09

Cezar and Sculptor: the public release record on 2026-08-09

Measured on 2026-08-09	Cezar open-mercato/cezar	Sculptor imbue-ai/sculptor
Latest release	v0.9.2, published 2026-08-04	sculptor-v0.44.0rc2, published 2026-08-07
Commits, weekly average	96.4 a week (1,157 commits in the 12 weeks to 2026-08-09)	151.6 a week (1,819 commits in the 12 weeks to 2026-08-09)
Most recent commit	2026-08-08	2026-08-08

As recorded on 2026-08-09 from each project's public source repository on GitHub, Sculptor (imbue-ai/sculptor) averaged 151.6 commits a week over the preceding twelve weeks, while Cezar (open-mercato/cezar) averaged 96.4 commits a week over the same span; both projects had also committed as recently as 2026-08-08. These are counts of development activity in openly hosted code repositories, not figures drawn from a package registry's download totals or a vendor's own status page, so they measure how busy each codebase has been rather than anything reported by the makers themselves. For someone weighing the two, the higher commit rate suggests Sculptor was under more frequent active development in this window, which may matter to buyers who value rapid iteration and responsiveness to issues. It does not, however, establish that either tool is more reliable, better supported, higher in product quality, or more widely used, since none of those properties can be inferred from commit frequency alone.

Where these numbers come from: on 2026-08-09 (2026-08-09T00:05:54Z) we called the public endpoints listed below and recorded what they returned. Nothing here is taken from either vendor's marketing pages, and anyone can repeat the same calls. Repository figures describe the named repository — for a closed-source platform that is its official CLI or SDK, not the platform itself. What these figures do not tell you: Commit counts include merges, dependency bumps and documentation changes, and a monorepo will always show more commits than a single-purpose repository, so this measures how busy the named repository is — not progress, quality, or how much of it reaches the product. The commit date says the repository is being worked on, nothing about what changed. None of them measures reliability, support or how either product feels to use.

Cezar — GitHub REST API · GitHub releases API · the project's own repository and the npm package published from it
Sculptor — GitHub REST API · GitHub releases API · Imbue's own repository for the project

What Cezar and Sculptor are

Cezar's GitHub page describes it as a "parallel coding agents orchestrator — a local cockpit for running and tracking AI coding-agent tasks in your repo" (github.com/open-mercato/cezar, as of 2026-08-09). You type a task, pick a workflow and an agent, and watch it work live: steps, tool calls, tokens and diffs, in a browser cockpit that runs entirely on your machine. The same page states there are no accounts, no database and no cloud, and that state lives in an .ai/cezar/ folder inside your repo as plain JSON, NDJSON and Markdown you can read and edit by hand.

Sculptor's product page introduces it as an "extensible, parallel coding workspace you own," described as an extensible, open source app for running coding agents, and marked beta (imbue.com/product/sculptor, as of 2026-08-09). It is one of several products listed by Imbue on that page.

So both aim at parallel agent work, and both publish their source under an MIT license (as of 2026-08-09). The differences show up in how you run them, which backends they drive, and how far along each project is.

The agents and models each one drives

Cezar's README (as of 2026-08-09) says you pick an agent per task — Claude Code, Codex, or OpenCode (marked experimental) — or mix them per step. It shells out to whichever agent CLIs you are already logged into, defaulting to claude, and states plainly that "No API key is ever used." That makes the backend list a matter of which command-line tools you have installed and authenticated.

Sculptor's product page approaches this as model support rather than CLI selection. Its FAQ answer to "Which models does Sculptor support?" names Claude 4.8 Opus, 4.7 Opus, 4.6 Opus, 4.6 Sonnet and 4.5 Haiku, along with experimental Pi support (imbue.com/product/sculptor, as of 2026-08-09).

These are two different axes, so read them side by side rather than as a contradiction. Cezar chooses among agent CLIs (with Claude Code as one option), while Sculptor lists the specific Claude model versions it can run, plus an experimental non-Claude option in Pi.

Where they run: platforms, hosting, and remote access

Cezar runs from the command line. Its README lists Node 20+ as a prerequisite and starts the cockpit with npx cezar-cli at http://localhost:4321 (as of 2026-08-09). It also documents a server path: server-install, server-deploy and server-uninstall on an ubuntu-vps platform, several independent cockpits per host via a --domain flag, and an --external-proxy option for setups where Dokploy, Coolify, Caddy or nginx already own ports 80 and 443. The page pitches leaving it on a VPS as "a dev team that's always on," with a mobile-friendly cockpit you can check from your phone; a hosted cockpit run with CEZ_REMOTE=1 is described as read-only.

Sculptor's product page lists Mac (Apple Silicon) and Linux as its supported platforms and states there is no Windows or mobile support (imbue.com/product/sculptor, as of 2026-08-09). VPS deployment and remote-hosting specifics were not covered on the page we read, so if running it on a server matters to you, check Imbue's own documentation before deciding.

Setup, license, and cost

Cezar installs through npx cezar-cli (or npx @open-mercato/cezar), and the README says that if your claude CLI is logged in and gh is authenticated, "there is nothing else to configure" (as of 2026-08-09). It is MIT-licensed and uses no API key, instead relying on the agent CLI logins you already hold — for the default Claude backend that means a Claude Pro or Max subscription on the CLI side. A CEZ_DRY_RUN=1 mode runs the whole cockpit against a bundled mock so you can explore it offline.

Sculptor's FAQ states it is "Free, open source, and MIT licensed," installs via a Download, and answers "Do I need a paid Claude subscription?" with "Yes" — a paid Claude or Claude Max subscription is required (imbue.com/product/sculptor, as of 2026-08-09).

Net cost picture as of 2026-08-09: both tools are free to install under MIT, and both put you in front of Claude, so the recurring cost in each case comes from a Claude subscription rather than the tool itself. Cezar can also route to Codex or OpenCode if you would rather not depend on Claude at all.

Choosing between them

Reach for Cezar if you want to orchestrate several agent CLIs at once, mix Claude Code with Codex or OpenCode per step, self-host on a VPS, and run autonomous or ×2/×3 variant batches with live cost, status and peak memory per run. Its README leans toward users comfortable with Node, git worktrees and a command line.

Reach for Sculptor if you want a simpler downloadable workspace on a Mac (Apple Silicon) or Linux desktop, you are focused on the Claude model family, and you already hold a paid Claude or Claude Max subscription. Keep in mind that its product page marks it beta as of 2026-08-09.

Cezar's public repository showed active development at the time we looked (128 stars, 25 forks and 1,262 commits, github.com/open-mercato/cezar as of 2026-08-09), which is one input if project maturity weighs on your choice. Beyond that, the decision turns on how many backends you need, whether remote self-hosting is on your list, and how much setup you are willing to do.

Verdict

Pick Cezar if you want to orchestrate several agent CLIs at once, mix Claude Code with Codex or OpenCode per step, self-host on a VPS, and run autonomous or ×2/×3 variant batches with live cost and status per run. Its README (as of 2026-08-09) reads as a tool for people comfortable with Node, git worktrees and the command line.

Pick Sculptor if you want a simpler, downloadable Claude-centric workspace on a Mac (Apple Silicon) or Linux desktop and you already hold a paid Claude or Claude Max subscription. It is marked beta as of 2026-08-09, which is worth weighing against Cezar's more active public repository.

Both are MIT-licensed, free to install, and both put Claude at the center, so the call comes down to how many backends you need, whether remote self-hosting is on your list, and how much setup you are willing to take on.

FAQ

Are Cezar and Sculptor free?

Both list an MIT license on their pages as of 2026-08-09. Cezar uses no API key and runs the agent CLIs you are already logged into, so its ongoing cost comes from those subscriptions (a Claude Pro or Max login for the default backend). Sculptor's FAQ says it is free, open source and MIT-licensed but requires a paid Claude or Claude Max subscription.

Do both work with Claude?

Yes. Cezar defaults to the Claude Code CLI and can also run Codex or OpenCode (experimental), per its README as of 2026-08-09. Sculptor's product page lists Claude 4.8/4.7/4.6 Opus, 4.6 Sonnet and 4.5 Haiku, plus experimental Pi support, as of 2026-08-09.

Can I run either one on a server and access it remotely?

Cezar's README (as of 2026-08-09) documents installing it as a service on an Ubuntu VPS with multi-domain cockpits, reverse-proxy support and a mobile-friendly, read-only remote cockpit. Sculptor's product page focused on a Mac and Linux desktop download and did not cover VPS or remote-hosting setup, so check Imbue's documentation if that is a requirement.

Which platforms do they support?

Cezar runs via Node 20+ from the command line and documents an Ubuntu VPS deployment (github.com/open-mercato/cezar, as of 2026-08-09). Sculptor's product page lists Mac (Apple Silicon) and Linux and states there is no Windows or mobile support (imbue.com/product/sculptor, as of 2026-08-09).

Sources

Originally published at https://utilverse.info/compare/cezar-vs-sculptor-two-mit-licensed-parallel-coding-agent-tools-compared/.