Genie spaces

[prasuanu1222]

Hello Team

I am planning to use a genie space for our project as we have seen some changes to costing i would like to understand few things
1) what model does a genie space use and how to get costing estimate for the genie space?
2) we want to embeded this genie space in another application i see we have only api way to do that but we have limited number of api we have very large number of api spaces i dont think that is option how can we find a work around that?

[Ashwin_DSA]

Hi @prasuanu1222,

For the first question, it has been answered before on this forum. Genie is more of a managed service. You can find details about the underlying models on this page. This can change as Databricks switches to the best model available at the time. 

From a cost perspective, Genie costs have two parts. LLM usage charges and the existing compute cost. Compute is billed separately and unchanged by Genie Paygo. For Genie Spaces specifically, the FAQ says every user gets 150 DBUs of free usage every month, covering Genie, Genie Spaces, and Genie Code. Many users never exceed it. So, that should give you an indication. You can also check this community post. 

For the second question... if the goal is simply to surface a Genie Space within another website or application, the API is no longer the only option. Databricks now documents a native iframe-based option here... Embed a Genie Space in an external app. That page explains how a workspace admin must first allow the embedding domain, after which a space author can generate iframe code directly from the Share dialog.

The important limitation is that this does not bypass throughput limits by having many spaces. The iframe path is documented as 20 questions per minute per workspace across all Genie Spaces, not per space.

By contrast, the public docs for the Conversation API say the free tier is best-effort five questions per minute per workspace across all Genie Spaces. So if you were avoiding the API because you have a large number of spaces, that concern is valid, but the same general principle still applies... the limit is enforced at the workspace level rather than separately for each space.

So...

• If you only need to embed the existing Genie experience inside another app, use the documented iframe approach. Embed a Genie Space in an external app.
• If you need a fully custom UX, custom orchestration, or application-controlled rendering, then the API is still the right path. Use the Genie Spaces API.
• If you go down the API route, the docs explicitly recommend retry logic and exponential backoff to handle throughput constraints gracefully.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

[bala_sai]

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.