Fincept Terminal: The AGPL-3.0 C++20 Desktop Terminal and What It Leaves Out

The Gap Fincept Terminal Targets, and Who It Is Actually For

A Bloomberg seat runs roughly $27,000 a year according to the README's own comparison. That number is the whole pitch. Fincept Terminal is a native desktop application for financial research, built in C++20 with a Qt6 interface and Python 3.11 embedded for analytics, packaged as one binary rather than an Electron shell. Market analytics, investment research and economic data sit in a single window instead of a browser tab farm.

The README splits the audience in two, and it does so bluntly. The repository you are reading is the free AGPL-3.0 edition, described as being for learning, personal use and academic research, shipping one release a month. Enterprise is the private, closed-source build, developed daily, aimed at funds, family offices and research desks. If you are a student or an academic, the open build is the intended target. If the terminal is how you earn, the README says to use Enterprise. That is an unusually direct statement of scope for a project README, and it should be read as a boundary rather than marketing modesty.

One consequence deserves attention before anything else. The open build's stated cost is not zero. The README says its real cost is your own data and LLM bills, charged per token with no ceiling. Free software with an uncapped metered dependency is a different proposition from free software that runs offline.

Two Editions on One Data Core: How the Architecture Splits

The README states that two editions run on one data core. That single sentence explains most of the design. The C++20 and Qt6 application is the shell and the rendering layer; Python 3.11 is embedded for analytics; the data core underneath is shared between the open and closed builds. What differs is what gets wired into that core.

The comparison table makes the split concrete. Data: free public feeds and your own API keys in the open build, against private datasets, deeper history and point-in-time data in Enterprise. AI: bring your own LLM key, against 400 to 5,000 included credits plus multi-agent research and a private dataroom. Trading: paper trading and broker integrations, against live broker routing and live algo deployment. Controls: nothing listed for the open build, against SSO/SAML, audit logs, RBAC and SLA-backed support.

Read those four rows together and a pattern appears. The open build gives you the interface and the analytical machinery. It does not give you the inputs. You supply the data feeds, you supply the model key, and your orders do not reach a broker. That is a coherent position for an academic tool and a poor one for a trading desk, which is presumably the intent.

The repository layout supports the description. A fincept-qt directory holds the Qt application, alongside docs, images, a Dockerfile, setup.sh and updates.json at the top level. The Dockerfile header states that it is a multi-stage, multi-arch build pinning Qt 6.8.3 exactly, GCC 12.3 or newer, CMake 3.27.7, and the modules qtcharts, qtwebsockets and qtmultimedia. It also notes that Windows and macOS native installers are produced by a GitHub Actions workflow on platform runners, and that Docker cannot build those by design.

Installing Fincept Terminal and Running a First Session

The README does not document a source build for end users. It points to the releases page, and the download table lists platform installers for the latest release, v4.4.1. Start there rather than at a compiler.

On Debian or Ubuntu, the README gives the .deb package and a single install command. Run it from the directory holding the downloaded file.

sudo apt install ./FinceptTerminal-*.deb

On Fedora or RHEL the table lists an .rpm package, and on Linux x64 generally there is a .run installer that the README says to make executable and then run. Windows x64 gets a setup executable, after which you launch FinceptTerminal.exe.

chmod +x FinceptTerminal-4.4.1-linux-x64-setup.run

There is also a Docker path, and the Dockerfile header carries the run command. It assumes an X11 host and shares the display socket into the container.

docker run --rm -it --net=host \
  -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix \
  fincept/terminal:4.0.2

Note the tag in that example: 4.0.2, while the current release is v4.4.1. The Dockerfile header is illustrative and not kept in step with the release table, so treat the tag as a placeholder and check what has actually been published.

The README also states that Enterprise needs its own account, and that free Fincept logins do not sign in to it. Expect an account step before the open build is useful. What the README does not document anywhere is the first-run workflow inside the application: there is no walkthrough of configuring a data provider key or an LLM key, no default port, and no environment variable list. The manual link points to an external page rather than the repository. If you need a documented path from install to first chart, the README does not provide one, and that is the largest gap in the onboarding story.

The Licence Question the README Leaves Half-Answered

The README's comparison table lists the open build as AGPL-3.0 with strong copyleft, and the badge row links to a LICENSE file in the repository. The repository entry list confirms that LICENSE exists at the top level. What the README does not contain is the text of that file, so the licence identifier rests on the README's own claim rather than on a verified file. That is a small thing to check and worth checking first.

AGPL-3.0 matters more here than in a typical library. Strong copyleft reaches software offered over a network, which is why the README frames Enterprise as having no copyleft to manage. If you intend to embed this terminal in something you distribute, or to expose a modified version as a service, the licence is the decision, not the feature list. The README states plainly that the open build is for learning, personal use and academic research. It does not offer a separate commercial licence, and it says the Enterprise plans are the whole price list with no negotiated pricing.

Upgrade cost is straightforward on the surface. The open build ships one release a month, and the release history shows v4.3.0 on 2026-07-25, v4.4.0 on 2026-08-11 and v4.4.1 on 2026-08-20. That is a monthly cadence with patch releases in between. Because the application is distributed as prebuilt installers rather than through a package repository, upgrading means downloading a new installer each cycle, and the README does not describe an in-application updater. The presence of updates.json at the repository root suggests some update mechanism exists, but the README does not document it. Do not assume silent upgrades.

Where the Open Build Is the Wrong Tool

The clearest failure mode is stated by the project itself. If you need live broker routing or live algo deployment, the open build does not have it. Paper trading and broker integrations are listed for the open edition; live routing is listed only for Enterprise Pro at $299 per user per month. Anyone planning to point this at a funded account should stop at that row.

The second limitation is data. The open build runs on free public feeds and your own API keys. Point-in-time data, which is what you need to avoid look-ahead bias in a backtest, is listed under Enterprise. A backtest built on restated history will look better than reality, and the free tier is where that risk lives.

The third is the AI dependency. Bringing your own LLM key means token costs scale with use, and the README describes those bills as having no ceiling. A research workflow that fans out across many queries can outrun the price of the software it replaced, which is an odd place to land for a free tool.

The fourth is support and governance. The open build lists no SSO, no audit logs and no RBAC. For a single researcher that is irrelevant. For a team that has to answer who saw what, it is disqualifying, and no amount of C++20 will fix it.

Finally, there is the question of who the open build is for in practice. The README says Enterprise is what the team develops daily and the open build ships monthly. Monthly releases are a real cadence, not abandonment, and the last push on 2026-08-20 is recent. But a monthly snapshot of a product whose primary development happens in a closed branch will always trail the thing it is a snapshot of. Expect to be a consumer of the open build, not a participant in its direction.

Alternatives and the Actual Difference in Approach

The obvious comparison is a browser-based research stack. A Python notebook with pandas, a charting library and a handful of data-provider SDKs covers a large share of what a research terminal does, and it does so in an environment you already control. The difference is not capability, it is packaging. Fincept Terminal is one native binary with a Qt6 interface and embedded Python 3.11, so there is no environment to build, no dependency drift, and no browser between you and the charts. What you give up is the ability to reach into the analytics layer directly; the Python is embedded, and the README does not describe an extension point for it.

The second comparison is a commercial terminal seat. At roughly $27,000 a year for Bloomberg, according to the README's own figure, Fincept Enterprise at $1,188 to $3,588 per user per year is a different order of magnitude. The README is honest that this is not a like-for-like swap: Enterprise offers 41 modules and a 700-page manual, while the open build is a monthly snapshot for learning. The comparison worth making is not open build against Bloomberg. It is open build against whatever you would otherwise assemble yourself, and there the trade is your time and your API bills against a prebuilt interface.

The third comparison is against doing nothing and reading filings in a browser. That is free, and for occasional research it is adequate. Fincept Terminal earns its install when you are doing this daily and want the workspace to persist.

Editorial conclusion

Adopt the open build if you are a student, hobbyist or academic who wants a native C++20 and Qt6 research terminal and is willing to supply your own data and LLM API keys. Do not adopt it if you need live broker routing, SSO, audit logs or point-in-time data, because the README places all of those in the closed Enterprise build at $99 to $299 per user per month. Do not adopt it if AGPL-3.0 copyleft conflicts with how you ship your own code. Verify first whether the repository carries a LICENSE file that actually states AGPL-3.0, since the README table and the licence badge are the only places the term appears in the repository. Verify second that v4.4.1 installers exist for your platform before planning around the monthly release cadence.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes