# Prometheus the code agent: the licence badge and the licence metadata disagree

> Prometheus is a LangGraph multi-agent system that indexes a codebase into a Neo4j knowledge graph and repairs issues through classification, reproduction and resolution agents. The engineering is carefully pinned, the documentation is confident to a fault about its competitors, and two facts a reader needs early are stated in the wrong file or not at all.

**EuniAI/Prometheus** — 🧠 Prometheus: A Knowledge-Graph-Driven 🤖 AI Agent that maps 🗺, understands 🧩, and repairs 🛠 complex codebases — not by guessing, but by reasoning. ⚡

- Repository: https://github.com/EuniAI/Prometheus
- Stars: 1,134 · Forks: 83
- Language: Python
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/euniai-prometheus

## The licence metadata says GPL-3.0 and the badge points at Apache-2.0

Two of the three places a licence can be recorded disagree, and the third does not settle it. The repository's own metadata records GPL-3.0. The badge row at the top of the readme links to the Apache License 2.0 page on opensource.org. A LICENSE file sits at the root of the tree.

That is worth pausing on rather than resolving by assumption. Nothing in the visible text says which of the two applies, whether the badge is simply wrong, or whether the project relicensed without updating the badge. Rather than pick one, treat the licence as unresolved and read the root LICENSE file directly, because a copyleft licence and a permissive one differ in ways that matter if you intend to link against this code or ship it inside something else.

It is an odd place for the ambiguity to sit, since everything else in the packaging is unusually precise. The distribution is named Prometheus with a capital letter, the build backend is hatchling, the version is 1.3.0, and the project requires Python 3.11 or newer. Those are all precise statements. The licence is the one field that has drifted.

## The name collides with a monitoring system, and the readme never says so

A practical problem comes before any technical one. Prometheus is the name of the metrics system that most infrastructure teams already run, of a film, and of a figure from Greek myth, and the readme does not acknowledge any of them. It uses the name for an autonomous coding agent and moves on.

That collision is not hypothetical. Searching the project's name surfaces the myth, the film, the pronunciation, the monitoring tool and its Grafana dashboards, and the agent's own news section is the only place in the file where any of that gets acknowledged, in the shape of a link to a separate curated list of code agent projects. A reader arriving from search has no signal in the readme itself that this is not the metrics stack.

Two details sharpen the point. The distribution name in the manifest is Prometheus rather than something like prometheus-agent, so the name on the package index is the colliding one too. And the leaderboard claim the project leads with is a category inside a leaderboard most people know for something else entirely, which compounds the ambiguity rather than resolving it. Nothing here is a defect in the code; it is a discoverability cost that anyone evaluating the project pays.

## The leaderboard rank is tied to one model in one month

The news section leads with two entries. The first, dated November 2025, states that the agent reached a top 5 and then a top 1 position in the leaderboard category for agents using gpt-5. The second, dated October 2025, points at a separate curated list of code agent projects and research.

Both numbers are real claims with a narrow shelf life. A leaderboard slice is defined by which model the agents are built on, so a top 1 in the gpt-5 category describes a configuration that stops being the frontier as soon as a newer model appears, and it describes November 2025 specifically. As a piece of evidence it says the orchestration worked well with that model at that time, which is genuinely interesting, and it says nothing about any other model or any later date.

The academic backing is more durable. The readme links a paper titled Prometheus: Towards Long-Horizon Codebase Navigation for Repository-Level Problem Solving, published on arXiv in July 2025 under computer science, with eleven authors, several of them known for software engineering research. A preprint describing the method is a better reference for judging the approach than a leaderboard position is, and the file is right to point at both.

## The comparison table asserts four competitors' limitations without evidence

A four-row table sets the project against SWE-Agent, Lingxi, TRAE and OpenHands. Each row has a description of the other system, a list of its limitations, and a column explaining why Prometheus is superior.

The structure is worth reading as a documentation pattern rather than as evidence. The limitation entries are the authors' characterisations of other people's projects: that one system lacks cross-file or cross-repo understanding, that another has limited context retrieval and no persistent knowledge graph, that a third focuses on orchestration rather than reasoning depth, that a fourth operates task by task with weak contextual reasoning. None of these rows links to a measurement, an issue thread or a reproduction, and the first row even opens its limitation list with a dash before continuing. A self-authored comparison of this kind is a claim about the authors' reading of the field, and the underlying systems are all open source and worth checking directly.

The comparisons do reveal what the project thinks its own contribution is. The recurring words are multi-agent collaborative reasoning across files and commits, a unified codebase knowledge graph, long-term memory under the name Athena, and structured code representation. That is a coherent thesis, and it is the same thesis the architecture section describes, which makes the table useful as a statement of intent even where it is not a measurement.

## LangGraph is pinned to 0.2 while LangChain is pinned to 0.3

The dependency list is where the engineering shows, and the pin pattern is unusual enough to inspect. Exact equality pins cover the tree-sitter parser and its language pack, the Neo4j driver at 5.20.0, LangChain at 0.3.27, and LangGraph at 0.2.41. Four provider packages are pinned too, and they do not share a version scheme: the Anthropic and OpenAI adapters sit at 0.3.x while the two Google adapters, one for the generative API and one for Vertex, sit at 2.1.x.

So the orchestration layer is held at a 0.2 release while the abstraction layer above it is held at 0.3. That is a deliberate-looking constraint rather than an accident, and it is the kind of pin that ages: whenever the orchestration library needs a security fix or a new provider feature, this project cannot take it without a coordinated bump of the LangChain line as well.

One dependency carries no bound at all, asyncpg, while the PostgreSQL stack around it is otherwise exact, with the checkpoint library at a floor of 2.0.2 and the ORM pinned at 0.0.24. The rest sit at floors rather than ceilings, including the FastAPI standard extra, the LiteLLM shim, the Docker SDK, the MCP client and the search tool. Ranged floors and exact pins in the same list is a normal outcome of a project that has been patched over time rather than designed from scratch.

## Five async frameworks in the test extra, and the test extra ships in the image

The optional test group is unusual in a way that says something about intent. Alongside the usual pytest and coverage packages it installs pytest-asyncio at an exact version, plus a plugin for Tornado's async framework, one for Trio, one for Twisted, and anyio, with Twisted itself. That is five async models under test, which suggests the suite is meant to hold up regardless of which event loop the surrounding code runs on.

The group also pulls testcontainers at a pinned version, so the tests start real containers rather than fakes. For a system whose unit of work is a knowledge graph plus a Postgres checkpoint store, that is the right instinct: an in-memory substitute would not exercise the queries that actually matter.

Where it becomes a deployment question is the Dockerfile, which installs the project with the test extra:

```dockerfile
RUN pip install --upgrade pip \
    && pip install hatchling \
    && pip install .[test]

EXPOSE 9002

CMD ["uvicorn", "prometheus.app.main:app", "--host", "0.0.0.0", "--port", "9002"]
```

So the runtime image carries pytest, coverage tooling, five async plugins and testcontainers, on top of the application. The base is python:3.11-slim with unbuffered output, and the whole build context is copied into /app, which means the tests and documentation travel with the image too. It works, and it is a larger attack surface and a larger image than the application alone would need.

## The Neo4j image carries no tag while the driver is pinned exactly

The compose file is where the defaults are, and two of them are worth reading closely. The database service is declared as image neo4j with no tag, which means it resolves to whatever the registry considers latest, while the Python driver in the manifest is pinned to exactly 5.20.0. A client library held to an exact version against a database that floats is the kind of combination that works until it does not.

Its credentials are the defaults. Authentication is set as the neo4j user with the password spelled out, and the healthcheck authenticates with the same pair. The APOC plugin is enabled, heap memory is given as 6 gigabytes initially and 12 at most, the transaction memory total is capped at 12 gigabytes, and the database transaction timeout is set to 600 seconds. The Postgres service is pinned to version 16 but uses the same style of default password, and both services bind-mount their data directories straight into the working tree.

One thing the compose file gets right is exposure. Neither database publishes a port, so both stay inside the bridge network, and only the application port is published. The healthchecks for both services are real commands rather than a sleep, with an interval, a timeout and a retry count, which is more than most compose files manage.

## Authentication is one environment variable with no default in the file

The application service passes its configuration straight through from the host environment, and the list includes a switch called PROMETHEUS_ENABLE_AUTHENTICATION. It is written with no fallback value, so whether the API requires authentication depends entirely on what the host environment or the example env file supplies. Nothing in the visible file states which way it defaults.

That matters because of how the service is exposed. The application port is published to the host without an interface prefix, and the container command binds the server to all interfaces inside the container:

```yaml
ports:
  - "9002:9002"
environment:
  - PROMETHEUS_ENABLE_AUTHENTICATION=${PROMETHEUS_ENABLE_AUTHENTICATION}
```

So if that variable is unset, an API that can drive automated issue resolution against your repositories may be reachable from the network with no authentication. The dependency list suggests authentication was intended rather than skipped, since password hashing and a JSON web token library are both pinned, and the cross-origin setting is also an environment variable, which means origins are configured the same way.

A second detail sits in the same file. The image installs the Docker command-line client, and the capability list includes Docker-isolated testing and validation, which implies the running service creates sibling containers. In the portion of the compose file that is visible, no Docker socket is mounted into the application service, so that capability has nothing to talk to as configured here.

## Conclusion

Prometheus is worth evaluating if you want issue resolution that reasons over repository structure rather than one file at a time, and the classification, reproduction and resolution split with a Neo4j graph of the codebase is a real design rather than a wrapper around a model. Four things to settle first. The licence is genuinely ambiguous here, with GPL-3.0 in the metadata, an Apache-2.0 badge in the readme and a LICENSE file at the root, so read the root file before you vendor any of it. Authentication is a single environment variable with no default in the compose file, and the API port is published on every interface, so decide that before exposing the container. The Neo4j image carries no tag while the Python driver is pinned to an exact version, so the database can move under you. And the headline leaderboard rank is tied to one model in one month, which is the least durable claim in the file.

## FAQ

### Which licence does the EuniAI Prometheus repository use?

The sources disagree. One records GPL-3.0, the readme badge links to the Apache License 2.0 page, and a LICENSE file sits at the root. Nothing in the visible text says which one applies, so read the root file rather than assuming either.

### What databases does the EuniAI Prometheus stack need?

Neo4j for the unified code knowledge graph and Postgres for state, with checkpointing through langgraph-checkpoint-postgres and the ORM layer on sqlmodel and asyncpg. Both run as services on an internal bridge network in the compose file, and neither publishes a port to the host.

### How does Prometheus decide which agents to run on an issue?

LangGraph state machines orchestrate specialised agents for classification, reproduction and resolution, with graph-based semantic retrieval over codebase structure, AST and documentation, and Docker-isolated testing and validation. The full cycle is described as detect, reproduce, repair, verify.

### What did Prometheus score on SWE-bench?

The November 2025 news entry states it reached a top 5 and then a top 1 position in the leaderboard category for agents using gpt-5. The readme links both the leaderboard and a July 2025 arXiv paper describing long-horizon codebase navigation for repository-level problem solving.

### Which Python versions does Prometheus support?

The manifest requires Python 3.11 or newer, and the container image is built on python:3.11-slim. The build backend is hatchling and the manifest version is 1.3.0, though the repository publishes no GitHub releases to compare that against.

## Sources

- [EuniAI/Prometheus on GitHub](https://github.com/EuniAI/Prometheus)
- [Issues](https://github.com/EuniAI/Prometheus/issues)
- [License: GPL-3.0](https://github.com/EuniAI/Prometheus/blob/main/LICENSE)
- [README](https://github.com/EuniAI/Prometheus/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/euniai-prometheus