Choosing an AI engine for each feature

Every AI feature can run on its own engine and model, with its own standby for when a local engine is asleep. What that changes, what it costs, and the one feature that never moves.

Seayora uses AI in about thirty different places — writing a listing description, reading a receipt, checking an advert for Fair Housing problems, categorising a bank transaction. Those jobs are nothing like each other in size. Alt-text for a photo is a few hundred words in and one sentence out. A bank statement is a whole document in and a structured list of every transaction out, and it can cost sixty times as much per call.

For a long time all of them ran on one engine, chosen in Platform Settings. That meant picking one point on a very wide range and accepting that it was wrong at both ends. Admin → Platform Settings → AI Engines lets you set each feature separately — the global engine and the per-feature pins sit on that one tab, in that order.

How the setting works

Anything you have not touched follows the global engine at the top of the same tab. If you never pin a feature, nothing changes.
Pinning a feature to an engine overrides the global setting for that feature only.
Pinning a model as well overrides the default model. Leaving the model on "Engine default" means the feature keeps following whatever the server is configured to use, including when that changes.
Setting a feature back to "Follow global" removes the override entirely.

What the costs on the screen mean

Each feature shows a figure per 1,000 calls. That is a comparison between models using an estimated prompt size and the token budget that feature actually uses — not a forecast of your bill. Your real spend, with real call volumes, is in Admin → API Costs.

Two things are deliberately not folded into those figures, and both push costs up. Claude models from 4.7 onwards count roughly 30% more tokens for the same text, so their sticker price understates them against other vendors. And models that reason before answering bill that reasoning as output, which can exceed the figures shown. Both are noted on the screen rather than silently averaged in.

A model with no rate on file reads "not priced" — never "$0.00". A local engine reads "on your hardware", which is a different thing again: genuinely no per-token cost, because the cost is a machine this meter cannot see.

Picking sensibly

Job shape	What it looks like	What to run it on
Micro	Photo alt-text, listing titles, transaction categorisation. Short in, short out, very high volume.	The cheapest model that produces a usable sentence. This is where nearly all the saving is.
Standard	Listing descriptions, the Fair Housing review, collections drafting, tax classification.	A mid-tier model. Judgement matters here and the volume is moderate.
Document	Receipt capture, bank statement import, the walkthrough blueprint.	A strong model. These are low-volume and high-stakes — a cheap model that invents a line item costs far more than the call saved.

"Preview changes" works out what moving every feature onto a right-sized model would do, and shows you the whole list with the money before anything is written. It only ever proposes models recommended for that job shape, so a bank statement cannot land on a model picked for alt-text.

The one feature that never moves

Voice note transcription always runs on OpenAI, whatever you choose. It is shown on the screen, locked, with the reason: no other engine we support offers an equivalent, so pointing it at a local engine would switch voice notes off rather than move them.

Running a model on your own hardware

Ollama and LM Studio are supported as engines. There is no per-token cost, but two things are worth knowing. Neither can read a PDF, so document features step over to a cloud engine when handed one. And the server has to be able to reach the machine running it — a private network address is only reachable from a server on that same network.

The "Test" button beside each engine on the AI Engines tab tells you whether it answers, how fast, and which models it currently has loaded. A model named in your configuration but not loaded is the failure that looks like success: the endpoint answers, the call goes out, and the engine returns an error for a model it does not have.

Because engines are now per feature, you can put one low-stakes feature on a local engine and leave everything else on a cloud one, rather than having to move the whole platform at once.

When a local engine is not answering

A machine on your desk sleeps, reboots and loses its network. So a local engine has a standby: the engine that answers for it while it cannot be reached at all. You set it in the Global AI Provider Engine card, directly under the engine tiles, and it saves with the rest of that screen.

It only ever fires when the machine could not be reached AT ALL. An engine that is running and refuses a request is a bug on our side, and quietly re-asking a cloud model would hide it behind a bill.
It is one hop, never a chain, and every handover is written to the log — a cloud engine silently covering for a local one is an outage you never learn about and a bill you did not expect.
Only cloud engines can be a standby. A second machine that may also be asleep buys you one more timeout and then the same failure.
Each feature can override it, in the row for that feature: its own standby engine, its own standby model, or "Fail instead — no standby".

"Fail instead" is a real answer and worth using on the Fair Housing review. An empty result there is indistinguishable from a clean advert, so an answer from an engine you did not pick is worse than no answer at all.

Leaving a feature’s standby on "Use the platform standby" is the normal case. The row tells you what that resolves to, and says plainly when a standby can never fire because that feature runs on a cloud engine already.

Search embeddings, and why they are separate

Search embeddings can run on OpenAI, Google Gemini, LM Studio or Ollama — but they are set in their own card, "Search index", rather than in the feature list. Anthropic is the one engine that cannot do it at all: Claude has no embeddings endpoint, and the screen says so rather than offering a choice that would never run.

They are separate because they are not really a setting. Every other choice on that screen changes what the next call does. This one describes the search index that already exists — so changing it clears every search vector on the platform and rebuilds them. Two models produce two different kinds of vector even when they are the same size, and an index built half by one and half by the other returns results that are perfectly well-formed and completely meaningless. Clearing is what makes that impossible.

You are shown the count before anything happens, and asked to confirm it. The button says how many vectors it will clear.
While the index rebuilds, browse search runs on its keyword and geography terms alone. It gets less good; it does not break.
The rebuild is automatic and runs in the background — about 80 records every ten minutes. The card shows how far along it is.
A listing created while a local engine is asleep is simply not indexed yet. The same backfill picks it up when the machine comes back. This is also why embeddings have no standby: a standby is a different engine, which would put a second kind of vector into the index.

Choosing a local engine needs one extra step. Nothing on LM Studio or Ollama reports how wide a loaded embedding model’s vectors are, so "Measure width" asks it for one embedding and reads the answer. Note that your embedding model is a different model from your chat model — asking a chat model for an embedding fails in a way that looks exactly like the engine being down.

One hard limit: vectors wider than 2000 numbers cannot be indexed, and an unindexed search reads every listing on every query. Models that are natively wider are requested at a smaller size, and anything that still does not fit is refused with that reason.

Embeddings are cheap either way — a portfolio of ten thousand listings costs a few cents to index on a cloud engine, and nothing at all on your own machine.

If a feature stops producing anything

The most common cause is a feature pinned to an engine that has no key on the server. The screen shows a warning at the top listing any feature in that state. Setting it back to "Follow global", or adding the key, fixes it.

Related guides

Related features and guides

Seayora Platform Overview — Documentation. What Seayora is, who it is for, and how the listings, leasing, payments, accounting, and service-pro tools fit together in one platform.
Roles & Account Types — Documentation. The difference between landlord, management, service professional, and tenant accounts — and what each role can do on Seayora.
AI that runs on your phone — Documentation. Some Seayora features can run on the handset itself — free, offline, and without the text leaving the device. Which ones, which phones, and what happens on every other phone.
Seayora vs TurboTenant — Comparison. Seayora vs TurboTenant, compared on published prices: subscription vs pay-when-money-moves, screening fees, ACH and card costs, and which is cheaper at your rent roll.