Genie Spaces do not expose a single fixed model choice for standard usage it uses a compound AI system.

For cost, I would split it into two areas:

The first one is the SQL warehouse cost. Genie still has to run SQL against the warehouse attached to the space, so this depends on the warehouse type/size, query runtime, concurrency, and how many questions users are asking. This is probably the easier part to estimate once we have some query history from a pilot.

The second one is Genie or LLM usage cost, this depends more on the number of users, how many questions they ask, and whether the usage is happening through the UI/embed experience or through the API.

For embedding, API is not necessarily the only path. If the requirement is just to let users access an existing Genie Space from another internal app, iframe embedding is probably the simpler option. It avoids building a custom API flow for every interaction.

A couple of things still matter though like users need access to the Genie Space and the underlying data, and the workspace admin has to allow that application/site for embedding. Also users can interact with the embedded Genie Space, but they cannot edit the space configuration from there.

If the requirement is a fully custom experience across many Genie Spaces, then the Conversation API may still be needed. In that case it is better to avoid a direct one to one integration for every space. A better design would be to have a common backend layer that routes requests to the right Genie Space, with caching, queueing/retry logic, and maybe fewer curated domain level spaces instead of too many small spaces.