Provider Models
Provider Models connect Lakehousecat to an external AI provider. They encapsulate the credentials and configuration needed to call a specific AI service. Creating and managing Provider Models is an Administrator responsibility, as it involves API keys and incurs costs on the provider's side.
Supported Providers
Lakehousecat supports the following AI providers:
- OpenAI — Chat, Speech-to-Text (STT)
- Anthropic — Chat
- Google — Chat, Speech-to-Text (STT)
- Azure (Azure OpenAI) — Chat, Speech-to-Text (STT)
- AWS (Amazon Bedrock / Transcribe) — Chat, Speech-to-Text (STT)
- xAI — Chat, Speech-to-Text (STT)
Creating a Provider Model
Navigate to Workspace → Models → Provider Models and click the + icon.
Required Fields
| Field | Description |
|---|---|
| Provider Type | Select the provider (OpenAI, Anthropic, Google, Azure, AWS, xAI). |
| Model Type | Select the task type: Chat or STT (Speech-to-Text). |
| Configuration Name | A unique, descriptive name for this configuration (e.g. anthropic-claude-chat). |
Provider-specific credential fields are shown after selecting the Provider Type. See the individual provider pages for details.
Administrator Default Settings
After filling in the required fields, administrators can optionally set the saved configuration as:
- Default UI model — used as the pre-selected model in the chat interface for the selected model type
- Default Backend model — used by the backend for internal operations (Chat type only)
These defaults are applied after saving the configuration.
The Default Backend Model
One Provider Model can be designated as the Default Backend Model. This model is used by the system for all semantic extraction operations — the background process that analyzes data sources and builds the semantic layer that enables natural language querying.
The Default Backend Model is a system-level configuration, distinct from the Provider Model assigned to a Custom Model for chat queries. It is set by the Administrator and applies globally across all data source and Custom Model operations.
To set the Default Backend Model, open a saved Provider Model configuration and toggle Default Backend model in the Administrator Default Settings section.
Multiple Providers
Multiple Provider Models can be active in parallel. The relationship between a Provider Model and a Custom Model is 1:1 — each Custom Model uses exactly one Provider Model for chat queries.
However, this assignment can be changed after the Custom Model is created. For example, you can start with a cost-effective model during development and switch to a more capable model for production — without recreating the Custom Model.
Different Custom Models can each use a different Provider Model, allowing you to run multiple providers simultaneously for different use cases.
Model Compatibility
The model identifiers shown in Lakehousecat's dropdowns are models that have been actively tested with the platform. Lakehousecat validates correct API integration, response formatting, and analytical behavior for each listed model.
The AI model landscape evolves rapidly — new models are released nearly every week. We cannot test every model version as it appears. As a result, the listed models represent a subset of what is technically compatible. In practice, most chat-capable models from the supported providers work correctly with Lakehousecat even if not explicitly listed.
If you need to use a model that is not in the dropdown, you can enter the model ID manually. Lakehousecat will attempt to use it, but compatibility is not guaranteed for models that have not been tested.
We continuously expand our test coverage and update the model lists as new versions are validated.
Sharing
After creating a Provider Model, an Administrator can share it with individual users or groups using the Share function.
Sharing with Builders: Builders who have been granted access to a Provider Model can use it as the base for Custom Models. This is the standard workflow.
Sharing directly with Users: A Provider Model can also be shared with regular Users (without a Custom Model in between). In this case, the User interacts directly with the LLM provider — this is pure chatbot behavior with no system prompt, no data connections, and no Lakehousecat skills. This is a valid but limited use case, essentially a raw API proxy. For full data-driven analytics, share a Custom Model instead.
API Rate Limits
The effective API rate limits depend on your chosen AI provider and the specific plan or contract you have with them. Lakehousecat itself does not impose additional rate limits on top of what the provider enforces.
This section is specifically about calls Lakehousecat makes outward to your configured AI provider. Separately, Lakehousecat's own API ingress applies its own rate limit to incoming requests from your users — see Limits if you're seeing slowness or errors that aren't showing up as provider 429s.
Some features — in particular chart generation — use internal agent workflows that issue multiple sequential API calls to complete a single user request. Depending on your provider plan, this may cause rate limits to be reached faster than with simple single-turn queries.
When a rate limit is exceeded, the provider typically returns HTTP status 429 (Too Many Requests). This is expected behavior from the provider side and not a bug in Lakehousecat.
If you encounter rate limit errors:
- Check the application logs for HTTP 429 entries or similar rate limit indicators.
- Review which features or workflows triggered the limit (e.g. chart generation, semantic extraction).
- Contact your AI provider to discuss plan upgrades or rate limit adjustments.
Model Quality Recommendations
Lakehousecat's analytics and chart generation workflows are agentic: the model must follow multi-step instructions, reason over structured data, and ground its responses in query results. Not every AI model is suited for this.
Frontier models are strongly recommended for production use. Models from the leading providers — such as the latest GPT-4 class models via OpenAI or Azure, Claude Sonnet/Opus via Anthropic or AWS Bedrock, Gemini Pro/Ultra via Google, and Grok via xAI — have been validated against Lakehousecat's full feature set and consistently deliver correct, data-grounded responses.
Open-weight models are experimental. Many open-weight models, even recent and capable ones, can produce lower-quality responses in agentic workflows:
- They may ignore provided data context and generate generic or fictitious content.
- They may fail to follow structured tool-call instructions correctly.
- Response quality varies significantly between model families and versions.
Lakehousecat cannot validate every open-weight model that becomes available. If you choose to configure an open-weight model:
- Treat it as experimental, without quality guarantees.
- Test it against your actual data before rolling it out to end users.
- Be aware that prompt behavior tuned for frontier models may not transfer.
For analytics-heavy workloads, we recommend staying with frontier models unless you have a specific reason to use open-weight alternatives.
There is no single "right" provider
Lakehousecat does not recommend one provider or model over another as a general rule. The best choice depends on factors specific to your situation:
- Your setup and architecture — which provider you already have infrastructure and credentials for (e.g. an existing AWS account vs. a standalone OpenAI key).
- Your data quality and use case — how demanding your analytics workloads are, and how much reasoning depth they require.
- Your budget — pricing, rate limits, and cost visibility differ meaningfully between providers and model tiers (see Cost Awareness below).
Each provider page in this section documents what Lakehousecat has actually verified for that provider (see "Tested Configurations" on each page) — this reflects practical, functional compatibility, not a performance ranking. We deliberately do not publish our own benchmark numbers or comparative scores; response quality depends on too many variables (model choice, prompt, data preparation, and more) to reduce to a single number. If you want quantitative, third-party model comparisons to support your decision, Artificial Analysis is an independent, actively maintained source that benchmarks models across providers on quality, speed, and price.
Start light, scale deliberately
Across every provider, our practical experience is the same: start with a lighter, cheaper model, and move to a heavier one only when you have a concrete reason to. The most capable "flagship" or reasoning-tier models (e.g. Claude Opus-class, GPT "pro"/deep-research variants) are intelligent but also the slowest and most expensive to run — for structured, repeatable tasks like chart generation, that extra capability is often not needed and does not change the outcome. Reserve heavier models for genuinely open-ended reasoning or chat use cases where their depth is actually exercised, and weigh that against the cost before switching. See Choosing a Model for Chart Generation for concrete per-provider starting points.
Speech-to-Text Setup
Several providers support Speech-to-Text (STT) for voice input. For most of them, the STT credentials work the same way as Chat — but Google is a special case that requires extra setup, so it is worth knowing before you start:
| Provider | STT model selection | Extra setup beyond Chat? |
|---|---|---|
| OpenAI | Model list (whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe) | No — same API key as Chat |
| xAI | Model ID (grok-stt) | No — same API key as Chat |
| AWS | No model selection — streaming engine, language code only | IAM permission for Amazon Transcribe; no model-access activation needed |
Curated recognizer models (latest_long, chirp_3, …) | Yes — a separate Google Cloud project with billing, the Speech-to-Text API enabled, and a separate API key (the Gemini chat key does not work for STT) |
The Google requirement is a property of Google Cloud, not a Lakehousecat limitation. See the Google provider page for the exact step-by-step setup, and the AWS provider page for Transcribe.
Cost Awareness & Chart-Generation Restrictions
The choice of model has a direct — and potentially large — impact on your API costs. This is especially true for chart generation, which is an agentic workflow: a single chart request issues many sequential calls to the provider (generate SQL → pick a chart type → build the configuration). Heavy, high-priced "pro" or deep-research reasoning models multiply the cost of every one of those steps, while a single chat message stays inexpensive.
Because Lakehousecat only orchestrates the calls and never marks up provider pricing, the Administrator is responsible for choosing a model that fits the intended use case and budget. This is a factual consideration, not a limitation of any particular provider — comparable cost risks exist across all providers' premium tiers.
Premium "pro" and deep-research models are not available for chart generation
To protect against runaway costs, premium "pro"-tier reasoning models and deep-research models cannot be used as the base model of a chart-generating Custom Model. This is not a recommendation you can override — it is enforced by the backend for every access path (UI, CLI, and direct API calls alike), so it cannot be bypassed by going around the UI.
| Use case | Premium "pro" / deep-research model |
|---|---|
| Register and use as a standalone Chat model | ✅ Allowed — no restriction |
| Use as the base model of a Custom Model for chart generation | ❌ Not available |
This is scoped narrowly: only the combination of an expensive model and chart generation is blocked. The same model remains fully usable for chat — registering it as a Chat provider model and conversing with it is unaffected. If you try to select a restricted model as a Custom Model's base model, or trigger chart generation with one, you'll get a clear message naming a lighter alternative (e.g. gpt-5.6-luna) — this is a deliberate prevention, not a warning you can dismiss.
The restriction applies to a model class, not to a specific provider — comparable premium/pro tiers exist across multiple providers and are treated the same way. See each provider's page for concrete examples of which models fall into this class.
There is no fixed price per chart. The cost of a single chart generation varies with the complexity of the request, the number and length of the agent's steps, and the overall processing time — the same model can cost noticeably more for a complex request than a simple one. For the amounts that actually apply to you, always refer to your own provider dashboard, which is the authoritative source for billing.
Volume adds up. Generating many charts in a short period translates into real spend, particularly with large models. Plan for this so that usage never comes as a surprise on your provider invoice.
Cost visibility per provider
How quickly your usage becomes visible differs by provider. This is a property of each provider's billing platform, not a quality judgment:
| Provider | Cost visibility |
|---|---|
| Anthropic | Timely; clean CSV export available |
| OpenAI | Timely; clean CSV export available |
| Delayed (~1 day) — today's usage may not appear until the following day | |
| AWS | Delayed — usage appears in the AWS billing dashboard with a lag |
Choosing a Model for Chart Generation
For chart generation specifically, a fast, lightweight model is the recommended choice — and "bigger" or "more expensive" brings no benefit here. Chart generation is a structured, tool-driven task (produce SQL, select a chart type, assemble a configuration), not an open-ended reasoning problem. The strengths of large reasoning models (deep inference, complex coding) are barely exercised; speed and reliability matter more. In testing, lightweight and heavy models produced the same chart for the same request, while the heavy model cost several times as much and took roughly twice as long.
You can use a large model for chart generation, but it is overkill. The recommended starting point per provider:
| Provider | Recommended for chart generation |
|---|---|
| Anthropic | Claude Haiku — fast, reliable, considerably cheaper than Sonnet/Opus |
| Gemini Flash / Flash-Lite — the fastest, most reliable tier in testing | |
| OpenAI | A standard GPT-5.x chat model — not the -pro or deep-research variants |
| Azure (Azure OpenAI) | A standard GPT-4-class model — a solid, cost-effective default |
| AWS (Bedrock) | An established foundation model in a lightweight tier (e.g. Claude Haiku via Bedrock) |
| xAI | grok-4.20-fast (non-reasoning) — the heavier reasoning Grok variants bring no benefit for this structured task |
These are recommendations for the standard and lightweight model tiers — feel free to pick a larger standard model if you prefer, you'll simply pay more for the same result. Premium "pro" and deep-research tiers are a separate case: they are not available for chart generation at all (see Cost Awareness & Chart-Generation Restrictions above) — keep those for use cases where their reasoning depth genuinely helps, such as open-ended chat.
The provider model you select for a Custom Model is used for all of that Custom Model's steps — Lakehousecat never silently switches to a different model in the background. This gives you predictable cost and compliance behavior.
Next Steps
For provider-specific configuration details, see the dedicated pages: