Roadmap

Current Release: v0.9

Version 0.9 focused on production readiness: Docker and Kubernetes deployment, Prometheus metrics, structured logging, health checks, and the plugin registry. Key achievements:

• ✅ Docker multi-stage build for minimal production images
• ✅ Kubernetes Helm chart with horizontal pod autoscaling
• ✅ Prometheus metrics for agent runs, tool calls, and LLM latency
• ✅ Plugin registry with openclaw plugin install command
• ✅ REST API for programmatic agent invocation
• ✅ Webhook trigger system for event-driven agents
• ✅ Response caching with configurable TTL

Next Release: v1.0

Version 1.0 marks the first stable API release. The focus is on API stability guarantees, expanded LLM support, and enhanced multi-agent capabilities:

Future Roadmap (v1.1+)

These items are planned for releases after v1.0, ordered roughly by expected timeline:

• Agent marketplace: Community-contributed agent templates with one-click deploy (v1.1)
• Fine-tuning pipeline: Built-in fine-tuning data collection and training job management (v1.1)
• Multi-modal tools: Image analysis, document OCR, and audio transcription tools (v1.2)
• Agent testing framework: Automated evaluation harness for agent quality regression testing (v1.2)
• Federated agents: Agents running on different servers collaborating via secure message passing (v1.3)

Influencing the Roadmap

The roadmap is shaped by community feedback. The best ways to influence priorities:

• Vote on existing GitHub issues with a 👍 reaction — issues with more votes get prioritized
• Open a feature request issue with a clear use case and description of what you need
• Contribute the implementation — a working PR for a planned feature will always be fast-tracked for review over one that doesn't have a volunteer implementation
• Join the community Discord and share your use case in #feature-requests

The maintainers review roadmap priorities monthly and publish updates to this page. If you're planning a contribution to a roadmap item, comment on the tracking issue first to avoid duplicate work.

How Priorities Are Set

The OpenClaw roadmap is driven by three inputs: community demand (measured by GitHub issue votes and Discord discussions), adoption blockers (things that prevent new users from successfully getting started or that cause existing users to stop using the project), and maintainer judgment about what makes the codebase healthier and more sustainable long-term.

Performance improvements and developer experience upgrades get prioritized regularly because they benefit all users proportionally. Niche features with narrow applicability get deprioritized in favor of features that unlock usage across many more scenarios. Security issues are never deprioritized regardless of effort — they're treated as production incidents and fixed before the next release.

Version Numbering Policy

OpenClaw follows Semantic Versioning strictly: MAJOR.MINOR.PATCH. Before v1.0, minor version increments (v0.8, v0.9) indicate significant new features that may include breaking changes — always read the changelog when upgrading minor versions. Patch releases (v0.9.1, v0.9.2) contain only bug fixes and security patches; they are always safe to apply without reviewing breaking changes.

After v1.0, the MAJOR version will only be incremented for breaking changes. The maintainers are committed to providing at least one minor version's deprecation notice before removing any API that users may depend on — you will never have a feature disappear without warning after v1.0.

Release Schedule

OpenClaw targets a minor release (0.X) every 6-8 weeks and patch releases as needed when bugs are reported. There is no fixed date-based release schedule — releases happen when features and fixes are ready and the test suite is clean. Release candidates (e.g., v1.0.0-rc1) are published to PyPI with the --pre flag for community testing before stable releases.

To receive release notifications: watch the GitHub repository (click "Watch" → "Releases only"), subscribe to the newsletter via the project website, or join the Discord server's #releases channel where all releases are announced.

Shaping the Roadmap

The roadmap is not carved in stone. Community members actively influence priority through the GitHub discussions board, where feature requests and use-case descriptions are the primary input. The most effective way to get a feature prioritized is to clearly describe the use case it solves, share how many people would benefit, and if possible, provide a design sketch showing how it would fit the existing architecture.

Every quarter, the maintainers publish a "roadmap update" post summarizing what shipped, what moved, and what's next. These posts invite community feedback on priority adjustments. The process is transparent by design — roadmap decisions are made in GitHub discussions and Discord , not in private channels.

If you want to implement a roadmap item yourself, comment on the relevant issue and the maintainers will assign it to you and provide any design guidance needed. Community implementations of roadmap items are prioritized for review over other contributions because they directly advance the project's stated direction.

Deprecation Policy

OpenClaw takes backward compatibility seriously. Before removing any configuration key, API endpoint, or public Python API, the maintainers publish a deprecation notice in the changelog with a minimum 2-minor-version warning period. Deprecated features emit a warning log message when used, making it easy to identify what needs updating.

When a deprecated feature is finally removed, a migration guide is published in the documentation explaining exactly what to change. Your feedback on deprecations matters — if a planned removal would cause you significant pain, open a GitHub issue and the maintainers will discuss whether the timeline can be extended or a better migration path provided.