Cost always reported as 0 for a billable action

Both generateSpeech (line 42) and translatedTts (line 157) hardcode const cost = 0 and call metadata.setCost(0), even though both actions are marked billable: true in the integration definition. This means the platform will never charge or track any cost for these operations, which contradicts the intent of the billable flag.

Compare with the OpenAI integration, which computes (input.length / 1_000_000) * PricePer1MCharacters before calling metadata.setCost. CAMB AI's pricing model should be reflected here (e.g., based on character count or duration). If actual cost tracking isn't feasible at this time, billable: false would be more accurate until it is implemented.

pollForResult used as a side-effect mechanism

pollForResult<T> is designed so that the getResult callback is the source of truth for the returned value T. Here, the callback is abused — it sets runId = rid as a side-effect and then returns rid, making the outer let runId: number | undefined variable the actual carrier of the result. This leaks the run_id via closure mutation rather than using the return value.

A cleaner approach is to use the return value of pollForResult directly:

const runId = await pollForResult(
  async () => {
    const status = await cambClient.translatedTts.getTranslatedTtsTaskStatus({ task_id: taskId })
    return { status: status.status, run_id: status.run_id }
  },
  async (rid: number) => rid
)

Then remove the let runId: number | undefined declaration and the guard if (!runId) block (since pollForResult already throws if no run_id is returned on SUCCESS).

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Hardcoded API base URL bypasses the SDK

The URL https://client.camb.ai/apis/tts-result/${runId} is constructed manually and the request is fired with a raw fetch call, while all other API calls go through the @camb-ai/sdk. If the API host ever changes (e.g. versioning, domain migration), this line will silently break.

Consider either using the SDK method if one exists, or at minimum extracting the base URL into a named constant at the top of the file so it can be updated in one place:

const CAMB_AI_BASE_URL = 'https://client.camb.ai'
// ...
const audioResponse = await fetch(`${CAMB_AI_BASE_URL}/apis/tts-result/${runId}`, {

Date.now() and a content hash are used together, defeating both purposes

generateFileKey combines a SHA-1 hash of the input (good for content-addressable deduplication) with Date.now() (good for uniqueness). These two goals contradict each other: because the timestamp changes on every invocation, the full key is never reproducible, so the hash provides no deduplication value whatsoever.

If the intent is to deduplicate file uploads for identical inputs (which pairs well with cacheable: true), drop Date.now():

If the intent is simply to produce a unique key per invocation (e.g. to avoid collisions), drop the hash and keep only the timestamp (or use crypto.randomUUID()).

schemas.ts is dead code — ttsModelId is never imported or used

ttsModelId and TtsModelId are defined here but are not imported by either integration.definition.ts or src/index.ts. The definition file declares its own local TtsModels constant:

// integration.definition.ts
const TtsModels = ['mars-flash', 'mars-pro', 'mars-instruct'] as const

This duplication means the two enum definitions can diverge silently. Either:

• Remove schemas.ts and use the local constant in integration.definition.ts as-is, or
• Import ttsModelId from schemas.ts in integration.definition.ts and use it for the model field to keep the canonical list in one place.

speed input parameter silently ignored

The generateSpeech input schema defines a speed field (validated between 0.5–2.0), but it is never forwarded to the cambClient.textToSpeech.tts() call. Any value a user provides for speech speed will be silently discarded.

No null guard on cloneVoice result

result.voice_id is used directly without any null/undefined check. All other actions guard their critical response fields (e.g. the task_id checks on lines 72–75 and 102–105), but cloneVoice does not. If the CAMB AI API returns a missing or null voice_id, the function will return { voiceId: undefined }, violating the output schema's z.number() constraint and silently surfacing bad data to downstream bots.

as any cast bypasses SDK types for translation result

createTranslation is cast to any to access task_id. This suppresses TypeScript's ability to catch any future shape mismatch (e.g. if the SDK renames the field). The translatedTts action avoids this — createResult.task_id is accessed directly from the typed createResult without a cast. It would be worth checking whether the SDK type definition for createTranslation is missing task_id, and if so, opening an issue with @camb-ai/sdk. In the interim, a narrower cast is safer than as any:

const createResult = await cambClient.translation.createTranslation({...}) as { task_id?: string }

Reusing a TTS run_id with the translation API may be fragile

After polling translatedTts.getTranslatedTtsTaskStatus, the resolved runId is passed to cambClient.translation.getTranslationResult. This works today because the CAMB AI API appears to share a single run_id namespace across both the TTS and translation sub-services for a translatedTts job, but this coupling is undocumented and non-obvious. If the API ever separates the two IDs (or if the TTS run_id becomes a different type than the translation run_id), this will fail silently or throw at runtime.

Consider adding a comment referencing the API docs that confirms the run_id from a translated-TTS task is also a valid translation result run_id, so the intent is clear to future maintainers.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}