PiG is a Go port of the Pi coding agent, with upstream behaviour as the contract

Upstream behaviour is the specification, Go is the implementation

The project defines itself in terms of what it is not doing. The repository description says PiG is a faithful Go port of upstream Pi, the TypeScript codebase behind the Pi coding agent, and that it is a parity-bound translation rather than a rewrite, with upstream behaviour as the contract and Go as the implementation language. The README puts the same idea as a set of rules. PiG follows Pi's behaviour and design unless a Go constraint or an approved product-neutral requirement makes a difference necessary, and the compatibility philosophy lists preserving observable compatibility with Pi, treating the pinned Pi release as the reference behavior, minimising unnecessary divergence, recording each intentional user-visible or interoperability difference, preferring changes that reduce the cost of the next upstream sync, and sharing generally useful findings with the ecosystem when the contribution route permits. That list is effectively the project's design review checklist, and it tells a reader that divergence is not a failure but something that has to be justified in writing.

The pin names the behaviour oracle

The mechanism that makes the compatibility claim checkable is a pinned upstream commit, and the README is precise about what it means. The pinned Pi build is 1.3.0+1402973a, a specific commit of the main branch, and the README says the pin names the behavior oracle. It also says the pin does not claim that every upstream change is already ported, and points at two places where the real state is tracked: the parity coverage file reports verified behavior, and the upgrade ledgers under the upstream-sync directory list each upstream change and its disposition. That is a much stronger position than a project that says it is compatible. A ledger of dispositions tells a reader whether a given upstream change was ported, skipped or deliberately deferred, which is exactly the information a user needs before upgrading. The pin itself lives in a file in the .upstream directory and can be overridden for a single run with an environment variable, or moved with a make target.

What is ported, and what is deliberately left out

The scope statement is short and the omission is the interesting part. The current package scope covers Pi's agent, AI, coding-agent and TUI packages, and it does not implement Pi's experimental remote Session packages or its standalone telemetry and evaluation packages. The README points at a file map document for the exact boundary, which is the right place to look before depending on a specific feature. The rest of the project structure follows from the same division. The repository has agent/, ai/, coding/, tui/, cmd/, extensions/, piglets/, mcp/, telemetry/, chord/, codemode/ and durable/ directories, an embed.go file at the root, and an internal/ directory, so the Go code mirrors the upstream package layout rather than inventing a new one. A port that keeps the upstream structure is much easier to re-sync, which is the whole point of the compatibility rules.

One binary, but the TypeScript extensions still need Node

The headline benefit is that PiG is a single native binary that starts quickly and needs no Node.js, and it runs Pi's TypeScript extensions unchanged. That last clause is the interesting trade-off, because the extension story is broader than Go. The README says you can also write extensions in Go, Rust or Python, and that you can bundle extensions, skills and prompts into a Piglet, a named agent you can share or build into its own executable. The dependency list in go.mod shows the mechanism for the foreign extension types, with wazero as a WebAssembly runtime, chroma for syntax highlighting, goldmark for Markdown, the AWS SDK for Go v2, modernc sqlite for the database, and websocket and fsnotify for the transport and file watching. The Node.js requirement does not disappear for TypeScript extensions, it just moves from the core agent to the extension runtime, and the README has a separate document about using the two side by side.

Installing is one of four commands, and Go is the least fragile

There are four documented install routes, and the README notes that the install page covers every method including updates and uninstalling. On macOS, Linux, or Android under Termux on arm64, it is a shell installer piped to sh.

curl -fsSL https://pi-in-go.dev/install.sh | sh

On Windows in PowerShell, it is the equivalent PowerShell script piped to iex, and the README is upfront that Windows support is a preview. With npm it is a global install of the package on any supported platform, and with Go it is a go install of the module path at the latest version.

go install github.com/MichaelKinsy/PiG/cmd/pig@latest

The Go route is the one to prefer in a reproducible environment, and the quick start is two commands:

cd /path/to/project
pig

and there is a reason the version choice matters: the go.mod retracts v0.5.0 with a comment saying that version cannot be installed with go install because its module source is larger than the Go module size limit, and that v0.5.1 or later should be used. That is a concrete operational detail rather than a theoretical one, since the newest release at the time of writing is v0.5.1.

Configuration is a directory, a pin and a make gate

The project facts section reads like a configuration reference, and each entry answers a question a user would otherwise have to search for. The binary is named pig. The Go module is github.com/MichaelKinsy/PiG. The configuration root is a directory under the home directory or the PIG_HOME environment variable, and the agent directory sits inside it or comes from PIG_CODING_AGENT_DIR. There is a local upstream mirror directory, a main verification gate called make check, and a full verification and coverage refresh called make verify. The Makefile itself explains that developers, CI and coding agents run make targets rather than ad hoc shell commands, and that the scripts behind those targets live in an automation/ directory split into dev, ci, gen, release, porter and images subdirectories. There is also a stated reward function for the coverage target, which should print three numbers going up and zero going down.

Version reporting and one documented behavioural divergence

Two details tell you how seriously the parity work is taken. The first is version reporting. The version flag prints PiG's version as the PiG release plus the Pi release, with the Pi release as semver build metadata so the string still sorts as the PiG release, and a separate command prints the two as separate fields, and neither command reads user configuration. The second is the login privacy default, which is the one place the README calls out a divergence from Pi by identifier. The interactive login masks secret input by default, and turning off the mask secret input setting in the settings restores Pi's plain-text typing and submitted input. The README labels this with a divergence marker and links to the login privacy documentation, which is exactly the kind of thing the compatibility rules say should be recorded, and the mask being the default rather than the exception is a deliberate product decision rather than a porting artefact.

Pre-stable, independently governed, and not endorsed upstream

The status is stated without hedging. PiG is a pre-stable 0.x release, core paths are ported and checked against the pinned Pi build with paired parity scenarios, and edge cases are still hardening. The README says that if PiG behaves differently from Pi, that is either a bug or a documented divergence. It also says PiG is not an official Pi release and that the Pi maintainers do not endorse PiG, and it directs anyone who wants Pi itself to the upstream source, documentation, the vendor behind it and its community channels. The governance is local to this repository, with the project decisions, issues and contributions belonging here and separate documents for governance and maintainers. The origin is stated too: Michael Kinsy created PiG while working at Hewlett Packard Enterprise. The licence is MIT with a REUSE status badge and a NOTICE file, and the repository carries a changelog directory, a CITATION.cff file and a third party notices file alongside the code.

Editorial conclusion

PiG suits a developer who wants Pi's terminal agent as a single fast binary without a Node.js install, and a contributor who wants to help port a well-specified system. It does not suit a team that needs every Pi package, because the port covers the agent, AI, coding-agent and TUI packages and leaves the experimental remote Session and standalone telemetry packages out. Before adopting, read the port status file for the current scope and check the pinned Pi commit, and note that the last push to the repository was on 2026-10-20 with v0.5.1 from 2026-10-19 under an MIT licence with a REUSE status badge.

Frequently asked questions

Official sources

1. License: MIT
2. MichaelKinsy/PiG on GitHub
3. Project website
4. README
5. Releases