⚠️ Potential issue | 🟠 Major

Missing thinkingConfig despite function name implying thinking is enabled.

The function callGeminiWithThinking no longer configures thinking in providerOptions. Compare with callFastGemini (lines 20-25) which includes thinkingConfig: { thinkingBudget: 256, includeThoughts: true }. The function name is now misleading—either add the thinking configuration or rename the function.

Additionally, this function uses HarmBlockThreshold.OFF while all other functions in this file use HarmBlockThreshold.BLOCK_NONE. This inconsistency may cause unexpected behavior differences between Gemini call variants.

   const { text } = await generateText({
     model: google("gemini-3-flash-preview"),
     prompt,
     experimental_telemetry: { isEnabled: true, recordInputs: true, recordOutputs: true },
-    providerOptions: { google: { safetySettings } },
+    providerOptions: {
+      google: {
+        safetySettings,
+        thinkingConfig: { thinkingBudget: 1024, includeThoughts: true },
+      },
+    },
   });

In `@apps/pipeline/src/callFastGemini.ts` around lines 78 - 94, The function
callGeminiWithThinking is missing the thinkingConfig and uses an inconsistent
HarmBlockThreshold; update the providerOptions passed to generateText inside
callGeminiWithThinking to include thinkingConfig: { thinkingBudget: 256,
includeThoughts: true } (matching callFastGemini) and change all safetySettings
thresholds from HarmBlockThreshold.OFF to HarmBlockThreshold.BLOCK_NONE so
behavior matches other Gemini variants; ensure you only modify the
providerOptions block in callGeminiWithThinking and keep the rest of the call
(model, prompt, experimental_telemetry) unchanged.

The api_key is read from process.env.AZURE_GROK_KEY but there's no check to ensure it's defined. If the environment variable is missing, api_key will be undefined, and the OpenAI client will be initialized with an invalid key. This will lead to runtime errors later on. It's better to fail fast with a clear error message if the key is not configured.

const api_key = process.env.AZURE_GROK_KEY;

if (!api_key) {
  throw new Error("Missing environment variable: AZURE_GROK_KEY");
}

const client = new OpenAI({ baseURL: endpoint, apiKey: api_key });

⚠️ Potential issue | 🟡 Minor

Missing API key validation before client initialization.

If AZURE_GROK_KEY is undefined, the OpenAI client will be created with an undefined API key, which will fail at runtime during the first API call rather than at module load time. Consider adding validation.

 const api_key = process.env.AZURE_GROK_KEY;
+
+if (!api_key) {
+  throw new Error("Missing AZURE_GROK_KEY environment variable");
+}

 const client = new OpenAI({ baseURL: endpoint, apiKey: api_key });

In `@apps/pipeline/src/callGrokAzure.ts` around lines 6 - 8, Ensure AZURE_GROK_KEY
is validated before creating the OpenAI client: check process.env.AZURE_GROK_KEY
(the api_key variable) and if it's missing/empty throw a clear Error or log and
exit, then only instantiate new OpenAI({ baseURL: endpoint, apiKey: api_key });
that way OpenAI client creation (the client variable) never occurs with an
undefined key and failure happens at startup instead of at first API call.

⚠️ Potential issue | 🟡 Minor

Return type may be null; consider handling.

completion.choices[0].message.content can be null when the model returns a refusal or empty response. The current signature implies it always returns a string.

-export const callGrokAzure = async (prompt: string) => {
+export const callGrokAzure = async (prompt: string): Promise<string> => {
   const completion = await client.chat.completions.create({
     messages: [{ role: "user", content: prompt }],
     model,
   });

-  return completion.choices[0].message.content;
+  const content = completion.choices[0].message.content;
+  if (content === null) {
+    throw new Error("Model returned null content");
+  }
+  return content;
 };

In `@apps/pipeline/src/callGrokAzure.ts` around lines 10 - 17, callGrokAzure
currently returns completion.choices[0].message.content which can be null;
update callGrokAzure to handle that case by checking completion and
completion.choices[0].message.content and either (a) return a safe fallback
string (e.g., empty string) or (b) throw a clear error, and update the function
signature accordingly to reflect string | null or throw; reference the symbols
callGrokAzure, completion, choices, and message.content when making the change
so the null-check covers completion.choices[0] and message.content before
returning.

Using zodSchema.shape to generate the JSON schema is not robust. This property only exists on z.object schemas and doesn't correctly represent the full schema structure expected by the OpenAI API, especially for nested objects, arrays, or non-object types. This can lead to runtime errors or incorrect schema validation.

Consider using a library like zod-to-json-schema for a more reliable conversion. For example:

import { zodToJsonSchema } from 'zod-to-json-schema';

// ... inside callGrokAzureWithSchema
const jsonSchema = zodToJsonSchema(zodSchema);

const completion = await client.chat.completions.create({
  // ...
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "response",
      strict: true,
      schema: jsonSchema,
    },
  },
});

This will require adding zod-to-json-schema as a dependency. The current implementation with @ts-expect-error is a strong indicator of a potential issue.

The API response completion.choices[0].message.content can be null. Attempting to JSON.parse(null) will result in null, which might be acceptable, but if the model returns an empty response for some reason, it's better to handle this case explicitly to avoid unexpected behavior or provide a clearer error message.

    const content = completion.choices[0].message.content;
    if (content === null) {
      throw new Error("Received null content from the model.");
    }
    result = JSON.parse(content) as T;

⚠️ Potential issue | 🟠 Major

cat -n apps/pipeline/src/callO3.ts

Remove the review concern: gpt-5.2 is available in the Chat Completions API.

The model is officially supported for all developers as of February 2026, including the direct OpenAI SDK path used here.

However, the callGpt5 function does not implement the required callModel<T> interface specified in the coding guidelines for apps/pipeline/src/call*.ts. The function accepts schema and maxRetries parameters but does not use them. Implement structured output handling via the schema parameter and retry logic to comply with the shared interface, or remove the unused parameters.

In `@apps/pipeline/src/callO3.ts` around lines 36 - 39, The callGpt5 function
currently calls client.chat.completions.create (chatCompletion) but does not
implement the callModel<T> interface: it accepts schema and maxRetries but never
uses them; update callGpt5 to either (A) implement structured output handling by
using the provided schema to request and validate structured output (e.g.,
include a system/instruction to output JSON matching schema, parse the model
response into type T and validate against schema) and add retry logic around
client.chat.completions.create honoring the maxRetries parameter with
exponential backoff and proper error propagation, or (B) remove the unused
schema and maxRetries parameters and update the signature to match the intended
simple call; reference symbols: callGpt5, callModel<T>, schema, maxRetries, and
client.chat.completions.create (chatCompletion) so reviewers can locate and
verify the changes.