packages/typescript/ai-openai/src/utils/client.ts (1)

45-47:Duplicate:generateId duplication.

This function is identical to implementations in Gemini, Anthropic, and Ollama adapters. See the comment onpackages/typescript/ai-gemini/src/utils/client.ts (lines 41-43) for consolidation recommendations.

packages/typescript/ai-anthropic/src/utils/client.ts (1)

43-45:Consider centralizinggenerateId to eliminate duplication.

This exact implementation is duplicated across multiple provider utilities (OpenAI, Gemini, Ollama) and the base adapters in@tanstack/ai. Consider extracting it to a shared location in@tanstack/ai and re-exporting from there.

Additionally,substring(7) may return fewer than 4 characters for small random values. Usingsubstring(2, 9) orpadEnd would ensure consistent length.

-export function generateId(prefix: string): string {-  return `${prefix}-${Date.now()}-${Math.random().toString(36).substring(7)}`+export function generateId(prefix: string): string {+  return `${prefix}-${Date.now()}-${Math.random().toString(36).substring(2, 9)}` }

packages/typescript/ai-anthropic/src/adapters/summarize.ts (3)

32-34:Redundantkind declaration.

BaseSummarizeAdapter already setskind = 'summarize' as const. This redeclaration is unnecessary unless you intend to override with a different value.

 export class AnthropicSummarizeAdapter extends BaseSummarizeAdapter<   typeof ANTHROPIC_MODELS,   AnthropicSummarizeProviderOptions > {-  readonly kind = 'summarize' as const   readonly name = 'anthropic' as const   readonly models = ANTHROPIC_MODELS

---

71-97:buildSummarizationPrompt is duplicated across providers.

This method is identical to the implementation inOpenAI.buildSummarizationPrompt (seeopenai-adapter.ts lines 171-197). Consider extracting it to a shared utility in@tanstack/ai to reduce duplication and ensure consistent behavior across providers.

---

38-41:Consider passing config to base class.

The constructor passes an empty object tosuper({}) whileBaseSummarizeAdapter acceptsSummarizeAdapterConfig with fields liketimeout,maxRetries, andheaders. IfAnthropicSummarizeConfig expands to include these fields, they won't propagate to the base class.

 constructor(config: AnthropicSummarizeConfig) {-  super({})+  super(config)   this.client = createAnthropicClient(config) }

packages/typescript/ai/src/adapters/base-chat-adapter.ts (1)

11-121:Solid base chat adapter design; consider wiringTModels intoChatOptions for extra safety

TheChatAdapterConfig,ChatAdapter generics, andBaseChatAdapter shape look coherent and extensible: thekind: 'chat' discriminator, type‑only_providerOptions/modalities/metadata fields, andchatStream contract are all aligned with how a unifiedgenerate/ai API will discriminate adapters.

If you ever want stricter coupling between supported models andchatStream calls, you could consider tightening the signature to something like:

chatStream:(options:ChatOptions<TModels[number],TProviderOptions>,)=>AsyncIterable<StreamChunk>

sooptions.model can’t drift frommodels. Not required, but it’s a low‑cost type‑safety win if it doesn’t fightChatOptions’ current generic constraints.

packages/typescript/ai/src/adapters/index.ts (1)

1-33:Adapter index looks good; consider derivingAdapterKind fromAnyAdapter

The base adapter re-exports andAnyAdapter union are a nice central place to hang adapter‑level types.

To reduce the chance of drift if you add another adapter kind later, you could deriveAdapterKind fromAnyAdapter instead of hard‑coding the union, e.g.:

exporttypeAnyAdapter=|ChatAdapter<any,any,any,any,any>|EmbeddingAdapter<any,any>|SummarizeAdapter<any,any>exporttypeAdapterKind=AnyAdapter['kind']

Not required, but it keeps the discriminator and the union in sync automatically.

packages/typescript/ai-gemini/src/utils/client.ts (1)

41-43:Consider consolidatinggenerateId across adapter packages.

This identical function is duplicated across Gemini, OpenAI, Anthropic, Ollama, and base adapter classes. Consider extracting it to a shared utility module (e.g.,@tanstack/ai/utils) to reduce duplication and ease maintenance.

Example consolidation inpackages/typescript/ai/src/utils/id.ts:

exportfunctiongenerateId(prefix:string):string{return`${prefix}-${Date.now()}-${Math.random().toString(36).substring(7)}`}

Then import from the shared location in each adapter package.

packages/typescript/ai-ollama/src/utils/client.ts (1)

39-41:Consider removing the default parameter for consistency.

ThisgenerateId implementation has a default parameter'msg', while the identical function in OpenAI, Anthropic, and Gemini adapters doesn't have a default. For consistency across the codebase, consider removing the default or applying it uniformly.

Note: This also relates to the code duplication mentioned in the Gemini utils review—consolidatinggenerateId would naturally resolve this inconsistency.

packages/typescript/ai-ollama/src/adapters/text.ts (2)

254-260:Duplicate code in image source handling.

Both branches of the conditional (lines 255-259) execute identical code. The distinction betweendata and URL sources appears intended but isn't implemented.

Simplify by removing the redundant conditional:

           } else if (part.type === 'image') {-            if (part.source.type === 'data') {-              images.push(part.source.value)-            } else {-              images.push(part.source.value)-            }+            images.push(part.source.value)           }

Or, if different handling was intended (e.g., prefixing data URIs), implement the distinction.

---

280-292:Silent failure on JSON parse error.

The empty catch block silently converts invalid JSON arguments to an empty object, which could mask malformed tool call data and cause downstream failures.

Consider logging or preserving the original string:

                   try {                     parsedArguments = JSON.parse(                       toolCall.function.arguments,                     ) as Record<string, unknown>                   } catch {-                    parsedArguments = {}+                    // Log or handle malformed arguments+                    console.warn(`Failed to parse tool call arguments for ${toolCall.function.name}`)+                    parsedArguments = { _raw: toolCall.function.arguments }                   }

packages/typescript/ai-gemini/src/adapters/embed.ts (2)

74-86:Sequential API calls for multiple inputs may be inefficient.

Each input triggers a separate API call in sequence. For batches of inputs, this adds latency. Consider parallelizing withPromise.all if the Gemini API supports concurrent requests, or check if batch embedding is available.

-    for (const input of inputs) {-      const response = await this.client.models.embedContent({+    const responses = await Promise.all(+      inputs.map((input) =>+        this.client.models.embedContent({-        model,-        contents: [{ role: 'user', parts: [{ text: input }] }],-        config: {-          outputDimensionality: options.dimensions,-        },-      })+          model,+          contents: [{ role: 'user', parts: [{ text: input }] }],+          config: {+            outputDimensionality: options.dimensions,+          },+        }),+      ),+    )-      if (response.embeddings?.[0]?.values) {-        embeddings.push(response.embeddings[0].values)+    for (const response of responses) {+      if (response.embeddings?.[0]?.values) {+        embeddings.push(response.embeddings[0].values)       }     }

---

88-96:Hardcoded usage tokens and inconsistent ID generation.

Usage tokens are hardcoded to0, which doesn't reflect actual API consumption. Also,Date.now() is used directly instead of thegenerateId utility used in other adapters (e.g., Ollama summarize adapter usesgenerateId('sum')).

For consistency with other adapters:

+import { generateId } from '../utils'+     return {-      id: `embed-${Date.now()}`,+      id: generateId('embed'),       model,       embeddings,       usage: {-        promptTokens: 0,-        totalTokens: 0,+        promptTokens: 0, // TODO: Gemini API may provide token counts in response+        totalTokens: 0,       },     }

packages/typescript/ai-openai/src/adapters/summarize.ts (1)

15-20:Provider options are defined but never used.

OpenAISummarizeProviderOptions definestemperature andmaxTokens, but thesummarize() method hardcodestemperature: 0.3 (line 53) and usesoptions.maxLength formax_tokens. Consider either removing these unused options or applying them in the API call.

packages/typescript/ai-gemini/src/adapters/summarize.ts (2)

50-53:Inconsistent inheritance pattern.

This adapter implementsSummarizeAdapter directly, whileOpenAISummarizeAdapter extendsBaseSummarizeAdapter. For consistency and to leverage shared functionality (like the basegenerateId), consider extendingBaseSummarizeAdapter instead.

---

26-40:Provider options are defined but not applied.

GeminiSummarizeProviderOptions definesgenerationConfig andsafetySettings, but these are not passed to thegenerateContent call. Either use these options in the API request or remove them from the interface.

     const response = await this.client.models.generateContent({       model,       contents: [         {           role: 'user',           parts: [             { text: `Please summarize the following:\n\n${options.text}` },           ],         },       ],       config: {         systemInstruction: systemPrompt,+        ...options.providerOptions?.generationConfig,       },+      safetySettings: options.providerOptions?.safetySettings,     })

packages/typescript/ai-openai/src/adapters/text.ts (3)

100-107:Remove or replace debug logging.

Theseconsole.error statements appear to be debugging artifacts. Consider removing them or using a proper logging abstraction that can be configured for different environments.

     } catch (error: unknown) {       const err = error as Error-      console.error('>>> chatStream: Fatal error during response creation <<<')-      console.error('>>> Error message:', err.message)-      console.error('>>> Error stack:', err.stack)-      console.error('>>> Full error:', err)       throw error     }

---

380-400:Debug logging in catch block.

Similar to the earlier comment, theconsole.log should be removed or replaced with a configurable logging mechanism. Also note the unusedeventTypeCounts referenced here.

---

348-351:Consider a more robust type check.

The type assertion(item as { type: string }).type works but is fragile. Consider using a type guard or checking for the property existence first.

-          const hasFunctionCalls = chunk.response.output.some(-            (item: unknown) =>-              (item as { type: string }).type === 'function_call',-          )+          const hasFunctionCalls = chunk.response.output.some(+            (item) =>+              item && typeof item === 'object' && 'type' in item && item.type === 'function_call',+          )

packages/typescript/ai-ollama/src/adapters/embed.ts (2)

85-92:Sequential API calls may impact performance for batch embeddings.

Each input triggers a separateclient.embeddings() call. If the Ollama API supports batching multiple prompts in a single request, consider leveraging that to reduce latency and overhead. Otherwise, for large input arrays, consider usingPromise.all for concurrent requests (with appropriate rate limiting if needed).

---

100-100:Non-unique ID generation.

Date.now() can produce duplicate IDs for rapid successive calls. Consider using a UUID library or combining with a random suffix:

-      id: `embed-${Date.now()}`,+      id: `embed-${Date.now()}-${Math.random().toString(36).slice(2, 9)}`,

packages/typescript/ai/src/types.ts (1)

994-1037:Duplication withChatStreamOptionsForModel.

ChatOptionsForChatAdapter (lines 994-1037) is structurally very similar toChatStreamOptionsForModel (lines 887-937). The main difference is the adapter base type (ChatAdapter vsAIAdapter). Consider whether these could share a common base type or be unified to reduce maintenance overhead as the API evolves.

packages/typescript/ai-gemini/src/adapters/text.ts (1)

157-162:Silent error swallowing in argument merging.

The catch block silently replaces the existing args with the new args when JSON parsing fails, which could mask data corruption issues. Consider logging a warning:

             } catch {+              // Log or track parse failure for debugging               toolCallData.args =                 typeof functionArgs === 'string'                   ? functionArgs                   : JSON.stringify(functionArgs)             }

packages/typescript/ai/src/core/generate.ts (3)

495-497:Dead code -outputSchema is guaranteed to be defined.

This function is only called whenchatOptions.outputSchema is truthy (line 347), andoutputSchema is destructured fromoptions. This check will never trigger.

-  // Validate against the schema-  if (!outputSchema) {-    throw new Error('outputSchema is required for structured output')-  }-   const result = outputSchema.safeParse(parsed)

---

223-224:Missing newline between type definitions.

There's a missing newline separator before theGenerateReturnType comment, which reduces readability:

-      : never /** Infer the return type based on adapter kind, schema, and stream */-type GenerateReturnType<+      : never++/** Infer the return type based on adapter kind, schema, and stream */+type GenerateReturnType<

---

550-589:generateSummaryStream doesn't actually stream.

This function awaits the fullsummarize() result before yielding any chunks, so it provides a streaming interface but not streaming behavior. This may be intentional for API consistency, but consider documenting this limitation or implementing true streaming if the underlying adapter supports it.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

examples/ts-react-chat/src/routes/api.tanchat.ts (1)

2-8:Remove top-leveltest = ai(openaiImage(...)) and associated imports

Thisconst test = ai({ adapter: openaiImage(), ... }) is:

• Unused in the route logic, and
• For image adapters, side‑effectful: theai() implementation immediately callsadapter.generateImages, so this will generate images at module load time for every server start / hot reload.

A very similar unusedtest block was flagged previously; this is effectively the same issue with a valid model instead of'gpt-5'.

You can safely drop it and the now‑unused imports (ai,openaiImage,openaiSummarize,openaiText,z), e.g.:

-import { ai, chat, maxIterations, toStreamResponse } from '@tanstack/ai'-import {-  openai,-  openaiImage,-  openaiSummarize,-  openaiText,-} from '@tanstack/ai-openai'+import { chat, maxIterations, toStreamResponse } from '@tanstack/ai'+import { openai } from '@tanstack/ai-openai'@@-import z from 'zod'@@-const test = ai({-  adapter: openaiImage(),-  model: 'gpt-image-1',-  prompt:-    'A cute baby sea otter wearing a beret and glasses, sitting at a small cafe table, sipping a cappuccino, with a croissant on a plate. The background shows a picturesque Parisian street with the Eiffel Tower in the distance. The scene is bathed in the warm, golden light of a late afternoon.',-  numberOfImages: 2,-  size: 'auto',-  providerOptions: {-    quality: 'high',-  },-})-

That keeps the example route focused on the chat flow without unexpected image API calls.

Also applies to: 12-12, 21-31

packages/typescript/ai-gemini/src/model-meta.ts (1)

223-253:Gemini image model metadata and exports look consistent

The new image model entries (GEMINI_2_5_FLASH_IMAGE, GEMINI_2_FLASH_IMAGE, IMAGEN_* variants) and theGEMINI_IMAGE_MODELS /GeminiImageModels exports line up correctly and give the image adapter a clean, typed model surface. Only nit: you might consider movingGeminiImageModels belowGEMINI_IMAGE_MODELS to avoid the forward reference and mirror the pattern used forGeminiModels, but that’s purely cosmetic.

Also applies to: 421-450, 517-607, 782-793

packages/typescript/ai/src/core/generate.ts (1)

24-281:Unifiedai() routing and typing look correct

TheGenerateAdapter/AnyGenerateAdapter unions,GenerateOptionsFor/GenerateReturnType, and theai() overload cleanly discriminate onadapter.kind and produce the expected API shapes:

• chat → stream or structuredPromise based onoutputSchema
• embedding →Promise<EmbeddingResult>
• summarize → streaming vs non‑streaming viastream
• image →Promise<ImageGenerationResult>

The model/providerOptions extractor helpers (ChatProviderOptionsForModel,ImageProviderOptionsForModel, etc.) also give nice per‑model typing without leaking index‑signature maps. Aside from the summarizeproviderOptions wiring noted separately, this core looks well‑structured.

Also applies to: 365-400, 472-598, 664-677, 685-704

packages/typescript/ai-gemini/tests/image-adapter.test.ts (1)

115-160:RelaxgenerateImages call expectation to tolerate extra config fields

ThegenerateImages test asserts:

expect(mockGenerateImages).toHaveBeenCalledWith({model:'imagen-3.0-generate-002',prompt:'A cat wearing a hat',config:{numberOfImages:1,aspectRatio:'1:1',},})

But the adapter’sbuildConfig currently also includesimageSize (and may gain more fields over time). With stricttoHaveBeenCalledWith, any additional keys onconfig will cause this test to fail even though the call is still correct.

Consider making this more robust, e.g.:

expect(mockGenerateImages).toHaveBeenCalledWith({model:'imagen-3.0-generate-002',prompt:'A cat wearing a hat',config:expect.objectContaining({numberOfImages:1,aspectRatio:'1:1',}),})

This keeps the important contract assertions while allowing harmless additions to the request config.

packages/typescript/ai-openai/tests/image-adapter.test.ts (1)

135-187:MakegenerateImages request expectations less brittle

The tests currently assert the fullimages.generate call shape:

expect(mockGenerate).toHaveBeenCalledWith({model:'gpt-image-1',prompt:'A cat wearing a hat',n:1,size:'1024x1024',stream:false,})

This will start failing as soon asbuildRequest adds legitimate fields (e.g.,response_format, quality/style options).

You can keep the important guarantees while future‑proofing the test by loosening it slightly:

expect(mockGenerate).toHaveBeenCalledWith(expect.objectContaining({model:'gpt-image-1',prompt:'A cat wearing a hat',n:1,size:'1024x1024',stream:false,}),)

Same idea applies to the second test that only checks ID generation; the call shape doesn’t need to be pinned exactly there either.

Also applies to: 189-218

packages/typescript/ai-gemini/src/adapters/image.ts (1)

90-121:Minor cleanup in config/result shaping

Two small nits you might consider:

• InbuildConfig,imageSize: size will serialize away whensize isundefined, so it’s harmless but could be omitted entirely when not set for slightly cleaner requests.
• IntransformResponse, you don’t need to explicitly setusage: undefined; omitting the property keeps the result shape cleaner and avoids consumers checking for an explicitlyundefined field.

Example tweak:

  private buildConfig(    options: ImageGenerationOptions<GeminiImageProviderOptions>,  ): GenerateImagesConfig {    const { size, numberOfImages, providerOptions } = options-   return {-     numberOfImages: numberOfImages ?? 1,-     imageSize: size,-     aspectRatio: size ? sizeToAspectRatio(size) : undefined,-     ...providerOptions,-   }+   return {+     numberOfImages: numberOfImages ?? 1,+     ...(size && { imageSize: size, aspectRatio: sizeToAspectRatio(size) }),+     ...providerOptions,+   }  }  private transformResponse(    model: string,    response: GenerateImagesResponse,  ): ImageGenerationResult {    const images: Array<GeneratedImage> = (response.generatedImages ?? []).map(      (item) => ({        b64Json: item.image?.imageBytes,        revisedPrompt: item.enhancedPrompt,      }),    )    return {      id: generateId(this.name),      model,      images,-     usage: undefined,    }  }

packages/typescript/ai-openai/src/adapters/image.ts (1)

59-92:Double‑checksize: 'auto' semantics across models

Right nowgenerateImages relies onvalidateImageSize, which short‑circuits forsize === 'auto', so'auto' is effectively allowed for any model. If DALL·E 2/3 do not support'auto' forsize, these calls will only fail at the OpenAI API level instead of being caught by your validator.

A tighter approach (if the API requires it) would be to only treat'auto' as special for the GPT‑Image models and run validation (and/or throw) for'auto' on DALL·E:

export function validateImageSize(  model: string,  size: string | undefined,): void {-  if (!size || size === 'auto') return+  if (!size) return++  const isGptImageModel =+    model === 'gpt-image-1' || model === 'gpt-image-1-mini'+  if (size === 'auto' && isGptImageModel) return

Please verify this against the current OpenAI image docs before changing behavior.

packages/typescript/ai-openai/src/image/image-provider-options.ts (2)

213-237:ClarifyvalidateImageSize behavior for'auto' and per‑model sizes

The validator short‑circuits forsize === 'auto', which means'auto' is effectively accepted for all models even though only the GPT‑Image models include'auto' in their documented size sets. If DALL·E 2/3 don’t support'auto', this defeats the purpose of early validation.

Consider:

• Restricting the'auto' fast‑path to GPT‑Image models only, and
• Potentially usingOpenAIImageModelSizeByName (or a typed helper) instead of a rawRecord<string, Array<string>> to keep the table aligned with the type aliases.

This keeps runtime validation in sync with the declared capabilities.

---

264-297:Optional: enforce documentedbackground/output_format constraint

The JSDoc forbackground says that when'transparent',output_format must be'png' or'webp', butvalidateBackground currently only guards thatbackground is used with GPT‑Image models, not that the output format is compatible.

If you want runtime parity with the docs (especially for JS consumers orany usage), consider extending the validation input to includeoutput_format and adding a simple check:

-interface ImageValidationOptions {-  prompt: string-  model: string-  background?: 'transparent' | 'opaque' | 'auto' | null-}+interface ImageValidationOptions {+  prompt: string+  model: string+  background?: 'transparent' | 'opaque' | 'auto' | null+  output_format?: GptImageOutputFormat+}export const validateBackground = (options: ImageValidationOptions) => {  if (options.background) {    const supportedModels = ['gpt-image-1', 'gpt-image-1-mini']    if (!supportedModels.includes(options.model)) {      throw new Error(        `The model ${options.model} does not support background option.`,      )    }++    if (+      options.background === 'transparent' &&+      options.output_format &&+      options.output_format !== 'png' &&+      options.output_format !== 'webp'+    ) {+      throw new Error(+        `Transparent background requires output_format 'png' or 'webp', got '${options.output_format}'.`,+      )+    }  }}

packages/typescript/ai/src/types.ts (1)

1044-1093:ChatOptionsForChatAdapter mirrors ChatStreamOptionsForModel; minor Omit nit

TheChatOptionsForChatAdapter helper matches the structure ofChatStreamOptionsForModel, constrainingproviderOptions by model andmessages by model input modalities and metadata, which is exactly what you want for the newChatAdapter abstraction.

One tiny nit: theOmit<ChatOptions, 'model' | 'providerOptions' | 'responseFormat' | 'messages'> still refers to'responseFormat', while the current options useoutput?: ResponseFormat<...>. This is harmless (the extra key is ignored inOmit), but you could replace'responseFormat' with'output' for accuracy:

-    ? Omit<-        ChatOptions,-        'model' | 'providerOptions' | 'responseFormat' | 'messages'-      > & {+    ? Omit<ChatOptions, 'model' | 'providerOptions' | 'output' | 'messages'> & {

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro