For the complete documentation index, see llms.txt. This page is also available as Markdown.

4.1 How Orbit is priced

Most software is priced by how big the buyer is — seats, assets, headcount. Orbit is priced by how a firm uses it. The reason is that two firms of very different sizes can use the platform in nearly the same way, and two firms of the same size can use it completely differently. What determines the value a firm gets — and therefore what it pays for — is not its scale but its maturity in adopting AI into its research process. Pricing follows that.

This matters because it changes who pays what. A large institution just beginning to connect AI to its data may need far less of the platform than a small, AI-native fund running automated workflows across its whole universe. Pricing by firm size would get both wrong. Pricing by usage and maturity matches what a firm pays to what it actually does with the platform — which is both fairer to the buyer and a more honest reflection of value delivered.

Orbit frames that maturity in three stages. They are not rigid tiers a firm is sorted into so much as a description of how firms grow into the platform, and most firms move up the stages over time as AI becomes more central to how they work.

Stage one — connected data. At the first stage, a firm's need is access: it wants the connected, structured data and the ability to ask questions of it, in one place, instead of working across fragmented sources. This is the foundation — the Knowledge Base and the ability to query it. A firm at this stage is putting AI to work on its research data without yet running automated processes over it. Notably, a firm can be large and sophisticated and still be here: many institutions that have already rolled out a general-purpose AI assistant have, in effect, paid the cost of adopting AI but still lack the institutional financial data to point it at. For them, connecting Orbit's data is the missing piece, not the beginning of an AI journey.

Stage two — running the platform. At the second stage, a firm moves from asking to running: it uses the agents and the use-case library, sets workflows to run on their own, and consumes the platform's processing across more of its work. This is where the automate mode from Part 2 comes into its own, and where consumption — the actual work the platform does on a firm's behalf — becomes part of what is paid for, because it reflects how much the platform is doing. How that consumption works is the subject of 4.3.

Stage three — enterprise and private. At the third stage, a firm runs Orbit as core infrastructure: integrating its own internal data at scale, deploying privately where required, and building extensively on the platform with its own logic and workflows. This is the most involved relationship, shaped to a firm's specific environment, data, and requirements — and priced accordingly, because it is the most customised and the most deeply embedded.

These stages map onto the packages described in 4.2, and onto the way consumption is handled in 4.3. The through-line is the progression introduced all the way back in 1.4 — access, ask, monitor, automate, integrate — seen now from the commercial side: a firm pays in line with how far along that progression it is, and the relationship grows as the firm does.

One consequence worth stating plainly: this model is designed so a firm can start where it is. A firm does not have to commit to the deepest, most expensive relationship to begin getting value; it can enter at the stage that matches how it works today and move up as AI becomes more central to its research. The pricing is built to meet a firm where it is on its own adoption curve — the same principle that runs through the whole platform.

Last updated