Comparisons

Three layers

• typesafe-sdk: the official low-level Python SDK for TypeSafe models, transport, retries, and API errors.

• pyjev: a Python application layer with typed results, named .pyjev.toml decisions, offline compilation, credentials, CLI behavior, and confidence gates.

• Other higher-level tools: may optimize for a different application, provider, agent, or protocol workflow.

pyjev and jev-cli

This comparison uses tumf/jev-cli version 0.6.2, main commit 980cb98f5f529ba310ce4c7481a55e034b0a0829, reviewed on 2026-09-20. It is a version-qualified snapshot, not a claim about every future release.

Both projects are useful and overlap on direct Jev primitives. They optimize for different layers rather than being interchangeable implementations of one product.

jev-cli retains rich response data where the provider supplies it. pyjev’s result wrappers are a stable Python-facing contract; the distinction is not that jev-cli discards uncertainty.

pyjev and Nasrallah-AL/jev-cli

This is a separate comparison from the tumf/jev-cli section above. It covers Nasrallah-AL/jev-cli, the TypeScript project distributed as npm package jevctl 0.2.3, executable jev, at main commit a1e668164e75d7fc80cc4a51aaeb1d0144d8961f (reviewed 2026-09-25). It is a dated snapshot, not a winner/loser ranking or a claim about future releases.

The useful lesson is the semantic recipe layer and operational UX, not copying the external CLI’s entire product boundary. pyjev keeps named contracts, offline inspection, typed uncertainty, explicit caller policy, and the official SDK transport boundary. Its recipes compose those foundations without invoking handlers or owning provider behavior.

Architecture

A pyjev named decision flows through a validated repository declaration:

.pyjev.toml -> schema/discovery -> offline compile -> Jev/AsyncJev -> typesafe-sdk

The official SDK owns transport, retries, request models, and API error semantics. pyjev adds declaration, validation, result normalization, lifecycle, credentials, and caller policy.

The jev-cli baseline is closer to:

CLI or MCP tool -> provider selection/translation -> HTTP endpoint -> JSON result

That makes it a strong direct shell, agent, MCP, and multi-provider client. It also means it owns provider request translation and compatibility behavior.

When to use which

Use pyjev when you need:

• an embeddable sync or async Python client;

• dependency injection and caller-owned client lifecycle;

• typed results with uncertainty and metadata preserved;

• named decisions reviewed in source control;

• credential-free validation or request previews;

• explicit confidence policy at an automation boundary.

Use jev-cli when you need:

• a standalone generic shell client;

• provider selection across the official service, gateways, or a custom endpoint;

• an MCP server for an agent host;

• its bundled agent-skill installation workflow;

• JSON-first direct request tooling.

For a one-off primitive shell judgment, either tool may fit. The syntax and output overlap there and should not be treated as the strategic distinction.

Exit codes are not interchangeable

pyjev’s exit codes are its own automation contract:

In particular, pyjev exit code 3 means a policy gate failed after Jev returned a valid result. It does not mean the API rejected authentication. Do not use these numbers as if they were interoperable with another jev CLI’s taxonomy.

Why not use the SDK directly?

Use typesafe-sdk directly when you want maximum control and do not need named decisions, pyjev credential ergonomics, shell-safe confidence gates, offline inspection, or pyjev result wrappers. Use pyjev when those application and workflow abstractions make decisions easier to declare, inspect, validate, execute, gate, trace, and reuse.