Release status

The documentation header reads the installed package version from the root package.json.

Onboarding status

The hosted installer is planned and is not part of the current release. Use npx flary create or the local browser wizard from npx flary quickstart. See Quickstart and Deploy.

Large runtime changes ship under the npm next tag before they move to latest. Release candidates must pass package installation, generated template builds, Cloudflare deployment, provider recovery, tenant isolation, restart, archive restore, Browser, and Sandbox tests that apply to the release.

Internal transcript-engine versions and legacy migration adapters are release details. Application code should use the stable function, agent, thread, and client contracts.

See the repository tags and npm dist-tags for the exact published state.

1.0 release path

1.0.0 is the first stable 1.0 release. It includes the complete Flue 2 session engine, durable approval and user-input continuation, lazy tool search and Code Mode, protected secret collection, and default lazy web search. The same package passed the release, restart, package-install, and generated consumer gates as 1.0.0-rc.2 before it moved to latest.

1.0.1 is the first maintenance release. It adds the source-quality gate, package policy files, pull-request CI, and package metadata cleanup. It does not remove or rename the 1.0.0 public exports.

Publishing uses npm trusted publishing from .github/workflows/publish.yml. The npm package must trust the rdvo/flary repository and the publish.yml workflow. Release jobs do not use a stored write token.

The repository vendors the dmmulroy/anti-slop Oxlint rules. npm run lint enforces the high-signal rules during release checks. npm run lint:audit shows the full boundary-contract migration report. npm run lint:strict turns every audit warning into an error. Rules that reject all unknown input, runtime type guards, and conditional properties remain audit warnings because Flary must parse untrusted provider and network data at runtime.

What the npm tags mean

Pin an exact release candidate when you test a product integration. Do not assume that a Git tag is available on npm.

Codex-style behavior

Flary targets headless runtime behavior. It does not copy the Codex desktop interface, private app-server protocol, internal prompts, or ChatGPT login.

The portable Flary tool surface has three protected model-visible controls:

• execute for bounded Code Mode;
• request_user_input for durable follow-up questions;
• request_secret for protected credential collection.

Inside execute, the model can use tools.search, tools.describe, tools.call, and tools.batch. Application, MCP, OpenAPI, workspace, and Sandbox adapters use normalized policy, approval, replay, and audit contracts. Each adapter must pass its matching restart and replay tests before a stable release.

This is close to Codex-style lazy tool execution, but it is not exact parity. Flary uses a provider-neutral Dynamic Worker so the same thread can move between providers. Some providers also support native programmatic tool calling. Flary can use native acceleration only when it preserves the same durable call and audit contract.

Current differences are intentional and documented:

• eagerTools adds small, frequent tools to agent guidance. It does not expose them as provider-native direct tools.
• Tool search is lazy, but the runtime does not yet have the same central exposure classes, default result cap, and search cache as Codex.
• Dynamic Worker Code Mode is the portable default. Native provider code execution is an optional optimization, not a separate execution contract.
• The Codex desktop interface, private protocol, internal prompts, and exact product UX are outside Flary’s open runtime contract.

See Tools, MCP, and OpenAPI for the exact current surface.