huiwenhan (@huiwenhan) on X

What it claims

PRAXO-CORE 2.5.0 is a provider-neutral Go agent loop. Models and tools are anything that implement its model and tool contracts. The release adds four things: a reusable conformance suite, stricter virtual-path rejection, an explicit plugin trust handoff, and a published event and compatibility policy. The author, huiwenhan, also lists what the release does not claim.

How it works

Optional adapters translate these into the core contracts: OpenAI-compatible endpoints, Anthropic, Gemini, MCP, OTel, Harmovela, A2A and multi-agent supervision. Tool results, model output and tool names are treated as untrusted input. The final authorization check on a tool call runs in the loop.

pkg/conformance covers VFS backends, memory stores, sandbox runners, event sinks, policy hooks, gateways, models, streaming models, tools and retrievers. conformance.Run executes named checks and returns every failure in one pass, not just the first. The author describes it as an evidence tool, not a benchmark or security certification.

The local VFS now rejects these inputs before resolving a virtual path, instead of cleaning them:

• NUL bytes
• Windows drive-relative paths
• reserved device names
• alternate data streams
• trailing dots or spaces

ValidateTrust only checks that a plugin manifest declares a signature identity and an SBOM path. It does no cryptographic verification. The host product must do all of the following before the framework host starts the payload:

• verify the detached signature
• resolve the trust root
• check rotation and revocation
• match artifact and SBOM digests
• apply SBOM policy
• materialize the artifact
• record durable evidence

The event/OpenTelemetry compatibility policy says event names and payload keys are stable. New types and keys are additive, and consumers must ignore unknown values.

How to use it

The quickstart runs against Ollama or any OpenAI-compatible endpoint:

export PRAXO_BASE_URL=http://localhost:11434/v1
export PRAXO_MODEL=llama3.2
GOWORK=off go run ./examples/quickstart

The author asks embedders to run the conformance checks against their own VFS, memory or sandbox backend. Reports of awkward contracts are the feedback they want most.

Limits

The E2B, Daytona, OpenSandbox and CubeSandbox workspace adapters are evaluation modules. They are conformance-tested offline only and have not been verified against the live services. The RHEOVELA durable-worker example covers result, approval and lease/fencing behavior. It was validated only against a local RHEOVELA server, not a deployed or multi-node setup. HA, leader election, replication/failover and enterprise identity enforcement belong to RHEOVELA-ee.

The author states there is no production case study, external benchmark, independent security review, live workspace-provider validation, or RHEOVELA HA/identity validation. A plugin host that starts successfully does not show that the plugin is trustworthy.