GitHub has added a REST API endpoint for repository star history that returns historical counts without exposing individual stargazer identities. The endpoint groups stars by calendar week, includes a day-by-day breakdown, and gives maintainers and tool builders a new way to chart repository growth after GitHub restricted identity-level stargazer access.

GitHub is giving star-growth tools a new data source

GitHub has added a new REST API endpoint for something maintainers have wanted for years: a clean history of how a repository’s stars grew over time.

The new endpoint returns historical star counts with timestamps while keeping individual stargazer identities out of the response. GitHub announced it on September 4 as a privacy-safe alternative for tools and integrations that track repository growth.

The route is straightforward:

`GET /repos/{owner}/{repo}/stargazers/history`

Instead of returning a list of people, the API returns aggregate history that can be turned directly into a growth chart.

That changes the problem from “who starred this repository?” to “how did interest in this repository change over time?” — which is usually the question analytics tools actually need to answer.

The response is already shaped for charts

GitHub groups the result by calendar week, with the most recent week first.

Each record contains three useful pieces of data: a `week` timestamp, a `total` count for that week, and a `days` array containing the number of stars created on each day. The daily array starts on Sunday.

A response can look as small as this:

`{ “week”: 1754784000, “total”: 19, “days”: [0, 12, 7, 0, 0, 0, 0] }`

That is enough to build several views without reconstructing history from user-level events. A dashboard can plot weekly totals, calculate daily spikes, compare launch periods, or build a cumulative growth curve.

GitHub also includes zero-count weeks, which helps tools preserve a continuous timeline instead of having to guess whether a missing week means no activity or missing data.

Pagination walks backward through the repository’s history

The endpoint is designed to be read as a time series.

Pages move backward toward the repository’s creation week. Inside each page, weeks are ordered newest to oldest. GitHub says concatenating the pages produces one continuous history.

The default page size is 30 weeks, and callers can request up to 30 records per page. The `page` parameter can go up to 100.

For public repositories, the endpoint can be used without authentication. When fine-grained authentication is used, GitHub requires read access to repository metadata.

That makes the API useful for both public analytics tools and authenticated internal tooling without requiring access to the identities behind the star count.

This follows GitHub’s earlier privacy changes

The new endpoint fills a gap created by GitHub’s privacy-focused API changes earlier this year.

GitHub announced that identity-level stargazer and watcher listings would be restricted to repository administrators and collaborators. The company framed the change around protecting user privacy and responsible use of public data.

That restriction changed the shape of repository analytics. A public tool could no longer assume it should collect a list of individual stargazers simply to reconstruct a star-growth graph.

The new history endpoint provides the aggregate signal directly.

For maintainers, that is a cleaner boundary: repository-growth data stays available, while user identity is no longer a requirement for measuring that growth.

Existing star-history tools can simplify their data model

Many repository analytics tools historically built star history from the stargazer listing endpoint because that endpoint could include the timestamp attached to each star.

That worked, but it meant the tool was processing identity-level records even when the final output was only a chart.

GitHub’s new API removes that extra step.

A tool can fetch weekly counts, keep the `days` breakdown if it needs more detail, and store only the aggregate time series it actually uses. There is no need to maintain a parallel table of user accounts just to produce a growth curve.

GitHub explicitly says the endpoint is intended to help tools and integrations that tracked star growth before the privacy restrictions took effect.

For developers maintaining those projects, the migration path is much closer to the final analytics model they wanted in the first place.

Stars become easier to use as a project signal

GitHub stars are simple, but they are still useful as a rough measure of repository interest.

A total count tells you where a project is today. History tells you how it got there.

That can reveal whether attention arrived gradually or in bursts, whether a release produced a visible jump, or whether a repository has been building interest steadily over months. The new endpoint gives developers that timeline without requiring them to infer it from a public list of people.

It also makes comparisons easier. Tools can normalize weekly growth, look at recent momentum, or show how two repositories moved through similar stages.

The API does not turn stars into a perfect measure of project quality, and it does not need to. Its value is simpler: it makes a familiar GitHub signal much easier to analyze over time.

The endpoint is small, but the design is clean

This is not one of GitHub’s biggest releases of the month.

It is a small API addition with a very clear job.

The endpoint returns the historical signal developers want, keeps the response compact, works for public repositories without authentication, and avoids exposing individual stargazer data.

That combination makes it useful for dashboards, open-source analytics, maintainer tooling, and integrations that want to show repository growth without building an identity dataset around it.

For an API, that kind of narrow design is often exactly what makes it easy to adopt.

The Upgrade Feeling

GitHub’s star-history endpoint is a good example of privacy and developer utility landing in the same design.

Maintainers still get the timeline they care about. Tool builders get data that is already shaped for charts. Public repositories can be queried without authentication. And the API no longer needs to expose who created each star just to show when repository interest grew.

It is a small addition, but a useful one.

Sometimes the best API update is the one that gives developers less data — because the data it keeps is exactly what the product needs.

Agent Merge Moves Copilot Into the Final Stretch of a Pull Request

GitHub announced on September 4, 2026 that Agent Merge is now in public preview as part of the VS Code 1.136 release updates. The feature is designed to help get a pull request ready to merge by resolving review feedback, failed checks, and merge conflicts. That is a meaningful expansion of the coding-agent workflow because the work does not stop when code is generated. Copilot is being pushed further into the stage where changes are reviewed, validated, repaired, and prepared for the final merge.

The Goal Is a Merge-Ready Pull Request

The new feature is centered on a simple outcome: take a pull request that still has blockers and help move it toward a state where it can be merged. GitHub’s changelog names three common blockers directly: review feedback, failed checks, and merge conflicts. These are exactly the kinds of issues that often appear after the main implementation is already finished. Agent Merge gives Copilot a role in that follow-through instead of leaving every cleanup step as a separate manual task.

Review Feedback Can Become an Agent Task

GitHub’s Copilot app documentation already shows the broader workflow behind this idea. When a pull request has review comments, a developer can ask an agent to resolve a comment with a Fix action. The agent can inspect the requested change, update the code, and continue the pull request workflow. Agent Merge builds on that direction by making review feedback part of a larger merge-readiness process rather than a disconnected step.

Copilot Can Work on Failing CI Checks

GitHub also documents Copilot workflows for failing CI checks. In the Copilot app, developers can ask an agent to fix failing checks from the pull request view. In Copilot CLI, the /pr fix ci command lets Copilot inspect failing CI jobs, analyze the logs, apply targeted fixes, push the changes, and re-check the CI status. This makes automated validation part of the same agentic loop as code changes.

Merge Conflicts Are Now Part of the Agent Workflow

Merge conflicts are another important part of the new flow. GitHub already lets Copilot cloud agent help resolve conflicts from a pull request. The agent can analyze the conflicting changes, resolve them, and verify that the build, tests, and linter still pass before requesting review. Agent Merge brings that capability into a broader workflow whose goal is to move the entire pull request toward merge-ready status.

Copilot CLI Shows the Full Pull Request Lifecycle

GitHub’s /pr command in Copilot CLI makes the direction especially clear. Developers can view pull request status, create a pull request, address review feedback, resolve merge conflicts, fix CI failures, or run the entire sequence. The /pr fix command handles feedback, conflicts, and CI in order, while /pr auto can continue looping through those phases until the pull request is fully green. Agent Merge fits directly into this larger move toward end-to-end pull request automation.

One Command Can Address the Main Pull Request Blockers

The /pr fix workflow is a useful preview of how GitHub is thinking about agentic pull request work. It runs three phases: review feedback, conflicts, and CI failures. Those are the same categories highlighted in the Agent Merge announcement. Instead of requiring the developer to jump between several tools and manually coordinate each repair, Copilot can work through the sequence as one connected task.

Agent Merge Can Keep Working in the Background

GitHub’s Copilot app documentation describes Agent Merge as a background workflow. When enabled, it prompts the workspace’s Copilot session to read the pull request, fix what is blocking it, and merge it as soon as GitHub allows. The workflow survives app restarts and turns itself off once the pull request is merged. That makes the feature feel less like a one-shot command and more like an ongoing agent watching the state of the pull request until the job is complete.

The Human Still Owns the Final Development Workflow

The strongest version of this workflow is not about removing developers from the process. GitHub’s own documentation keeps review and repository rules in the loop. Copilot can make changes, resolve blockers, and request review, while normal branch protections, approvals, and repository settings continue to determine when a merge is allowed. That keeps the agent focused on execution while the project’s existing collaboration model remains intact.

Copilot Was Already Moving Into Pull Request Repair

GitHub has been expanding Copilot cloud agent beyond code generation for months. In an official GitHub Checkout demonstration, the company showed Copilot working on pull requests, resolving merge conflicts, and handling development tasks around CI and review. Agent Merge turns that broader direction into a more explicit merge-readiness feature inside the current VS Code release cycle.

The Agent Can Read the Pull Request as a Working Context

A pull request contains much more than a diff. It includes review comments, CI status, branch relationships, code changes, and project history. GitHub’s Copilot app lets an agent operate with this pull request context and start a session directly from the PR. That gives the model a richer working surface than a generic code prompt because the agent can act on the state of the actual change that is moving through review.

This Changes What a Coding Agent Is Expected to Finish

Early coding assistants were mainly judged by how well they generated code. Agent Merge points toward a broader definition of completion. A useful coding agent is increasingly expected to help with the full path from implementation to review, validation, conflict resolution, and merge readiness. The result is a workflow where the agent is responsible for more of the delivery process, not just the first draft of the code.

Pull Request Automation Is Becoming More Continuous

The combination of Agent Merge, Copilot CLI pull request commands, cloud-agent conflict resolution, and CI repair shows a clear pattern. GitHub is connecting individual Copilot actions into continuous workflows. A developer can ask for a change, move it into a pull request, respond to feedback, repair checks, resolve conflicts, and continue until the repository’s merge conditions are satisfied. The boundaries between coding, review, and release preparation are becoming much more connected.

VS Code Is Becoming a Home for Agent Sessions

The same VS Code 1.136 update also adds new ways to manage agent sessions. GitHub’s changelog notes multi-root workspace experiments, chat-session organization, and indicators for sessions that need attention. These additions matter because long-running agents need a place where developers can see what is happening, return to a task, and understand which sessions require input. Agent Merge fits naturally into that environment.

The Pull Request Becomes an Active Agent Workspace

With Agent Merge, the pull request is no longer just a review artifact at the end of coding. It becomes an active workspace where an agent can keep contributing after the initial implementation. Review feedback can lead to new edits, CI results can trigger repair work, and merge conflicts can become another step in the same ongoing session. That turns the PR into a live coordination point between the developer, reviewers, repository rules, and Copilot.

GitHub Is Connecting Copilot Across App, CLI, Cloud Agent and VS Code

One of the most important aspects of this update is that the same pull request lifecycle is appearing across several GitHub surfaces. The Copilot app can respond to reviews and failing checks. Copilot CLI exposes /pr commands for the full workflow. Copilot cloud agent can resolve conflicts directly from GitHub. VS Code now adds Agent Merge. The pieces are converging around one idea: Copilot should be able to participate wherever the pull request is being worked on.

The Upgrade Feeling

Agent Merge is a strong example of coding agents moving from code creation into software delivery. GitHub is giving Copilot a larger role after the first implementation is done: read the pull request, respond to review feedback, work through failing checks, resolve merge conflicts, and keep moving toward merge-ready status. For developers, that means the agent is becoming less like an autocomplete layer and more like a collaborator that can stay with a change through the final stages of the pull request.