about bernstein.run
who
bernstein.run is the project site for bernstein, the open-source governance layer for ai agents (claude code, codex, cursor, aider, gemini cli, and the rest of the adapter registry work out of the box). it is built and maintained by alex chernysh as a solo project, self-bootstrapped, no investor money. the site, the python package on pypi, the npm wrapper, and the docs all ship under apache 2.0. public profiles: github.com/chernistry and x.com/@alex_chernysh.
why this project exists
the short version is in the project readme: i was paying about $400/month in claude bills running three coding agents in parallel and getting nondeterministic merges back. the bill was annoying, the merges were worse. bernstein is the orchestrator i wished i had then - a deterministic python scheduler in front of whichever cli coding agents you already trust, with parallel git worktrees, a quality-gate stage, and an hmac-chained audit log so the run is repeatable and the artefacts are accountable. it is not a magic prompt; it is a scheduler.
what qualifies the voice
concrete signals rather than years-of-experience filler. bernstein ships 53 cli adapters (claude code, codex, cursor, aider, gemini, openai agents sdk, and the rest - see /vs for the comparison index), an hmac-signed audit log, sigstore-style lineage records per artefact, a contextual-bandit router for cheapest-passing model selection, and an mcp server so the orchestrator itself is callable from any mcp client. architectural decisions are public: parallel worktrees over shared state, file-based session store over database, sub-process isolation over in-process plugin loading. the source is on github and the api docs are on readthedocs; the design rationale lives in commit history, prs, and /blog rather than in marketing copy.
how content is sourced
every blog post carries a publish date in its frontmatter and is dated in the visible header. comparisons (the /vs hub, the /why-bernstein decision page, and the per-adapter pages under /vs/<adapter>) cite the upstream project's own documentation as the source of feature claims wherever the claim is about the other tool. where i test a claim myself, i publish the test command in the post body so you can re-run it. numbers on the benchmark page are labelled by source - a simulation with its model and reproduction command linked, or a community-submitted bernstein cost --json run. model prices on /cost link to the upstream price page and carry the date the table was captured.
bias disclosure. i build bernstein, so any claim on this site about bernstein vs another tool is biased by that authorship. i try to keep the bias visible rather than hidden: the benchmark page labels its scheduling figures as a simulation, not measured runs, the /why-bernstein page includes explicit “who this is not for” sections, and the comparison source memo is the /vs hub itself - each comparison page links the upstream tool's docs at the top so a reader can audit the claim against the source. if a comparison reads as marketing rather than as a fair assessment, file an issue on the bernstein repo and i'll either fix the copy or take the page down.
contact
email forte@bernstein.run, github issues on the bernstein repo, or x.com/@alex_chernysh for short notes.