docs: update doc for extension fields (#1590)

**Description**
Explained how the unified thinking field works across providers and
documented automatic translation: GCP Vertex AI (Gemini) →
generationConfig.thinkingConfig, while GCP Anthropic and AWS Bedrock use
it directly. Update extension field usage for both vendor specific and
unified fields.

---------

Signed-off-by: Dan Sun <[email protected]>
Co-authored-by: Ignasi Barrera <[email protected]>

Author: yuzisun

site/docs/capabilities/llm-integrations/vendor-specific-fields.md

@@ -1,29 +1,43 @@
 ---
 id: vendor-specific-fields
-title: Vendor-Specific Fields
+title: Extension Fields
 ---
 
-# Vendor-Specific Fields
+# Extension Fields
 
-The AI Gateway supports vendor-specific fields that allow you to specify backend-specific parameters directly as inline fields in your OpenAI-compatible requests. These fields are applied during the translation process to the target backend's native API format.
+The AI Gateway supports extension fields that allow you to specify unified or backend-specific parameters directly as inline fields in your OpenAI-compatible requests. These fields are applied during the translation process to the target backend's native API format.
 
 ## Overview
 
-Vendor-specific fields enable you to:
+Extension fields enable you to:
 
 - Use advanced backend-specific features not available in the OpenAI API
+- Use unified configuration fields that work across multiple providers not available in the OpenAI API
 
-The vendor-specific fields are specified as inline fields in your OpenAI request and are applied after the standard OpenAI-to-backend translation.
+### Vendor Extension Fields
+
+Vendor specific fields are specified as inline fields in your OpenAI request and are applied after the standard OpenAI-to-backend translation.
+
+### Unified Extension Fields
+
+For thinking/reasoning capabilities, you can use a unified `thinking` field that automatically translates to the correct backend-specific format:
+
+- **GCP Vertex AI (Gemini)**: Translates to `generationConfig.thinkingConfig`
+- **GCP Anthropic**: Uses `thinking` field directly
+- **AWS Bedrock**: Uses `thinking` field directly
+
+This unified approach allows you to write provider-agnostic requests while still leveraging thinking capabilities.
 
 ## Supported Backends
 
-The following backends support vendor-specific fields:
+The following backends support extension fields:
 
 ### GCP Vertex AI (Gemini)
 
 - **API Schema Name**: `GCPVertexAI`
 - **Supported Fields**:
-  - `generationConfig.thinkingConfig`: Configure thinking process for reasoning models. [Gemini Docs](https://cloud.google.com/vertex-ai/docs/reference/rest/v1/GenerationConfig#ThinkingConfig)
+  - `safetySettings`: Configure the safety settings for gemini models that translates to `SafetySetting`. [Gemini Docs](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/configure-safety-filters)
+  - `thinking`: Configure thinking process for reasoning models that automatically translates to `generationConfig.thinkingConfig`. [Gemini Docs](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/thinking)
 
 ### GCP Anthropic
 
@@ -39,11 +53,15 @@ The following backends support vendor-specific fields:
 
 ## Usage
 
-Add vendor-specific fields directly as inline fields in your OpenAI request:
+Add extension fields directly as inline fields in your OpenAI request:
+
+### Using Unified Thinking Configuration
+
+The simplest way to enable thinking capabilities across all providers is to use the unified `thinking` field:
 
 ```json
 {
-  "model": "gemini-1.5-pro",
+  "model": "gemini-2.5-pro",
   "messages": [
     {
       "role": "user",
@@ -54,21 +72,44 @@ Add vendor-specific fields directly as inline fields in your OpenAI request:
   "max_tokens": 2000,
   "thinking": {
     "type": "enabled",
-    "budget_tokens": 1000
-  },
-  "generationConfig": {
-    "thinkingConfig": {
-      "includeThoughts": true,
-      "thinkingBudget": 1000
-    }
+    "budget_tokens": 1000,
+    "includeThoughts": true
   }
 }
 ```
 
+This configuration will work with any provider that supports thinking, automatically translating to the correct backend format.
+
+### Using Provider-Specific Fields
+
+For more fine-grained control or provider-specific features, you can use the vendor-specific fields like `safetySettings` for gemini models:
+
+```json
+{
+  "model": "gemini-1.5-pro",
+  "messages": [
+    {
+      "role": "user",
+      "content": "Explain quantum computing and show me a simple code example."
+    }
+  ],
+  "temperature": 0.7,
+  "max_tokens": 2000,
+  "safetySettings": [
+    {
+      "category": "HARM_CATEGORY_HARASSMENT",
+      "threshold": "BLOCK_ONLY_HIGH"
+    }
+  ]
+}
+```
+
 ### Field Conflicts
 
 Vendor fields override translated fields when conflicts occur.
 
+When using unified thinking configuration, the `thinking` field takes precedence over any provider-specific thinking configurations.
+
 ### Unsupported Fields/Backends
 
 Fields and Backends other than specified in [Supported Backends](#supported-backends) will be ignored.