copper-rs v1.0.0-rc1: the first compatibility contract for Copper

We are at the point where Copper starts making explicit compatibility promises, but it just also just the beginning!

The current Copper story really starts just short of 2 years ago: on May 9, 2024, when development started in earnest and the system began taking the shape it has today: compile-time runtime generation, deterministic replay, structured logs, bridges, missions, and a runtime that scales from Linux to MCUs.

Since then, the project has moved quickly. As of May 1, 2026, the GitHub repository shows ~1.3k stars for ~1.3k commits and 16 major releases. More importantly, it now has real users pushing on it from different directions. Some wanted better prototyping paths. Some needed distributed replay. Some wanted clearer contracts before they built serious products on top of it.

That feedback directly shaped what is now the v1.0 API surface.

1.0 is the first contract …

v1.0.0-rc1 does not mean Copper is complete. It means we now understand enough of the design space to start freezing the right parts.

The 0.x line is where we deliberately moved fast. We wanted to validate the hard questions before making compatibility promises: bridges, missions, no_std, remote debugging, structured logging, distributed replay, and parallel runtime execution. All those parts have been built, exercised, broken, fixed, and refined in public.

That let us do the work that actually matters before 1.0: converge towards a first stable application-facing surface.

The beginning of a formal API definition

We now have an the first draft of an explicit V1 API contract, checked public API snapshots, and a clearer separation between stable APIs, experimental features, and internal machinery. In practice, that means users can start building against Copper with a much clearer understanding of what we intend to preserve.

… but we made room for growth before freezing the surface

Part of the late pre-1.0 work was paying down future breaking changes on purpose.

A good example is the move toward passing a richer CuContext into tasks instead of only passing a clock. That gives Copper a place to grow execution metadata, task identity, and future runtime information without forcing another signature break across the whole ecosystem.

The same thinking applies to log versioning. Unified logs now carry an explicit format version in the header. That is a small change on paper, but it is exactly the kind of mechanism you want in place before a larger ecosystem depends on your artifacts. It gives us a much better base to evolve tooling and replay without breaking the world.

This is the general philosophy of the release: create room to extend the system later without repeatedly tearing up the user-facing contract.

A notable last minute change; A new extension point for the Copper log format!

v1.0.0-rc1 adds typed log codecs as a new extension point for the Copper log format.

That means applications can now specify payload-specific encoders and decoders while preserving Copper’s core properties: deterministic replay, efficient logging, and a static application-defined interpretation model.

copper-rs has a steady stream of use on crates.io

The first examples are lossless image compression with PNG and FFV1, backed by new multiplane CuImage support. More importantly, they demonstrate the mechanism for future workload-specific encodings like matrices etc.

This next phase also requires sharper specifications

This release also happens to line up with the next phase of the project.

We are now working with a customer, still unnamed for now, on the kind of discipline required to move toward building the first robotics safety certified operating system. That does not start with marketing language but with some boring documentation.

Before you can talk seriously about certification, you need to be able to say, precisely, what the compiler generates, what modules are allowed to assume, what the runtime guarantees, and how logs and artifacts are versioned and interpreted over time.

That makes this release more than a version bump. It is the first structural step toward a Copper that is not only fast and deterministic, but also increasingly specifiable and auditable.

But why this is still rc1?

We are calling this rc1 very deliberately. We want feedback before we paint ourselves into a corner. The contract is now explicit enough to discuss seriously, but still early enough to adjust if an important part feels wrong or too narrow.

So if you are already building on Copper, this is a good moment to look closely at the V1 surface and tell us where the rough edges are. If you were interested in the project but hesitant because the pace of change felt too high, this release is for you as well.

A Big Thank You

A UTSA student compiling copper on his laptop yesterday.

A big thank you to the Copper community.

This v1.0 API surface was not designed in isolation. It was shaped by people using Copper in the real world, pushing on it from different angles, and telling us very directly where the boundaries were still too fuzzy.

So thank you to everyone who opened issues, sent patches, tested early releases, broke things, reported regressions, challenged design decisions, and stayed with us through the fast pace of the 0.x line. v1.0.0-rc1 is not just a milestone for us. It is a milestone made possible by the community around the project.

We also want to be very clear about something and reiterate again and again: we are committed to keeping copper-rs open source.

So while the company will offer professional services, tooling, and support around Copper, the core project remains something we want the whole robotics community to rely on, contribute to, and grow with us. Copper Robotics Inc, while a main sponsor of that project is just a member of that community.

Full technical details are in the release notes. And as usual, if you have questions or strong opinions, join us on Discord or open an issue.