Runsight
Runsight is an open-source, self-hosted workflow engine that turns AI agent pipelines into plain YAML files versioned in Git. It tracks cost per block, enforces hard budget caps and runs built-in assertions on every output.
What is Runsight?
Runsight is a workflow engine for AI agents whose single source of truth is a YAML file sitting on your filesystem. The pitch is deliberately narrow: workflows are files, your repository is the database, and Git is the version control. Nothing lives in a vendor cloud, because there is no vendor cloud.
A workflow is a directed graph of blocks. Six types are available: linear for a single LLM call, gate for an LLM quality check that routes on pass or fail, code for plain Python, loop for bounded iteration, workflow for nesting a child flow, and dispatch for parallel branching where each exit port gets its own agent. Blocks call souls, the reusable agent identities that carry a role, a system prompt, a provider, a model and a temperature, stored either as their own YAML files or inline. Three tools ship built in: delegate, which lets the model pick the next branch, http for outbound requests with SSRF validation, and file operations. Custom tools are declared as YAML with a Python or HTTP executor.
The interface is a pair of synchronised views. A ReactFlow canvas and a Monaco YAML editor edit the same state, and the canvas layout lives in a separate JSON sidecar the engine never reads, so hand-editing the YAML never breaks your diagram. Saving writes to disk, committing writes to Git, dirty runs automatically spawn simulation branches, and every run is tied to a commit SHA.
Two capabilities go beyond the typical agent builder. Budget enforcement sets cost, token and duration ceilings per workflow and per block, in either warn or kill mode. Evaluation is built in, with fifteen deterministic assertion types, transform hooks and an offline test harness that runs on fixtures without spending anything on model calls.
It is released under Apache 2.0 and installs with a single uvx runsight, a Docker image, or from source. Eleven provider types are supported, local models through Ollama included, and a REST endpoint can trigger any committed workflow that has been explicitly enabled.
What it does
- Define AI agent workflows as plain YAML files on disk
- Version, diff, branch and review those workflows in Git
- Track LLM cost and latency block by block on every run
- Enforce hard cost, token and duration caps that kill a run before it overspends
- Evaluate outputs with built-in assertions and regression tests
- Pause, resume or kill an agent mid-execution
- Compose loops and nested sub-workflows for multi-step orchestration
When to use Runsight / When not to
A quick filter to help you decide if Runsight is the right fit.
When to use Runsight
- Engineering teams that want agent workflows reviewed in pull requests like any other code
- Organisations whose API keys, prompts and outputs must never leave their own network
- Teams that need hard, enforceable cost ceilings on every LLM call rather than a dashboard after the fact
- Developers who want assertions and regression tests instead of eyeballing agent output
- Python-comfortable builders already working daily with Git and the command line
When not to use Runsight
- Anyone expecting a hosted service, since there is no cloud offering and you install and run everything yourself
- Non-technical users, because every workflow is authored in YAML and Git is a hard requirement
- Teams that need a signed DPA, a privacy policy or contractual terms before they can adopt a tool
- Buyers who require a named, contactable vendor with documented support commitments
- Anyone needing a mobile app, a browser extension or a production-ready authenticated API today
How to use Runsight
A typical end-to-end flow, from setup to results.
- Install Python 3.11 or later together with uv, and make sure Git is present in your environment
- Run the single command uvx runsight from the directory you want as your workspace, or start the Docker image instead
- Let Runsight scaffold the project: it initialises a Git repository and creates the custom/workflows, custom/souls, custom/tools and .runsight directories
- Open localhost:8000 in your browser
- Add at least one LLM provider under Settings, paste your API key and wait for the automatic connection test to pass
- Create a workflow, either by writing YAML in the Monaco editor or by dragging blocks onto the visual canvas
- Define a soul for each step, giving it explicitly both a provider and a model name, since there is no default fallback
- Add a limits section with a cost cap so that a runaway agent cannot overspend
- Click Run and watch each block execute, with cost and latency accumulating in real time
- Commit the workflow to Git so that the run history is tied to a commit SHA
Pros & Cons
Pros
- Completely free and open source under Apache 2.0, with no paid tier of any kind
- No vendor lock-in by design, since the YAML stays readable even without the tool
- Self-hosted, so API keys, prompts and outputs never leave your own network
- Cost control is unusually granular, with enforceable caps per block that stop a run before it overspends
- Evaluation is built in, replacing the widespread looks-good-to-me test with assertions and regressions
- Installs in a single command, with no signup and no cloud account
- Dense technical documentation that goes as far as API contracts and architecture decision records
Cons
- The self-hosted API is unauthenticated today, so securing any non-local deployment is entirely your responsibility
- No privacy policy, terms of service, DPA or sub-processor list is published anywhere on the site
- The publisher is anonymous: no company is named, no address or email exists, and the GitHub organisation has no public members
- The visual canvas is still marked alpha, and budget limits have no user interface at all
- Workspace isolation is explicitly not a hard OS sandbox, with no namespaces, cgroups or seccomp
- Very young project, with the domain and repository both created in March 2026 and the current release still at 0.5.10
- Real technical prerequisites, since Git is mandatory and building from source also needs Node 20 and pnpm
Pricing & Plans
Runsight is free of charge in its entirety. The software is distributed under the Apache 2.0 licence with no paid tier, no subscription and no commercial edition, and the site publishes no pricing page at all. There is therefore no entry price point to report. The only cost borne by the user is that of the LLM provider calls the workflows make, which are billed directly by those providers and never by Runsight. Running local models through Ollama removes even that expense, since no API key is required.
- free
- self-hosted under the Apache 2.0 licence
- with every feature included and no paid tier
- distributed through PyPI
- a Docker image and the GitHub sources
Data, GDPR & hosting
A consolidated view of how Runsight handles your data.
GDPR overview
There is no mention of the GDPR anywhere on the site. A full-text and archived-HTML search across every collected page returned no occurrence of GDPR, data protection, DPA or sub-processors, and the sitemap confirms that no privacy policy, terms page or legal notice exists at all. No data protection officer is named, no Article 27 representative is designated, and no contact address of any kind is published. This silence is coherent with the model rather than negligent: the software is self-hosted, so the publisher never receives your data and never acts as a processor of it. The practical consequence is that GDPR responsibility falls entirely on you, as the operator of the deployment and as the party contracting directly with the LLM providers you choose to configure.
Who owns the data?
Runsight publishes no terms and conditions and no privacy policy, so no contractual statement of data ownership exists anywhere. In practice the architecture answers the question: the software runs entirely on your own machine or container, and every workflow, agent definition and tool file is a YAML file inside your own repository. Run history sits in a local SQLite database at .runsight/runsight.db, and API keys are stored as environment-variable references pointing at .runsight/secrets.env, a file that is gitignored and never committed. There is no account and no signup, so the publisher receives nothing and can claim nothing over your data.
Reuse rights
No terms of use are published, so nothing contractual restricts what you may do with the data your workflows produce. Because the engine runs locally, outputs stay in your own files and database and never pass through a publisher service. The software itself is released under the Apache 2.0 licence, which permits commercial use, modification and redistribution. The model calls go out to whichever LLM providers you configure with your own keys, so the reuse terms that genuinely bind you are those of OpenAI, Anthropic, Google or whichever provider you connect. Runsight adds none of its own on top.
Data retention & training
Hosting summary
There is no publisher-side hosting to describe: Runsight runs wherever you install it, so the jurisdiction is whichever one your own machine or container sits in. Workflows, agent definitions and tool files stay in your working directory, which defaults to the current folder and can be moved with the RUNSIGHT_BASE_PATH variable, or to /workspace under Docker. Run history goes into a local SQLite database at .runsight/runsight.db. Provider configuration files are committed to Git, while the secrets file holding the API keys and the application settings file are both gitignored. The marketing site itself is served from behind Cloudflare on an anycast address, but that concerns the public pages only, never your data. The one flow that does leave your infrastructure is the model call: prompts travel to whichever LLM providers you configure, under their own regions and their own terms, and Runsight documents nothing about where those providers process them. No hosting country or region is declared anywhere on the site, which is coherent for a self-hosted engine.
Things to keep in mind
Risks and trade-offs to weigh before adopting Runsight.
- Exposing port 8000 beyond localhost without adding your own proxy and authentication hands workflow execution to anyone who can reach it
- Code blocks execute arbitrary Python, and the Unix-local isolation is explicitly not a hard security sandbox
- The built-in http tool can reach any URL unless you configure a host allowlist, which makes prompt injection a genuine exfiltration path
- With no terms, privacy policy or DPA published, there is no contractual recourse and no vendor to hold accountable
- Watching a per-block cost display is not the same as setting a cap: limits are opt-in and easy to forget on a new workflow
- Automating judgement into gate blocks can quietly replace reviewing agent output with trusting an assertion that only checks the obvious
- A project this young, with 37 releases in six weeks, can change its API surface faster than your workflows can follow
Setup & Integrations
Technical difficulty
Moderate, and honest about it. The fast path really is one command, uvx runsight followed by a browser on localhost:8000, but it assumes Python 3.11 or later, uv installed, and Git present, without which saving and committing fail outright. Docker is an equivalent one-liner provided you handle port publishing correctly. Building from source is heavier, adding Node 20, pnpm and two terminals. Before the first run you must configure a provider and give every agent an explicit provider and model name. Comfort with YAML, Git and a terminal is assumed throughout.
Deployment
Integrations
Behind Runsight
Resources
All the official URLs gathered for verification and reference.
Frequently asked questions
How much does Runsight cost?
Do I need to create an account?
How do I install it?
Does my data leave my machine?
Is there an API?
Is that API secure?
Which models can I connect?
Is Git really mandatory?
How do I stop an agent from overspending?
Where do I get support?
Should you pick Runsight?
Runsight makes an unusually clear bet: agent workflows are code, so they should live in your repository and be reviewed like code. Everything follows from that. The YAML file is the source of truth, the canvas is only a view of it, saving writes to disk and committing writes to Git. If the project disappeared tomorrow you would still hold readable configuration files, a claim the site makes explicitly and one the architecture supports.
Two things set it apart in a crowded field. Cost enforcement is real rather than decorative: caps apply per workflow and per block, and can kill a run rather than merely warn about it. Evaluation is built in, with fifteen deterministic assertions, transform hooks and an offline harness that costs nothing to run. Together they address the two complaints that usually follow an agent project into production, namely surprise bills and untestable output.
The reservations are just as clear. This is a very young project: the domain and the repository were both created in March 2026, the current release is 0.5.10, the canvas is marked alpha and budget limits have no interface. The self-hosted API is unauthenticated, which is acceptable bound to localhost and dangerous anywhere else. Most significantly for anyone evaluating it inside an organisation, the publisher is anonymous, with no company named, no address or email published, no terms, privacy policy or DPA, and a GitHub organisation listing no public members. For an Apache 2.0 project you install and inspect yourself that matters less than it would for a hosted service, but it will not clear a formal procurement review.
For a developer or platform team comfortable with YAML, Git and the terminal, wanting cost and quality control over agent pipelines without sending anything to a third party, Runsight is worth an afternoon.
- Choosing a selection results in a full page refresh.
- Opens in a new window.