Invalid client property. Should have been a google-ai…

Error message

Invalid client property. Should have been a google-ai property but got: {}

What it means

resolve_properties resolves the client's UnresolvedClientProperty against the runtime context and expects the result to be the ResolvedClientProperty::GoogleAI variant. Any other variant (e.g. OpenAI, Anthropic, Aws) means the provider name and property type disagree, so BAML refuses to continue. This guards against a mislabeled or misparsed client definition.

Solutions

Set the client provider exactly to "google-ai" in the BAML config block.
Check for typos/whitespace/casing in the provider name.
If using dynamic client construction, ensure the properties were built for the google-ai provider.
Upgrade BAML if your config uses an outdated provider naming scheme.

Example fix

// before (baml)
client "gemini" { provider "googleai" ... }
// after
client "gemini" { provider "google-ai" ... }

Defensive patterns

Strategy: validation

Validate before calling

// baml config check
// client "gemini" { provider "google-ai" options { api_key env.GEMINI_API_KEY } }
if (!clientConfig.provider.startsWith('google-ai')) throw new Error(`google-ai client requires provider 'google-ai', got '${clientConfig.provider}'`);

Try / catch

try { const r = await b.MyFunction(...) } catch (e) { if (String(e).includes('Should have been a google-ai property')) { console.error('Fix the client provider string in your BAML config'); } throw e; }

Prevention

Use the exact provider string "google-ai" in client blocks.
Match dynamic client properties to the provider they were built for.
Lint BAML config files for provider typos in CI.

When it happens

Trigger: Declaring a client whose provider resolves to something other than google-ai but which flows into GoogleAIClient::new/dynamic_new — typically a typo in the provider string (e.g. "google-ai " with whitespace, wrong casing) or a client-override at runtime passing mismatched properties.

Common situations: Misspelling provider "google-ai" in the generator/client block; passing a dynamically constructed client property of the wrong type to dynamic_new; older BAML config formats where the provider key changed.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/116c79ddf0fe8768. Report an issue: GitHub.

Appendix: source

Thrown at engine/baml-runtime/src/internal/llm_client/primitive/google/googleai_client.rs:52

pub struct GoogleAIClient {
    pub name: String,
    pub client: reqwest::Client,
    pub retry_policy: Option<String>,
    pub context: RenderContext_Client,
    pub features: ModelFeatures,
    properties: ResolvedGoogleAI,
}

fn resolve_properties(
    provider: &ClientProvider,
    properties: &UnresolvedClientProperty<()>,
    ctx: &RuntimeContext,
) -> Result<ResolvedGoogleAI, anyhow::Error> {
    let properties = properties.resolve(provider, &ctx.eval_ctx(false))?;

    let ResolvedClientProperty::GoogleAI(props) = properties else {
        anyhow::bail!(
            "Invalid client property. Should have been a google-ai property but got: {}",
            properties.name()
        );
    };

    Ok(props)
}

impl WithRetryPolicy for GoogleAIClient {
    fn retry_policy_name(&self) -> Option<&str> {
        self.retry_policy.as_deref()
    }
}

impl WithClientProperties for GoogleAIClient {
    fn allowed_metadata(&self) -> &AllowedRoleMetadata {
        &self.properties.allowed_metadata
    }

View on GitHub (pinned to bd85ce9dee)