FinRobot ships three generations in one repository, and pip install finrobot gives you the oldest one

Three directories, three agent frameworks, one domain layer

FinRobot is not one codebase that grew versions; it is three projects that share a financial domain layer. finrobot_autogen/ is V0, built on AutoGen, and is the code behind the whitepaper on arXiv. The project labels it educational and not intended for production use. finrobot_equity/ is V1, built on the OpenAI Agents SDK, and is a self-hosted FastAPI web app that turns a ticker into a shareable HTML or PDF report. finrobot_desktop/ is V2, built on PydanticAI with FastAPI and a React/Tauri front end, and is the one the project calls production; it is also hosted at finrobot.ai/v2. A fourth generation, V3 on DeepSeek-Harness, is listed as in development. The practical point is that a bug report, a tutorial or a forum answer about FinRobot can refer to any of these, and code from one does not run in another. Check which directory a piece of advice targets before you follow it.

pip install finrobot installs the educational V0 package

The package on PyPI is the oldest generation. pip install finrobot installs V0, whose source moved into finrobot_autogen/ while the import name stayed finrobot, so existing from finrobot... import ... lines keep working. setup.py maps the finrobot package to finrobot_autogen/finrobot, sets the version to 0.1.5, and also bundles finrobot_equity and its subpackages. Dependencies, however, come only from finrobot_autogen/requirements.txt. The V1 web app has its own finrobot_equity/requirements.txt, which the Dockerfile installs but setup.py does not read, so importing finrobot_equity from a pip install gives you its code without the dependency list it ships with. setup.py also wraps the requirements read in a bare except: if the file is missing it prints a message and installs with an empty dependency list rather than failing. Anyone who runs pip install finrobot expecting the production agent system gets the teaching codebase instead.

Valuation numbers come from Python operators, not the model

The design rule that runs through all three generations is a strict split between computation and narration. Every financial number is produced by pure Python compute operators: DCF, DDM, LBO, WACC, comparable company analysis and Monte Carlo simulation run through deterministic code paths with provenance tracking. The language model handles reasoning, synthesis, explanation and report writing. The project condenses it into three lines:

Numbers are code-calculated.
Narratives are LLM-assisted.
Every output is provenance-tracked.

In the desktop app this shows up in the interface: the DCF table, a ten year forecast, is labelled code-computed, and the paragraph beside it is the LLM reading those numbers back across the three valuation methods. The guarantee covers the figures, not the prose. A paragraph that misreads a correctly computed table is still LLM output, so a reviewer has to compare the narrative against the code-computed values instead of trusting the summary.

A Lead Agent runs a fixed pipeline, then a bull and bear debate

V2 organises its agents as a pipeline under one orchestrator rather than an open conversation. A Lead Agent drives five role based sub-agents for data, analysis, modeling, synthesis and reporting, followed by three debate agents for the bull case, the bear case and the judgment:

User Research Request
        ↓
Lead Agent / Orchestrator
        ↓
Data Agent → Analysis Agent → Modeling Agent → Synthesis Agent → Report Agent
        ↓
Bull Agent ↔ Bear Agent → Judge Agent
        ↓
Traceable Investment Research Output

The output is a research report of 13 chapters with a 12 month price target and its range, a model confidence figure, and the data caveats that the audit operators raised. The stock workspace beside it pulls live market data independently of any AI report and shows it next to the verdict and the DCF, DDM, LBO and comps instruments. Because the debate stage sits after the report agent, the judgment is a review of the pipeline's output rather than a replacement for the deterministic numbers feeding it.

Desktop v0.1.0 runs only on Apple Silicon and is not notarized

FinRobot Desktop v0.1.0, published on 2026-07-07, is distributed as FinRobot_0.1.0_aarch64.dmg for macOS on Apple Silicon (M1, M2, M3 or later). You drag FinRobot into Applications. Intel Mac builds are not available in this release, so an Intel Mac user cannot run the production system from this download at all and has to fall back to V1 or V0, or use the hosted version at finrobot.ai/v2. The app is also not yet Apple notarized, so on first launch macOS may report that it is damaged. The documented workaround is one command:

xattr -cr /Applications/FinRobot.app

This strips the extended attributes macOS attaches to the downloaded bundle so it opens normally. It also means you are overriding the operating system's check on an unnotarized binary, which is a decision to make deliberately on a machine that also holds client or portfolio data.

The Dockerfile serves V1 on Python 3.13 while setup.py stops at 3.11

The Dockerfile at the repository root builds the V1 equity web app, not the desktop system. It starts from python:3.13-slim, installs build-essential so that numpy<2 can be compiled from source on Python 3.13, adds libfreetype6 and libfontconfig1 for matplotlib font rendering, installs finrobot_equity/requirements.txt, then purges the compiler to keep the image small. It must be built from the repository root because the app is imported as finrobot_equity.web_app.main, and it exposes port 8001 with this entrypoint:

CMD ["uvicorn", "finrobot_equity.web_app.main:app", "--host", "0.0.0.0", "--port", "8001"]

The setup.py classifiers, by contrast, list Python 3.6 through 3.11 and both CPython and PyPy. Neither file states a tested range for the other path, so a team installing the pip package on 3.13 or running the container on an older base image is outside what the repository declares, and has to do its own checking.

Releases are tagged per product, not per repository

The two tagged releases map to different directories. v1.0.0, titled FinRobot Equity Research, was published on 2026-03-20 and corresponds to the V1 web app. desktop-v0.1.0, published on 2026-07-07, is the V2 desktop build. The PyPI package carries its own version, 0.1.5 in setup.py, for V0. The last push to the master branch was on 2026-10-24. So the version number you see depends on which product you installed, and a changelog entry for one does not tell you anything about the others. Pin the tag that matches your directory when you report a problem.

Apache-2.0 code with a separate trademark policy

The code is released under Apache-2.0, declared in both the LICENSE file and setup.py, and the project states that all three generations are open source. The repository root also carries a NOTICE file and a TRADEMARK_POLICY.md. Apache-2.0 lets you fork and ship the code, but the presence of a separate trademark policy means redistributing a modified build under the FinRobot name is a question for that policy, not for the code license. The root .gitmodules file shows that part of the tree comes from git submodules, so a plain download of the default branch archive may not contain everything a full clone does.

Editorial conclusion

FinRobot suits analysts and developers who want LLM agents for equity research but refuse to let the model produce the numbers: the DCF, DDM, LBO, WACC and comps outputs come from Python operators. Use the V2 desktop app if you are on an Apple Silicon Mac and accept an unnotarized binary, the V1 Docker image if you want a browser service, and V0 only for learning. Before relying on it, confirm which of the three projects your install path actually gave you and check that its Python version matches.

Frequently asked questions

Official sources

1. AI4Finance-Foundation/FinRobot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases