Models

flinq ships models specialized on the European construction (AEC) domain. German is the deepest-trained language today, not the product boundary. During the pilot, two models are available side by side: flinq-pilot-otter and flinq-pilot-wombat. Both cover the full API surface — embeddings, hybrid search and rerank — in the same vector-space contract, at the same price. Try both against your own data and use whichever ranks your documents better. Anonymous, aggregate per-model usage tells us which model earns its place after the pilot.

Model ids during the pilot

model is required on every request, and every listed model works on all three endpoints. There is no silent substitution: you always get exactly the model you request, and a retired or unknown id returns 404 with the list of available models. Discover the current ids at any time:

curl https://api.flinq.ai/v1/models -H "Authorization: Bearer flq_your_key_here"

After the pilot, the winning model receives a versioned successor id; ids then keep serving exactly the model they name, so your embeddings stay comparable until you re-embed on a newer version yourself.

flinq-pilot-otter

Property	Value
Endpoints	/v1/embeddings, /v1/search, /v1/rerank
Native dimension	1024
Matryoshka dimensions	1024 / 768 / 512 / 256 / 128
Max input	512 tokens
Max inputs per request	2048
Output	L2-normalized float vectors
Distance	cosine (equivalently, dot product on normalized vectors)
Domain	European construction (AEC); deepest-trained language German
Price	EUR 0.40 per 1M tokens

flinq-pilot-wombat

Property	Value
Endpoints	/v1/embeddings, /v1/search, /v1/rerank
Native dimension	1024
Matryoshka dimensions	1024 / 768 / 512 / 256 / 128
Max input	512 tokens
Max inputs per request	256
Output	L2-normalized float vectors
Distance	cosine (equivalently, dot product on normalized vectors)
Domain	European construction (AEC); deepest-trained language German
Price	EUR 0.40 per 1M tokens

The two models share the vector-space contract but not the vector space: vectors from different models are not comparable with each other. Embed a corpus and its queries with the same model id, and re-embed if you switch.

The reranking stage

Given a query and a list of candidate documents, /v1/rerank returns them reordered by relevance, each with a score, using whichever pilot model you pass. The current stage is a bi-encoder: it embeds the query and each candidate independently and scores them by cosine similarity. Because candidates can be embedded ahead of time, this is cheap and fast. A cross-encoder reranker, which reads the query and document together and models their token-level interactions, is on the roadmap. We state that plainly rather than overclaim the current stage.

Add a rerank step when first-stage recall is good but the ordering of the top results is not sharp enough, for example when several candidates look lexically similar and you need the precise one at the top.

Choosing dimensions

Both models are Matryoshka-trained: the first N components of each 1024-dim vector are a faithful embedding on their own. Choose the slice that fits your index budget and latency target.

• 1024. Default. Highest retrieval quality. Use unless storage or ANN cost is a constraint.
• 768. A modest reduction with minimal quality cost.
• 512. Balanced point for large indexes where serving cost matters.
• 256. Cheap, large-scale ANN. A quarter of the storage and nearest-neighbor work for a small quality drop.
• 128. Smallest footprint, for very large corpora or tight memory budgets where some quality loss is acceptable.

A common pattern is to retrieve on a smaller slice for speed, then rerank the top-k pool with /rerank to recover precision at the top.