# Eve: Eden's Python Core for Building Autonomous Creative Agents > Eve is the repository behind Eden.art's creative AI assistants, providing a tool ecosystem and a price-management system for autonomous digital artists. This review covers its architecture, setup, and the practical constraints of its cost-control workflow. **edenartlab/eve** — Eden is building autonomous creative agents. - Repository: https://github.com/edenartlab/eve - Website: https://www.eden.art/ - Stars: 31 · Forks: 7 - Language: Python - License: not declared - Published: 2026-08-23 · Updated: 2026-08-23 · Language: en - Canonical page: https://hysenlabs.com/projects/edenartlab-eve ## What Eve Actually Provides Eve is not a finished product. The README opens with an under-construction warning and says the repository is under heavy active development. What it does provide is the core codebase for Eden.art's autonomous creative agents. These agents understand natural conversation, create visual content, and iterate on it. The flagship example is the Eve assistant on app.eden.art, which uses a suite of open-source AI tools. The target user is a developer who wants to build a custom digital artist, not an end user who wants to generate images. The repository gives you the scaffolding to define tools, manage their costs, and run them against a graph database. It is a foundation, not a turnkey application. ## How the Agent Architecture Fits Together The README does not describe a full agent loop, but it reveals the data flow. Eve relies on a suite of open-source AI tools, and it integrates with two companion repositories: eden_comfy_pipelines for production-ready ComfyUI nodes, and workflows for in-production ComfyUI workflows. These are the tools that the agent calls. The agent itself lives in this repo, and it uses FalkorDB as its database. FalkorDB is a graph database, which suggests the agent stores state as a graph, likely for tracking conversation context or tool dependencies. The tool pricing section shows that each tool has an api.yaml file with a cost_estimate field. That file is the single source of truth for a tool's price. When a tool is invoked, the system reads that price and charges against it. The architecture is modular: tools are defined in YAML, priced in YAML, and synced to a MongoDB collection called tools3. The agent does not hardcode prices. ## Getting Eve Running Locally The only concrete setup instructions in the README concern FalkorDB. You start a local instance with docker compose up falkordb. The default port is 6380 on the host, mapped to the container's 6379. The web UI is on localhost:8380. Authentication is disabled by default. If you enable credentials on a remote instance, you set FALKORDB_USERNAME and FALKORDB_PASSWORD in your shell. To verify the database is reachable, use redis-cli -h localhost -p 6380. You can override host and UI ports with FALKORDB_PORT and FALKORDB_WEB_PORT. The README does not mention installing Python dependencies, running a server, or any other startup command. That is a gap. The wiki is referenced as the place to get started, but the README does not link directly to it. You are expected to read the wiki for the rest. ## The Tool Pricing System Is the Most Concrete Feature The pricing mechanism is the most detailed part of the README, and it is the strongest signal of how Eve is meant to be operated. A tool's price lives in exactly one place: the cost_estimate field of its api.yaml. To change a price, you edit that line and merge the PR. CI then writes the new value to the tools3 collection in MongoDB, which production charges against. The command make price TOOL=flux_dev shows the current price and checks whether the repo agrees. make price checks every tool. make price-check fails if the repo and PROD disagree, and it runs in CI on every PR. There is also eve tool price-check as a required check against PROD, and eve tool price-sync --db PROD pushes repo prices to the database. This is a serious attempt to keep costs in sync across repositories and environments. It is a concrete workflow that you can test and rely on, unlike the rest of the agent behavior which is undocumented. ## Limits and Failure Modes in the Pricing Design The pricing system has deliberate edge cases that you must understand before trusting it. Prices are inherited. A tool with parent_tool and no cost_estimate uses its parent's price. The command eve tool price tells you which file the number actually came from, which is useful but also means a tool can silently change price when its parent changes. Some tools exist only in the database, such as retired workflows. Syncing never deletes those keys. They are listed in eve/db_only_tools.yaml. A database tool that is not listed there and not in a repo fails the check. Tools live in three repos: eve, workflows, and private_workflows. A repo that is not checked out is reported as UNCHECKED and its tools are skipped, never treated as deleted or unpriced. That is a safe behavior, but it also means you can get a green CI without actually knowing the price of a tool from an unchecked repo. STAGE is deliberately not a required check, because it carries in-development tools with experimental prices. This design is conservative, but it can hide drift in non-production environments. ## A Real Alternative: Building Directly on ComfyUI If Eve is too immature for your needs, the obvious alternative is to skip the agent layer entirely and build directly on ComfyUI. The README points to eden_comfy_pipelines, which provides production-ready ComfyUI nodes. ComfyUI itself is a node-based interface for running Stable Diffusion workflows. It does not have a natural language interface or autonomous iteration. You would have to write your own orchestration code to connect user prompts to workflow executions. Eve's value is that it wraps those workflows with an agent that can reason about them and manage costs. If you do not need autonomous decision-making, using ComfyUI directly gives you full control and avoids the under-construction risk of Eve. The trade-off is that you lose the pricing enforcement and the pre-built agent behavior. The alternative is not a drop-in replacement; it is a lower-level foundation that you would have to assemble yourself. ## Maintenance Cost and License Uncertainty The repository is under heavy active development, which means frequent changes. That is a maintenance cost in itself. You cannot assume a stable API. The README mentions that tools live in three repos, so changes to workflows or private_workflows can affect Eve's behavior. The pricing sync system is designed to reduce maintenance burden by automating price updates, but it adds its own complexity: you must maintain the db_only_tools.yaml list and ensure all three repos are checked out in CI. The license is listed as unknown. No license file is mentioned in the README. That is a red flag for adoption. Without a clear license, you cannot legally reuse the code in your own project without asking Eden directly. The README invites you to contribute tools and workflows, but it does not state the terms under which the code is available. Before adopting Eve, you should contact the maintainers to clarify licensing and check the wiki for the latest setup instructions. ## Conclusion Adopt Eve if you are building a creative AI agent that needs to call ComfyUI workflows and want a disciplined, database-backed way to track tool costs. Do not adopt it if you need a stable, production-ready API, since the repository is explicitly under heavy development and the license is not declared. Before integrating, verify the current state of the wiki, confirm that FalkorDB is running locally, and review the tool pricing policy to understand how costs are inherited and synced. ## FAQ ### What is eden art? Eden.art is the platform whose creative AI assistants are powered by the Eve repository, which is described as the core repository behind those assistants. They are autonomous digital artists that understand, create and iterate on visual content through natural conversation. ### Where is a tool price stored in the eve framework? In the cost_estimate field of that tool's api.yaml, and nowhere else. To change a price you edit that one line and merge; CI then writes the new value into the tools3 collection that production charges against. ### What happens when an eve tool has no cost_estimate of its own? The price is inherited from the parent named by parent_tool. The command eve tool price with the tool name reports which file the number actually came from. ### How do I run a local graph database for eve? Run docker compose up falkordb. The default host port is 6380 mapped to the container 6379, the web UI is on http://localhost:8380, authentication is disabled by default, and FALKORDB_PORT and FALKORDB_WEB_PORT override the ports. ### Does eve enforce its prices with a required CI check? Yes. eve tool price-check runs against PROD as a required check on every pull request, and eve tool price-sync --db PROD pushes the repository's prices to the database if they diverge. STAGE is deliberately not a required check. ### Which repositories hold eve tools? Three: eve, workflows and private_workflows. A repository that is not checked out is reported as UNCHECKED and its tools are skipped rather than treated as deleted or unpriced. ## Sources - [Official documentation](https://www.eden.art/) - [Official README](https://github.com/edenartlab/eve#readme) - [Project repository](https://github.com/edenartlab/eve) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/edenartlab-eve