diff --git a/docs/_scripts/model_feat_table.py b/docs/_scripts/model_feat_table.py
index 7c2c4bb2f4..6099950844 100644
--- a/docs/_scripts/model_feat_table.py
+++ b/docs/_scripts/model_feat_table.py
@@ -34,12 +34,12 @@ sidebar_class_name: hidden
 import DocCardList from "@theme/DocCardList";
 
 ## Features (natively supported)
-All LLMs implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abtach`, `stream`, `astream`. This gives all LLMs basic support for async, streaming and batch, which by default is implemented as below:
+All LLMs implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abatch`, `stream`, `astream`. This gives all LLMs basic support for async, streaming and batch, which by default is implemented as below:
 - *Async* support defaults to calling the respective sync method in asyncio's default thread pool executor. This lets other async functions in your application make progress while the LLM is being executed, by moving this call to a background thread.
 - *Streaming* support defaults to returning an `Iterator` (or `AsyncIterator` in the case of async streaming) of a single value, the final result returned by the underlying LLM provider. This obviously doesn't give you token-by-token streaming, which requires native support from the LLM provider, but ensures your code that expects an iterator of tokens can work for any of our LLM integrations.
 - *Batch* support defaults to calling the underlying LLM in parallel for each input by making use of a thread pool executor (in the sync batch case) or `asyncio.gather` (in the async batch case). The concurrency can be controlled with the `max_concurrency` key in `RunnableConfig`.
 
-Each LLM integration optionally can implement native support for async, streaming or batch, which, for providers that support it, can be more efficient.
+Each LLM integration can optionally provide native implementations for async, streaming or batch, which, for providers that support it, can be more efficient. The table shows, for each integration, which features have been implemented with native support.
 
 {table}
 
@@ -57,12 +57,13 @@ sidebar_class_name: hidden
 import DocCardList from "@theme/DocCardList";
 
 ## Features (natively supported)
-All ChatModels implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abtach`, `stream`, `astream`. This gives all ChatModels basic support for async, streaming and batch, which by default is implemented as below:
+All ChatModels implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abatch`, `stream`, `astream`. This gives all ChatModels basic support for async, streaming and batch, which by default is implemented as below:
 - *Async* support defaults to calling the respective sync method in asyncio's default thread pool executor. This lets other async functions in your application make progress while the ChatModel is being executed, by moving this call to a background thread.
 - *Streaming* support defaults to returning an `Iterator` (or `AsyncIterator` in the case of async streaming) of a single value, the final result returned by the underlying ChatModel provider. This obviously doesn't give you token-by-token streaming, which requires native support from the ChatModel provider, but ensures your code that expects an iterator of tokens can work for any of our ChatModel integrations.
 - *Batch* support defaults to calling the underlying ChatModel in parallel for each input by making use of a thread pool executor (in the sync batch case) or `asyncio.gather` (in the async batch case). The concurrency can be controlled with the `max_concurrency` key in `RunnableConfig`.
 
-Each ChatModel integration optionally can implement native support for async, streaming or batch, which, for providers that support it, can be more efficient.
+Each ChatModel integration can optionally provide native implementations to truly enable async or streaming.
+The table shows, for each integration, which features have been implemented with native support.
 
 {table}
 
diff --git a/docs/docs_skeleton/vercel_build.sh b/docs/docs_skeleton/vercel_build.sh
index 1c7e3799d7..cb3ed85ee7 100755
--- a/docs/docs_skeleton/vercel_build.sh
+++ b/docs/docs_skeleton/vercel_build.sh
@@ -51,3 +51,4 @@ cp -r extras/* docs_skeleton/docs
 cd docs_skeleton
 nbdoc_build
 python3.11 generate_api_reference_links.py
+python3.11 ../
diff --git a/docs/extras/integrations/chat/index.mdx b/docs/extras/integrations/chat/index.mdx
index 76c8d8b677..e3b05653e8 100644
--- a/docs/extras/integrations/chat/index.mdx
+++ b/docs/extras/integrations/chat/index.mdx
@@ -8,12 +8,13 @@ sidebar_class_name: hidden
 import DocCardList from "@theme/DocCardList";
 
 ## Features (natively supported)
-All ChatModels implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abtach`, `stream`, `astream`. This gives all ChatModels basic support for async, streaming and batch, which by default is implemented as below:
+All ChatModels implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abatch`, `stream`, `astream`. This gives all ChatModels basic support for async, streaming and batch, which by default is implemented as below:
 - *Async* support defaults to calling the respective sync method in asyncio's default thread pool executor. This lets other async functions in your application make progress while the ChatModel is being executed, by moving this call to a background thread.
 - *Streaming* support defaults to returning an `Iterator` (or `AsyncIterator` in the case of async streaming) of a single value, the final result returned by the underlying ChatModel provider. This obviously doesn't give you token-by-token streaming, which requires native support from the ChatModel provider, but ensures your code that expects an iterator of tokens can work for any of our ChatModel integrations.
 - *Batch* support defaults to calling the underlying ChatModel in parallel for each input by making use of a thread pool executor (in the sync batch case) or `asyncio.gather` (in the async batch case). The concurrency can be controlled with the `max_concurrency` key in `RunnableConfig`.
 
-Each ChatModel integration optionally can implement native support for async, streaming or batch, which, for providers that support it, can be more efficient.
+Each ChatModel integration can optionally provide native implementations to truly enable async or streaming.
+The table shows, for each integration, which features have been implemented with native support.
 
 Model|Invoke|Async invoke|Stream|Async stream
 :-|:-:|:-:|:-:|:-:
diff --git a/docs/extras/integrations/llms/index.mdx b/docs/extras/integrations/llms/index.mdx
index a76d217ad0..504d6e8bc3 100644
--- a/docs/extras/integrations/llms/index.mdx
+++ b/docs/extras/integrations/llms/index.mdx
@@ -8,12 +8,12 @@ sidebar_class_name: hidden
 import DocCardList from "@theme/DocCardList";
 
 ## Features (natively supported)
-All LLMs implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abtach`, `stream`, `astream`. This gives all LLMs basic support for async, streaming and batch, which by default is implemented as below:
+All LLMs implement the Runnable interface, which comes with default implementations of all methods, ie. `ainvoke`, `batch`, `abatch`, `stream`, `astream`. This gives all LLMs basic support for async, streaming and batch, which by default is implemented as below:
 - *Async* support defaults to calling the respective sync method in asyncio's default thread pool executor. This lets other async functions in your application make progress while the LLM is being executed, by moving this call to a background thread.
 - *Streaming* support defaults to returning an `Iterator` (or `AsyncIterator` in the case of async streaming) of a single value, the final result returned by the underlying LLM provider. This obviously doesn't give you token-by-token streaming, which requires native support from the LLM provider, but ensures your code that expects an iterator of tokens can work for any of our LLM integrations.
 - *Batch* support defaults to calling the underlying LLM in parallel for each input by making use of a thread pool executor (in the sync batch case) or `asyncio.gather` (in the async batch case). The concurrency can be controlled with the `max_concurrency` key in `RunnableConfig`.
 
-Each LLM integration optionally can implement native support for async, streaming or batch, which, for providers that support it, can be more efficient.
+Each LLM integration can optionally provide native implementations for async, streaming or batch, which, for providers that support it, can be more efficient. The table shows, for each integration, which features have been implemented with native support.
 
 Model|Invoke|Async invoke|Stream|Async stream|Batch|Async batch
 :-|:-:|:-:|:-:|:-:|:-:|:-: