Renyi is the scripting language of AI agents: the agent writes it, you review it at a glance, and the program can only do what it declares.

Why Renyi

Agents now write most of the code that runs on your behalf. The code they write in today's languages has to be read line by line, or run blind. Renyi is designed around that division of labour: the agent writes, the person reviews, and the language makes the review a glance.

1. What a program may do is in its signature. Every function declares its effects (needs filesystem.read("data"), network.http("api.example")), scoped to a path or a host, budgeted (at most 60 per minute) and guarded (only to). The compiler refuses what is not declared; the runtime admits only that, for the program's dependencies too. The signature of main is the whole program's grant.
2. Every run is evidence. A run can be recorded, replayed offline and reproduced under its manifest (toolchain, code hash, dependencies, grant, arguments, outcome); --explain narrates it in the words the program's author wrote. You know what a run did, as data.
3. Dependencies cannot widen what you allowed. A package's effects are computed from its sources, never written by hand; an update that would let the program do more is refused, not noticed later.
4. The tooling an agent needs is built in. The project map, the semantic diff and the chunks for retrieval by embedding are commands (renyi index, --diff, --chunks), the toolchain is an MCP server (renyi mcp), documentation is syntax (purpose:), and every error carries a fix, so the agent's next attempt is right.
5. Read in one pass, by anyone. Regular English with one spelling per concept, one canonical layout, no exceptions, no null, no anonymous functions, no operator overloading. A reviewer who has never seen Renyi reads what a program touches from its signature.

public function active_adult_emails(path: Path)
  returns List of Email
  or fails with FileError or JsonError
  needs filesystem.read
  purpose: Read users from a JSON file and return the e-mails of active users who are at least 18.

  let text be filesystem.read_text(path) otherwise fail
  let users: List of User be json.parse(text) otherwise fail
  let emails be
    for each user in users
    where user.is_active and user.age is at least 18
    sorted by user.name
    collect user.email
  return emails
end

Renyi is a general-purpose language; its first users are people who run automation with Claude Code, Codex and their like, and will not run an agent's Python blind. The design record is docs/design/08-positioning.md (decisions AH1 to AH4).

Against the alternatives

Each row is a claim the implementation keeps and the conformance suite tests. The other languages were built for other jobs and do them well; the comparison is for one job, a program an agent wrote and a person must trust.

For a program an agent wrote	Renyi	Python	TypeScript / Deno	Rust	Shell
What it may do, visible before it runs	in every signature, scoped and budgeted, checked by the compiler	not declared; a sandbox limits the whole process	--allow-* flags for the whole process	not declared; the type system is about memory, not effects	not declared
Its dependencies' effects	computed from their sources, locked, refused when they widen	not declared	not declared	not declared	not declared
What a run did	recorded, replayed, reproduced by the runtime	external tooling	external tooling	external tooling	set -x
What an error means	a fix on every diagnostic, by rule	a traceback	a message	a good message, for a programmer	an exit code
Reviewable without training	regular English, one spelling per concept	familiar to programmers	familiar to programmers	expert reading	terse
Speed on integer loops	machine code in the process	CPython	V8	native, the fastest	n/a

Python and TypeScript are the languages agents write best today, and nothing in them says what a script will touch before it runs. Rust gives guarantees about memory and data races at a cost in time and expertise that a script does not repay, and says nothing about effects. Shell is what agents reach for first, and it is the hardest to review of all.

The gap

Between "the agent wrote it" and "I ran it" there is a review that nobody has time for. Sandboxes bound the process from outside and tell you nothing about the program; type systems check shapes, not effects; recordings and audit trails are bolted on afterwards, if at all. Renyi closes that gap inside the language: the effects are types, the grant is a signature, the run is data, and the syntax exists so that a person can check all three in the time it takes to read a function header. That is the whole design; everything else follows from it.

Source files use the .renyi or .ry extension; the two are equivalent.

Install

Every release (decisions AI1 to AI4; v0.1.0 is the first) carries binaries for Linux (x86_64), macOS (Apple silicon) and Windows (x86_64). On Linux and macOS:

curl -fsSL https://raw.githubusercontent.com/renyi-lang/renyi/main/install.sh | sh

On Windows, in PowerShell:

irm https://raw.githubusercontent.com/renyi-lang/renyi/main/install.ps1 | iex

Both verify the archive's checksum; RENYI_VERSION=v0.1.0 picks a version and RENYI_INSTALL_DIR a directory. With a Rust toolchain, cargo install renyi builds the same binary from crates.io, and cargo install --git https://github.com/renyi-lang/renyi renyi from the repository. The VS Code extension (syntax highlighting and the client of the language server, renyi lsp; editors/vscode/) is attached to every release as a .vsix. docs/RELEASE.md is the release procedure, and the documentation site is https://renyi-lang.org. An agent starts from starter/ (decision AI3): a skill file, the MCP configuration and five workflows that do real work, with their tests and recordings. The MCP registry lists the toolchain as mcp-name: org.renyi-lang/renyi.

Status

The design is complete (M0); the front end (M1), the type and effect checker (M2), the project map (renyi index), the VM (M3) and packages (the first slice of M4, decision AC1) exist. What exists:

• docs/design/01-decisions.md: every design decision taken so far, with the reasoning.
• docs/design/02-syntax-sketch.md: the concrete surface those decisions produce; docs/design/04-stdlib-sketch.md: the prelude and the standard library modules, which also exist as declaration files under library/std/.
• docs/design/03-readability-test.md: how LLM comprehension of the grammar is measured (the grammar is frozen by decision V11); the harness and the rounds are under tests/readability/.
• docs/design/05-agent-tooling.md: the project map (renyi index) and the renyi mcp server for agents, both of which exist; docs/design/06-runtime-guarantees.md: recorded and replayable runs, budgets in grants, provenance guards; docs/design/07-system-design.md: the trade-offs the language claims to resolve, capability-safe packages, reproducibility, in-process sandboxing and checked live update.
• docs/cheatsheet.md: the whole language on one page, kept under 3000 tokens (python3 tools/count_tokens.py).
• docs/grammar.ebnf: the formal grammar of the syntax level, W3C EBNF over the lexer's tokens; a test in the syntax crate interprets it and checks that it accepts exactly what the parser accepts.
• docs/reference.md: the language reference, normative: one section per construct with the grammar excerpt, the meaning, the static rules with their diagnostic codes and the run-time behaviour; a test holds its excerpts to the grammar file and its list of diagnostic codes to the crates.
• examples/: thirty example programs, checked by python3 tools/lint_examples.py.
• compiler/: the compiler written in Renyi itself, run by the Rust VM: the syntax tree as Renyi types (whose derived JSON is what renyi parse --json prints), the lexer, the parser, the type and effect checker and the bytecode emitter; renyi run compiler/parse.ry <file> prints the same tree and the same diagnostics as renyi parse --json <file>, byte for byte on every program of the corpus, the conformance suite, the library and the compiler itself, renyi run compiler/checker.ry --json <file> prints the same diagnostics as renyi check --json <file>, with and without --strict, on every program of the corpus, the conformance suite and the compiler itself, and renyi run compiler/compile.ry --to <file.ryc> <file> writes the same bytecode file as renyi compile, byte for byte, on the same programs; a test holds all three pairs equal.
• crates/: the Rust toolchain. renyi check reports lexer, parser, type, effect and layout diagnostics as text or JSON, each with a suggested fix; renyi format rewrites files in the canonical layout; renyi tokens and renyi parse [--json] dump the token stream and the syntax tree; renyi index [--json] prints the project map: one record per definition with its signature, purpose, declared and transitive effects and failures, edges, metrics and content hash, renyi index --diff <map or revision> what changed since a saved map or a git revision, per definition, with what each change reaches and the version bump it forces, renyi index --chunks the map's modules and definitions as chunks for retrieval by embedding (JSON Lines: an id that changes exactly when the text does, the text, the metadata); renyi run checks a program and runs its main on the bytecode VM under the grant main declares, narrowed by --deny, --allow-host, --allow-read, --allow-write and --at-most, and inside each function by that function's own needs (the grant stack of decision Q1); renyi record writes a recording of every effect of a run with the run manifest in its header (--redact keeps a secret out of it), renyi run --replay re-executes one offline, renyi reproduce replays one under its manifest and compares the outcome and the output, --explain narrates a run through the purpose: clauses it passes, and --profile reports where its time went; renyi serve --watch runs a service and, when a file of its project changes and the program checks clean, runs main again between two requests with the listening socket kept open (decision AO1); renyi run --sandbox grant.json runs a program under a grant narrower than its main declares, with a memory budget, and a Rust host loads a module the same way through renyi::Sandbox and calls its public functions (decision AP1), and a C host, or a Python one through bindings/python/renyi.py, through the library renyi_c with the values as JSON texts (decision AW46; the guide is docs/embedding.md); the VM generates machine code for the hot code objects inside the binary (decision AG1: integer loops run in registers, an Integer that leaves the machine word goes back to the interpreter, which has the big ones), and --interpret keeps a run on the interpreter; renyi test runs every example: line and test block, a replays test from its recording (--strict, --refresh); renyi compile writes a program as a bytecode file (.ryc, the derived JSON of the types of compiler/bytecode.ry), which run, record, test and reproduce load in place of the source; renyi bind <header.h> --module <name> --library <names> writes a foreign module from a C header (decision AF1) and renyi bind --python <package> a Python module from a package (decisions AM1 and AM2); renyi add, update [--accept-effects], audit, fetch and publish manage a project's dependencies (decision AC1: renyi.json names them and a registry, a directory or a URL; renyi.lock.json pins each version's hash; every package's files are verified against their hashes and its effect manifest recomputed from its sources, so a package cannot understate what it does, and a version whose effects widen is never taken silently). Every example checks cleanly, is in canonical form, and its examples and tests pass, the five that reach the network and the one on SQLite from recordings under examples/fixtures/; the ten programs with a reference output print it. The VM covers the whole library: the prelude, console, environment, time, random, filesystem, JSON, CSV, regular expressions, the HTTP client (ureq), the HTTP server (over std::net), SQLite (rusqlite, compiled in) and other programs (std.process, decision AE1), the screen a frame loop draws on (std.screen, decision AW31), C libraries through foreign modules (decision AF1; renyi bind writes one from a header) and Python modules through the bridge (decisions AJ2, AJ3 and AL1 to AL4; renyi bind --python writes one from a package, AM1 and AM2; the guide is docs/python.md); run concurrently runs its tasks one after the other (decision S2); the binary allocates through mimalloc (decision X6). bench/ holds six benchmarks, four of them with CPython twins, and tools/bench.py times them (decision AG4; CI prints the numbers).

cargo build
./target/debug/renyi check examples/hello.ry
./target/debug/renyi check --json examples/hello.ry
./target/debug/renyi format --check examples/*.ry
./target/debug/renyi index examples
./target/debug/renyi index --diff HEAD examples   # what changed since the last commit, and the version bump
./target/debug/renyi run examples/hello.ry Renyi
./target/debug/renyi run --explain examples/statistics.ry 2 4 4 4 5 5 7 9
./target/debug/renyi run --profile compiler/parse.ry compiler/parser.ry   # where the VM's time goes
./target/debug/renyi run --interpret bench/primes.ry   # the interpreter alone; by default the hot code runs as machine code
python tools/bench.py target/debug/renyi              # the benchmarks of bench/, with --interpret, from their images and against CPython
./target/debug/renyi record --to hello.json examples/hello.ry Renyi
./target/debug/renyi run --replay hello.json examples/hello.ry
./target/debug/renyi reproduce hello.json
./target/debug/renyi test examples/invoice.ry
./target/debug/renyi compile --to hello.ryc examples/hello.ry && ./target/debug/renyi run hello.ryc Renyi   # from the bytecode file
./target/debug/renyi mcp examples        # the toolchain for an agent host, over standard input and output
(cd tests/conformance/packages/project && ../../../../target/debug/renyi audit)   # a dependency's effects against every main
./target/debug/renyi run compiler/parse.ry examples/hello.ry   # the parser written in Renyi, on the VM
./target/debug/renyi run compiler/checker.ry --json examples/hello.ry   # the checker written in Renyi, on the VM
./target/debug/renyi run compiler/compile.ry --to hello.ryc examples/hello.ry   # the compiler written in Renyi, on the VM
cargo test

Release 0.4.0 (2026-10-15) is the stable version (decision AW67): the effects of a function value where it is bound, stored or returned (AW60, AW61), a type in parentheses (AW62, AW63), the memory budget written in the program (AW64 to AW66), the liveness walk's residue on both sides (AW67) and the C archive's static library without the bitcode of fat LTO. Release 0.3.0 (2026-10-15) adds the C API (decisions AW46 to AW48: the crate renyi_c, the Python binding and a library archive per target) and fixes a Windows path in the embedding API. Release 0.2.1 (2026-10-14) fixes the scope of the current directory, filesystem.read("."), which refused every relative path, and lists the toolchain on the MCP registry. Release 0.2.0 is out (2026-10-13; the procedure in docs/RELEASE.md, decisions AI1 to AI5 and AW36; the extension is on the Visual Studio Marketplace and Open VSX as renyi- lang.renyi). Between 0.1.0 (2026-10-07) and it came the registration API for Rust natives (decisions AJ1 and AK1 to AK4; docs/extensions.md), the Python bridge (decisions AJ2, AJ3 and AL1 to AL4; docs/python.md), the resident world, the language server with completion, references and rename, the watch of serve and the embedding API (M5, decisions AN1 to AP2, AW38, AW39 and AW44), the rounds on the VM's speed and the front end's (decisions AQ to AU, AW1 to AW27), the toolchain for the browser with the play page and the showcase game (decisions AW29 to AW37), and the chunks for retrieval by embedding (decisions AW40 to AW43). docs/ROADMAP.md is the map of every stage, numbered and grouped by track, with what comes next (the C API of decision A5 is the next stage of AW28's order, not opened).

Working on this repository

CLAUDE.md holds the conventions for Claude Code sessions and docs/HANDOFF.md the current state and next steps; start there.

License

Apache-2.0. See LICENSE.