Most coding agents optimize for producing a plausible answer quickly. Kryptic is built around a different question: can the result be verified, repaired, and safely rolled back on the user’s machine?
Kryptic is a local-first, open-source Node.js CLI for AI-assisted engineering work. It runs in a bounded workspace and keeps the execution loop explicit:
- Plan the requested change.
- Act through constrained tools.
- Verify with real execution results.
- Repair only when verification identifies a concrete failure.
- Stop with an auditable result.
The important distinction is that verification is not model prose. A model can say that a test passed; Kryptic treats the command’s exit status, captured output, resulting diff, and workspace state as the evidence. If the evidence is missing or contradictory, the step is not complete.
Safety boundaries
The current release includes several defensive choices intended to make failures recoverable rather than mysterious:
- Direct process execution instead of passing commands through a shell.
- Literal patch replacement to avoid broad or ambiguous file corruption.
- Workspace and secret-file boundaries.
- Approval-gated edits and transactional rollback.
- Path revalidation before rollback operations.
- Provider timeouts and interrupted-run resume.
- An origin-restricted browser bridge with optional token authentication.
- A guided first-run setup that stores provider secrets in a protected user-level file.
These controls are deliberately less glamorous than a confident agent transcript, but they make the system easier to inspect and test.
Reproducible evidence
Kryptic currently has 42/42 regression tests, 11/11 deterministic benchmark cases, and 11/11 offline-demo checks in the local release workflow. Those numbers describe Kryptic’s own checks; they are not fabricated cross-agent comparisons. The comparative task definitions are published so that future evaluations can use the same fixtures and report failures honestly.
The project also includes an offline demo that requires no API key. It exercises the plan–act–verify–repair shape without depending on a hosted service, which makes it useful for first-run testing and CI.
What I’m looking for
I’m interested in feedback from developers who build or use coding agents. In particular:
- Which safety boundaries are missing or too restrictive?
- What verification fixtures would make agent comparisons fair?
- Which failure cases should be included in a public benchmark?
- Does the first-run setup explain the local-first model clearly?
Kryptic is early, and I’m not claiming it is universally better than other agents. The goal is narrower and more measurable: make engineering agents prove what they changed, show how they verified it, and recover transactionally when the first attempt fails.
Repository: https://github.com/adnqcr7-code/kryptic
Top comments (0)