An open standard for AI is a published specification that any implementation can target, so the capability belongs to an ecosystem rather than to one product. The best-known recent example is MCP, the Model Context Protocol, which standardised how AI assistants connect to tools. OpenCues applies the same move to a different layer: inline AI in text surfaces.
Why AI capabilities keep getting standardised
Closed assistants live inside one app; every other app does without them, or wraps them in shortcuts that lose context on tab-switch. A standard fixes the fragmentation once: when the way an editor asks for a cue or fills a blank is shared, every editor inherits the same vocabulary. New cues and blanks you write become usable by everyone; new integrations become useful to every existing config. The work compounds instead of fragmenting across walled gardens.
What the OpenCues standard actually is
File-format standards, one per text surface: cues (LLM to user, per word) and blanks (user to system, gated on _). Each has its own spec document, JSON Schemas, and conformance contract; a runtime can implement one surface and be conformant for that surface alone. The standard lives in the repo's spec/ folder: five spec docs, schemas, an executable conformance suite, a security model, and a proposal process modelled on MCP's SEPs. The standard is defined by a small set of .md files, not by any single piece of software.
What separates a standard from documentation
| Property | How OpenCues does it |
|---|---|
| Deterministic contract | Cues and blanks fire on literal text matches, never on an LLM reading a description: (the key difference from SKILL.md) |
| Executable conformance | spec/conformance/ holds valid/invalid fixtures, wire-format cases, and routing scenarios any runtime can run |
| Scoped normativity | Not a UI spec (rendering and keys are each integration's choice) and not a prompt-design spec (only the wire format is normative) |
| Evidence-gated growth | A runtime feature is promoted into the spec only after two independent runtimes adopt it |
| Versioned files | Configs pin spec: in frontmatter; runtimes refuse files newer than they support |
The honest status
The standard is currently a 0.7 draft. Field names and conformance rules may change between minor versions, production interop guarantees only begin at 1.0, and as of today no second implementation exists; the reference runtime in the OpenCues repo is the only one, and the conformance suite is the contract a second one would target. That is the normal early shape of a standard: MCP started as one vendor's spec too. The design bet is that the spec is small enough (markdown files, folder discovery, a one-line wire format) that a second implementation is a realistic weekend project rather than a corporate commitment.
Related: The OpenCues open standard · Implement the standard · OpenCues vs MCP · OpenCues vs SKILL.md · GitHub repo