openai/harmony

This system is a Rust-based library, exposed via Python and WebAssembly bindings, that handles the encoding, parsing, and rendering of AI conversation messages. It provides strict control over token generation and message structure, including support for function tools and special content types. The project also includes a Next.js demo application and comprehensive testing infrastructure to ensure cross-language consistency.

The HarmonyEncoding class now supports passing RenderOptions to the render method, allowing users to explicitly control whether the conversation includes function tools, which affects token generation. Additionally, the parse\_messages\_from\_completion\_tokens method and the StreamableParser now accept a strict mode parameter to control parsing behavior, and the StreamableParser includes a new process\_eos method for handling end-of-stream signals. The DeveloperContent class has also been added to the public API exports.

openai-harmony · high confidence

The demo application now includes a \cn\ utility function in \src/lib/utils.ts\ that combines \clsx\ and \tailwind-merge\ to safely merge Tailwind CSS classes, resolving issues with the previous shadcn utils implementation.

demo/harmony-demo · high confidence

The \HarmonyEncoding\ struct no longer uses a shared \Arc\<AtomicBool\>\ for tracking function tools, removing a concurrency hazard and allowing the encoding to be used safely across multiple threads. Rendering methods now accept an explicit \RenderOptions\ struct to pass context, and the message parser exposes a \ParseOptions\ struct with a \strict\ flag (defaulting to true) to control parsing behavior. These options are exposed in both the Python and WebAssembly bindings, allowing users to configure strictness and render context directly from their host applications.

src · high confidence

Added Python test runner and updated documentation; Added tests for constrain token handling and standardized test file encoding.

The openai-harmony library has been updated to version 0.0.8, with its Cargo.toml manifest adding a description and enabling the abi3-py38 feature for the optional pyo3 Python binding. The demo application's Next.js dependency has been upgraded from 15.4.4 to 15.4.10, and the Python project configuration now includes a description, readme reference, and pytest test path settings.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 72 → 75 (+2.8)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 87 → 87 (-0.0)
• Architecture 100 → 98 (-1.7)
• Maturity 68 → 68 (+0.0)
• Readiness 64 → 70 (+6.0)
• Security 85 → 90 (+4.6)
• Performance 100 (new)

• Dependency hygiene PARTLY measured — npm pinning read, dependency currency not (no pnpm-resolved versions to grade)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)

• Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
• Inconsistent naming for options-based methods. The with_options suffix is used here, but in StreamableParser, the options are passed via a separate constructor new_with_options. While not a direct duplicate, the API surface mixes patterns: some methods take options as a parameter (parse..._with_options), while others require a separate builder/constructor step (StreamableParser.new_with_options). This inconsistency in how optional parameters are handled across the module is confusing.
• Low cohesion: HarmonyEncoding (LCOM4 4) (src/encoding.rs)
• Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
• Naming inconsistency in 'into' variants. render_conversation_into does not take a next_turn_role, while render_conversation_for_completion_into does. It is unclear if render_conversation_into is a generic version or if it defaults to a specific role. The naming suggests render_conversation is the generic form, but the existence of a specific for_completion variant with an extra parameter creates ambiguity about when to use which.
• Redundant constructors with overlapping intent. Author contains a Role. Creating a message from an Author is functionally equivalent to creating one from a Role (plus potentially a name, but Message has a separate recipient field, not name). This forces the user to choose between two nearly identical paths.
• Same inconsistency as above but for the non-_into variants. render_conversation vs render_conversation_for_completion.

• Unchanged — 0 containers · 1 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

openai/harmony was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.