mediar-ai/screenpipe moved. Here is where it is now.

The redirect, in one HTTP round trip

You do not have to take this on faith. A single curl call against the old URL with -I (head request, no follow) shows exactly what GitHub does when something asks for the old path. The response is a 301 with a Location header pointing at the new org.

The status code matters. A 301 (rather than 302) is GitHub telling search engines and link-checkers that the move is permanent and authority should transfer to the new path. Browsers cache it, archive crawlers update their indices off it, and git itself follows the redirect during a clone or fetch transparently. Your existing checkouts still work. They do, however, have a stale remote URL written into their .git/config, and the polite thing to do is update them with git remote set-url origin https://github.com/screenpipe/screenpipe.git.

The rename, in time

Five rough waypoints. The dates are pulled from public GitHub metadata: the repo creation timestamp, the terminator creation timestamp, and the public README history of the screenpipe project. Specifics like “late 2024” reflect the README's star-count milestones and Mediar's portfolio listings, not a single commit.

What lives where now

The mediar-ai org and the screenpipe org both still exist and are both still active. They cover different problems. Below is a side-by-side of what each one is responsible for at the time of writing.

The two repos in numbers

A quick snapshot pulled from the GitHub REST API on May 5, 2026. The first two numbers describe the project that moved. The next describes the new flagship of the mediar-ai org. The last counts the current size of the org.

What the mediar-ai org actually contains today

If you arrived here looking for “the screenpipe org” and ended up at mediar-ai by mistake, the project mix is now noticeably different. The center of gravity is automation, not recording. The repos below are the ones worth knowing about.

And if you came looking for the original screen-recorder project, here is what the screenpipe org looks like by itself.

Why split a single org into two

A reasonable question: if both projects come out of the same team, why bother giving them separate orgs at all? The honest answer is that the two products solve different problems for different audiences and a shared org was starting to confuse both. Screen recording is a developer-and-prosumer tool with a brand (screenpi.pe), an MCP integration story, and a contributor base measured in the thousands. Windows desktop automation for enterprise RPA is a commercial product with a sales motion, a turn-key program, and an SDK that needs to evolve fast without churning the recording project.

Splitting the orgs lets each project keep its own README at the top of the GitHub org page, its own homepage, its own contributors and discussions. The recording project gets to look like a self-contained open-source community at github.com/screenpipe. The automation project gets to look like a focused commercial-leaning org at github.com/mediar-ai, anchored on terminator. The 301 redirect from the old path means none of the existing links break in the meantime.

If you came here looking for the current product

Some traffic to this page is people who searched the GitHub path because they were trying to find what Mediar is doing today, not the old project. The short version: Mediar AI is a Windows desktop automation platform that watches a workflow once, then executes it deterministically through Windows UI Automation. The runtime is built on terminator.

The longer version, with the source-level architecture of where the AI runs and where it does not, lives on the mediar-ai architecture page. The company background and the namesake clarification are on the company page.

Frequently asked questions