What AI Actually Costs in Real Estate Workflows

Jun 16 / Thomas Wiegelmann
A recent joke proposed a new metric called EBITTDA: earnings before interest, taxes, tokens, depreciation and amortisation. It works because it names something real. Tokens are not a line item in most accounts and they may never be. But when a team uses AI more often, across more people and more recurring work, token cost starts to become more relevant.

The US news outlet Axios reported that an unnamed enterprise spent around USD 500m on Claude in a single month, after giving employees licences with no usage limits. The figure circulated widely but was never independently confirmed, and the company was never identified, so the number is not the point. The cause is what counts. Consumption ran far ahead of anyone’s view of it. Microsoft and Uber have since hit milder versions of the same problem, scaling back or exhausting their AI budgets sooner than planned. The question underneath it is: what happens when access is broad and use grows faster than the firm can see?

None of this means avoiding broad access. It means making the use visible. In practice that is unglamorous: admin dashboards, limits set per user and per workflow, and the simple discipline of knowing which deliverable each spend attaches to. The organisations that get surprised are the ones that cannot see the bill forming.

In real estate the answer to this is rarely as dramatic. It shows up in ordinary work such as document review, due diligence, lease abstraction and investor reporting. The cost grows as more people use the tools on more material. One useful way to understand this is application density.

Application density is the real variable

The technology may stay the same while the density of its use changes. Density often matters as much as price. It is what can turn a small unit cost into something worth monitoring. In some organisations a few people use AI now and then and the cost stays small. In others a team uses it across recurring tasks, and some wire those tasks into fixed workflows. A task that looks cheap once becomes real when it runs a hundred times. The same set of documents, run again and again, is another matter entirely.

A rough illustration helps. Abstracting a single lease of forty pages might cost a few cents; run once, it disappears into the noise. Run it across a portfolio of two hundred leases every quarter, with the full chat history carried forward each time, and the same cheap task becomes a line worth a glance. Nothing about the unit price changed. Only the density did.

Density is not only about headcount. It is about the nature of the work. A team that uses AI for short writing has one profile, while a team that processes transaction documents and compares evidence has another. Both are reasonable. They simply produce different patterns of use. None of this makes AI less useful. It means an organisation needs to see how its use builds up. A team can use AI a lot and still use it well. The question is whether that use is visible enough to understand.

The cost you cannot budget for easily

Most organisations understand software through access. There is a licence fee, some setup and training, perhaps a bit of integration. AI adds a second layer: usage, measured in tokens. A token is a small piece of text the model reads or writes. Your prompt costs tokens, and so does the output. But so do the things you never typed: the system instruction, the template, the documents you upload, the earlier messages in the conversation, anything pulled from a knowledge base.

This is easy to underestimate, because what you see hides what you pay for. A user types a short question and gets a short answer. Behind it the system may have read a long instruction, several documents and the whole chat history. The answer may look cheap; the work behind it may not be. Many subscriptions bundle usage into a flat monthly fee, which obscures this: a heavy user can pay no more than a light one. That pricing model is already changing, with more plans moving to metered or capped usage. Understanding how your own use builds up matters regardless of which model applies.

Sometimes the hidden context is genuinely necessary. A lease summary without the lease is useless, and a market update without sources is too generic. But more context is not always better. Processing the same documents repeatedly means paying for them repeatedly. An unclear request brings more rounds of revision. A long answer where a short table would do costs more than it should. These are choices. A team can send a whole data room and ask for a full narrative, or it can select the passages that matter and ask for a short outline. Both can be right, and they cost very different amounts. That is why the cost question tends to arrive later than the first use case. It grows alongside the use.

Why many real estate workflows are context heavy

The cost question does not land evenly across tasks. A brainstorming prompt is not a lease review. A one-line summary is not a full due diligence pass across a data room. A quick internal note is not a section for the investment committee built from sources, comparables and in-house templates. Many real estate workflows require a lot of context. Investment teams work from market reports, transaction documents, valuations and comparables. Asset managers handle business plans, tenant updates, operating reports, technical analysis and ESG data. Fund teams produce investor updates and portfolio commentary, and legal teams read leases, contracts and deal documents.

These are also the tasks where AI can help a lot. It can structure material, summarise long documents, compare sources and draft a first version someone can check. But it needs context to do any of this: the source documents, a template, clear instructions and a format a colleague can review. The more often that happens, the more the pattern matters. The issue is not one prompt but the repetition.

Usage is not value

It is easy to read more use as better use. More prompts, more drafts and longer answers all feel like progress. Often they are just activity. A team may use AI heavily because the work suits it, or because the input was unclear, the format was never set and the user kept correcting the result through many loops. The first case is value. The second is friction. But the token count can look the same in both.

So judge a workflow by the work it creates, not the tokens it burns. A due diligence task is measured in evidence reviewed, time saved and the quality of the first draft. Investor reporting is measured in whether the output is accurate and easy to check. Low use is not always good. High use is not always bad. This matters in real estate because AI output rarely stands alone. A summary, memorandum section or lease comparison still needs to be checked against source documents. If a workflow saves drafting time but creates more review work, the apparent saving may be smaller than expected.

Model choice

Not every task needs the same model. A short summary and a complex due diligence review do not carry the same risk and they do not need the same capability. A lighter model may be enough. A stronger one may be justified when the material is complex or the output matters. This is a workflow choice as much as a technical one. Extracting dates from a document is not the same as comparing a report against a risk framework, and a rough internal note is not a section for the investment committee. You should not choose the cheapest model but the right one for the task.

Make cost understanding part of training

Training usually covers prompts, data protection and review. Cost belongs next to them. Most people do not need pricing tables. They need to know which habits drive use. Long chats carry old context forward. Full documents get used where a few pages would do. Open questions bring long answers, and unclear requests bring extra rounds. A strong model gets used where a simple one would serve. These are habits, and they can be taught with the team’s own work.

This is where sector-specific training matters. Generic examples can explain the tools, but real estate examples make the learning practical. Take a single deliverable, such as an investment committee section, and show it built two ways: with the full data room and a long narrative, or with selected passages and a short structured draft. The aim is not caution. The aim is intent. It is the kind of practical, sector-specific training we build with real estate teams at VARi.

Where to start

Look at the AI use already happening. Which uses are occasional and which are becoming more regular. Which rely on long documents and which need many rounds of iteration and feedback. Where the output saves time and where it only makes more to review. Then pick one workflow and ask a few plain questions. What goes in. What output do we expect. Who checks it. How often does it run. Which model is needed. Does the value justify the use.

These questions will not settle every cost issue, and they do not need to. Their value is that they make the discussion concrete. Adoption across real estate organisations will remain uneven. Some organisations are still exploring basic use cases. Others are already working on team workflows, review routines and practical guidance. The cost question becomes more relevant where use gets denser. This is also where our work at VARi often starts: with the actual workflows, documents and decisions where AI is already being used. We help real estate teams see how that use builds up, set it on workflows worth repeating, and use AI with intent rather than by habit.

Created with