diff --git a/api-reference/api-spec.mdx b/api-reference/api-spec.mdx
index e55db96e..02f34f3c 100644
--- a/api-reference/api-spec.mdx
+++ b/api-reference/api-spec.mdx
@@ -5,7 +5,7 @@ description: "Full Venice API reference: auth, OpenAI compatibility, headers, an
 "og:description": "Complete API reference including authentication, debugging, OpenAI compatibility, and response headers"
 ---
 
-The Venice API offers HTTP-based REST and streaming interfaces for building AI applications with uncensored models and private inference. You can create with text generation, image creation, embeddings, and more, all without restrictive content policies. Integration examples and SDKs are available in the [documentation](/overview/getting-started). Our API reference is also available as a [OpenAPI YAML spec.](https://api.venice.ai/doc/api/swagger.yaml)
+The Venice API offers HTTP-based REST and streaming interfaces for building AI applications with uncensored models and private inference. You can create with text generation, image creation, embeddings, and more, all without restrictive content policies. Integration examples and SDKs are available in the [documentation](/overview/getting-started). Our API reference is also available as an [OpenAPI YAML spec.](https://api.venice.ai/doc/api/swagger.yaml)
 
 ## Authentication
 
diff --git a/learn/private-rag-bot.mdx b/learn/private-rag-bot.mdx
index 1d3e71ab..a184f63d 100644
--- a/learn/private-rag-bot.mdx
+++ b/learn/private-rag-bot.mdx
@@ -132,7 +132,7 @@ For a private local bot, start with an on-disk local Qdrant path:
 qdrant = QdrantClient(path="./qdrant_data")
 ```
 
-There's a few different ways to handle deployment in production. However if you use a remote Qdrant deployment, remember that your document chunks and metadata will be stored there. Venice can keep the inference layer private, but you should still choose the right Qdrant deployment for your data.
+There are a few different ways to handle deployment in production. However if you use a remote Qdrant deployment, remember that your document chunks and metadata will be stored there. Venice can keep the inference layer private, but you should still choose the right Qdrant deployment for your data.
 
 ## Loading and Chunking Documents
 
@@ -196,7 +196,7 @@ def chunk_text(text: str, chunk_size: int, chunk_overlap: int) -> list[str]:
     return chunks
 ```
 
-A starting chunk size of `1000` characters with `150` characters of overlap is a good default for mixed Markdown and text documents. Smaller chunks can improve precision. Larger chunks can preserve more context. The right setting will often on depend on the kinds of documents you are storing.
+A starting chunk size of `1000` characters with `150` characters of overlap is a good default for mixed Markdown and text documents. Smaller chunks can improve precision. Larger chunks can preserve more context. The right setting will often depend on the kinds of documents you are storing.
 
 ## Embedding Documents with Venice
 
diff --git a/learn/rust-llm-gateway.mdx b/learn/rust-llm-gateway.mdx
index f46440f4..d12a7734 100644
--- a/learn/rust-llm-gateway.mdx
+++ b/learn/rust-llm-gateway.mdx
@@ -53,7 +53,7 @@ The reference implementation is a small Rust service with a few clear parts:
 
 *A client sends an OpenAI-compatible request to the gateway. The gateway authenticates the caller, checks rate limits, forwards the request to Venice, and records telemetry along the way.*
 
-As part of the gateway, we'll be ensuring that this service remains horizontally scalable with the least amount of surface area covered when it comes to the API itself. There's a few reasons for this - one of them primarily being that if you have a very high amount of throughput for example, you will almost certainly want to use replicas (i.e., spin up more than 1 of the same service). This means that if you aren't already, architecturally you'll want to put your original service and the replicas behind a load balancer so that if one container or service goes down, the entire service does not experience an outage.
+As part of the gateway, we'll be ensuring that this service remains horizontally scalable with the least amount of surface area covered when it comes to the API itself. There are a few reasons for this - one of them primarily being that if you have a very high amount of throughput for example, you will almost certainly want to use replicas (i.e., spin up more than 1 of the same service). This means that if you aren't already, architecturally you'll want to put your original service and the replicas behind a load balancer so that if one container or service goes down, the entire service does not experience an outage.
 
 Additionally, we will also assume that we own API key creation in some manner, although the gateway service shouldn't be minting them in isolation. This will be represented as a Postgres table that we seed when used locally. In production, this would typically be handled by the authentication service. Although it is possible to handle creating an API key upstream for every user who uses your LLM gateway, in practice this is not generally advisable. By offloading this responsibility to the upstream service, you also offload any control you would normally have - which means you can't fully enforce things like rate limiting and spend caps.