Two places, two granularities. This site's changelog carries release-level summaries, and the repo's CHANGELOG.md records every individual change with its package version bump, updated in the same commit as the change itself.
The current release: v0.1.0
The site changelog's first entry (26 May 2026) describes what shipped at v0.1.0: the text surfaces (cues and blanks), folder-based hot-reloading config, keyboard navigation and cycling, the capability-sandboxed blank model, the CLI (validate, list, seed-configs), reference integrations for Claude Code, OpenCode, Gemini CLI, Chrome, and the standalone shell app, and the open standard with its conformance suite and JSON schemas.
How the repo changelog works
OpenCues is a monorepo where each package versions independently under semver, deliberately staying below 1.0 until public launch. Every change lands in CHANGELOG.md under an Unreleased heading with the exact package bump in the entry title, so you can trace any version number to the change that produced it. The open standard has a separate spec/CHANGELOG.md, because wire-format changes move on their own schedule from runtime fixes.
Current package versions
| Package | Version |
|---|---|
@opencues/core (LLM analysis library) | 0.18.1 |
@opencues/runtime (host-agnostic runtime) | 0.13.5 |
opencues (CLI) | 0.2.42 |
The spec is versioned separately again (currently a 0.7 draft). A quick sample of recent entries shows the texture: a no-argument opencues interactive launcher, a trust gate on opencues import for third-party packs, gemma becoming selectable by name in the natural-language model switcher, and fixes like opencues validate false-positiving on shape-only blanks and a combined-mode CUE.md silently dropping its LLM half.
The discipline behind it
Version bumps aren't an afterthought in this repo; they're enforced. A CI gate fails any change that touches a package's source without bumping its version, and the project's contribution rules require the changelog entry in the same PR as the change. The payoff for users is that a version number is always meaningful: if opencues version shows a bump, something really changed, and the changelog names it.
Following along
The practical routes, in increasing granularity: this site's changelog for releases, the repo's CHANGELOG.md for individual changes, and opencues version on your machine to see exactly which versions your install is running. After pulling new code, opencues update rebuilds every detected integration, and opencues run self-heals stale installs even if you forget.
One honest note about the pre-launch state: while everything is below 1.0, minor versions can carry breaking changes, and the changelog is the contract for spotting them. The versioning policy itself (which bump rules apply to which package, when integrations bump independently of core, and when the spec version moves) is documented in the repo under docs/architecture/versioning.md, so the rules are inspectable rather than tribal knowledge.
Related: How to update · The documentation map · How to contribute · GitHub repo