How Active Are Agent Sandbox Tools? Reading 52 Weeks of Commits
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.
Contents
OverviewThe short version52 weeks of commits, week by week (measured 2026-08-15)Where the 52-week commit signal actually livesWhy the number on the repo's front page isn't the yearly oneclawk as a worked exampleSignals to check when the commit graph is thin or missingA repeatable way to size up activityBottom lineFAQSourcesAsk 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
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 | Week by week |
|---|---|---|---|---|---|---|
| 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.
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.