Okto Pulse (OktoLabsAI/okto-pulse) is an Elastic-2.0 local-first SDLC workbench that runs coding agents over MCP behind 17 named governance gates, blocking status transitions until spec coverage, validation, and evidence requirements are met.
Its thesis is that AI can generate the implementation but cannot guarantee that every requirement was covered or every acceptance criterion has evidence, so the workbench turns product intent into a governed pipeline (stories, ideation, refinement, spec, sprint, tasks, tests, bugs) and refuses to let work reach done without proof.
What it is #
pip install okto-pulse starts one Python process serving a web UI and API on port 8100 and an MCP server on 8101, with all state local under ~/.okto-pulse/ in SQLite plus an embedded graph database.
The same vendor ships a sibling product, Okto Nexus (
okto-nexus 0.3.2 on PyPI, under the same Elastic License 2.0 plus SaaS/Branding Addendum): a local-first MCP coordination hub where agents in one repository get durable identities, presence, messages, inboxes, handoffs, artifacts, an event log, and governance controls without a cloud broker.
The platform page now lists a third product alongside them, Okto Neuron (formerly Marginalia, 0.3.1, Elastic-2.0 source-available): a local-first knowledge-graph memory that extracts claims from Markdown notes and serves them over MCP with byte-range citations.
One
okto-nexus serve port exposes the whole hub (streamable-HTTP MCP at /mcp, operator REST and SSE, and a bundled React dashboard) over a SQLite database in WAL mode; its work dispatch is single-winner (handoffs with atomic claim, leases, rejection, cancellation, optional verification, and optional dependency graphs, all behind opt-in feature flags), harness integration adds eight runtime tools beside memory’s three, and the README’s R4 execution status leaves final G0 to G3 acceptance open, with four adapter catalog entries explicitly not four qualified native integrations.
The architecture splits into okto-pulse-core, which owns the SDLC domain, the governance gates, and knowledge-graph contracts as pure protocol seams, and okto-pulse, which supplies every concrete mechanism (SQLite, the Okto Grafx graph engine, the filesystem, scheduler, and MCP host); an unfilled slot fails closed rather than silently defaulting.
The gates cover resource readiness, spec coverage across acceptance criteria, requirements, business rules, API contracts, decisions, and test scenarios, plus task validation, test evidence, architecture findings, and sprint closure.
Tasks cannot start until the parent spec has the required scenario coverage, done transitions are held while unresolved issues remain, and test cards require evidence before being marked passed or failed.
An embedded knowledge graph keeps decisions, constraints, bugs, and learnings queryable with provenance across sessions.
Status #
Active and young: 52 stars (as of 2026-10-14), 2 forks, and 20 open issues as of 2026-11-05, created 2026-04-22, last pushed 2026-11-02, current PyPI version 0.4.2 (2026-10-28). The star count halved in three days (110 on 2026-10-07 to 52 today) while the repository kept being pushed, the signature of a GitHub star purge rather than a user exodus, so treat every adoption number in this note as unstable.
No GitHub releases are published (the tags ship without release pages), so the PyPI package is the release channel, and 0.4.2 pins patched Authlib and filelock builds and stops validating the MCP inventory against a fixed count. 0.4.0 is a breaking release: it refuses storage from earlier versions without migration, so upgrading means a fresh installation. The disagreeing-numbers problem shrank on re-verification: the gate counts now agree at 17 across README and product page, and the tool counts nearly do, with the README’s platform table saying 285 MCP tools and the product page saying 280+. The community footprint is thin: a Hacker News search for Okto Pulse returns nothing, so the evidence is the repository and the product site alone.
Strengths #
- The gate model is the point: coverage and evidence are enforced structurally before done, not reviewed after the fact.
- Local-first with no account, SQLite plus embedded graph, and an MCP endpoint that plugs into Claude Code, Cursor, Windsurf, Cline, or any MCP agent.
- The core and community split with fail-closed ports is an unusually clean separation for a young project.
- Spec-driven development and an operational knowledge graph in one tool, so requirements, decisions, and tests stay linked instead of spread across chat history.
Cautions #
- Elastic License 2.0 is source-available, not OSI open source; commercial use is allowed but you may not offer it to third parties as a hosted or managed service.
- Disagreements between the website, README prose, and README tables (gate and tool counts, version) make every volatile number worth re-checking before you cite it.
- Young project (0.3.x) with a single organization behind it, no published releases, and a very small community.
- It governs the coding workflow, not spending: it is not a budget or approval control plane in the Paperclip sense, despite sitting in this category.
Pricing #
Free to run locally with no account. The README describes a possible SaaS edition and a core-and-community split, but no prices are published, so there is nothing to track yet.
Compared to #
- Paperclip: a company-level control plane with budgets, org charts, and approvals; choose Paperclip to run a business of agents, and Okto Pulse to govern the requirements and evidence of one codebase.
- Spec Kit: a lighter spec-driven development toolkit; choose Spec Kit for prompt-and-template discipline and Okto Pulse when you want gates and an audit trail on the transitions.
- beads: a dependency-aware issue tracker for agents; choose beads for the ledger and Okto Pulse when delivery also needs coverage and validation evidence.
Bottom line #
Recommended for teams using coding agents on long-lived codebases who want spec coverage and delivery evidence enforced before work is accepted. Not for teams that need an OSI-approved license, a multi-agent org control plane, or a tool with a large community and stable versioning.
Changes #
- 2026-09-27 - Created.
- 2026-09-29 - Added Okto Nexus as the vendor’s sibling product (a local-first MCP coordination hub, okto-nexus 0.1.10, served from one
okto-nexus serveport, same Elastic license). - 2026-10-02 - Added Okto Neuron as the vendor’s third product (formerly Marginalia, 0.3.1, Elastic-2.0, local-first knowledge-graph memory served over MCP with byte-range citations).
- 2026-10-07 - Added the OktoLabsAI/okto-pulse star history chart to the Status section.
- 2026-10-10 - Recorded the star count falling from 110 (2026-10-07) to 52 while pushes continued, with the caution that the adoption numbers are unstable.
- 2026-10-19 - PyPI reached 0.4.0, a breaking release that refuses prior storage without migration, and okto-nexus reached 0.3.0; the README’s platform table moved to 285 MCP tools while the product page still says 215, and the website still advertises v0.2.6.
- 2026-10-21 - PyPI moved to 0.4.1 (2026-10-20), a patch above the breaking 0.4.0.
- 2026-10-30 - Full re-verification: PyPI reached 0.4.2 (2026-10-28, patched Authlib and filelock pins, MCP inventory no longer tied to a fixed count), okto-nexus reached 0.3.2 on PyPI, the product page caught up to v0.4.2 with 280+ MCP tools (the v0.2.6 lag and the 215-versus-285 disagreement recorded earlier are resolved), and the Nexus README defers its tool count to
tools/list. - 2026-11-05 - Recorded the OktoLabsAI/okto-nexus fold under the vendor-sibling ruling (no separate note): the sibling README now documents single-winner work dispatch (handoffs with atomic claim, leases, rejection, cancellation, and opt-in verification and dependency-graph flags), eight harness runtime tools beside memory’s three, and an R4 execution status that leaves final G0 to G3 acceptance open; PyPI holds at 0.3.2 while the README’s own release table still says 0.3.0, and the sibling repo pushed 2026-11-02.
See also #
- Control Planes Feature Matrix - the category compared on shared rows
- Paperclip - the company-scale control plane this complements
- Veto - the pre-execution tool-call gate, a different enforcement point
- Spec-Driven Development Feature Matrix - the adjacent shelf for spec-first tools
- What Needs Updating When Agents Do the Work - the corpus argument for keeping requirements and evidence current
References #
https://github.com/OktoLabsAI/okto-pulse - README: gates, MCP surface, architecture, licensing, local data layout
https://api.github.com/repos/OktoLabsAI/okto-pulse - stars, forks, issues, push dates as of 2026-10-06
https://pypi.org/pypi/okto-pulse/json - current version 0.4.2 and Elastic-2.0 license metadata (re-checked 2026-10-30)
https://oktolabs.ai/platform/pulse/ - product site: workflow, gate and tool counts, value proposition (re-fetched 2026-10-30, advertising v0.4.2, 17 gates, 280+ MCP tools)
https://oktolabs.ai/platform/neuron/ - the Neuron product page: Marginalia rename, 0.3.1, ELv2, byte-range provenance, five MCP tools
https://github.com/OktoLabsAI/okto-nexus - the sibling product’s README: serve ports, tool counts, SQLite/WAL storage, dashboard, licensing (37 stars after the same purge, pushed 2026-10-10, as of 2026-10-11)
https://pypi.org/pypi/okto-nexus/json - okto-nexus 0.3.2 under Elastic License 2.0 plus the SaaS/Branding Addendum (re-checked 2026-10-30)
https://docs.oktolabs.ai - documentation index: install, quickstart, MCP setup, knowledge graph