マルチ LLM コンテキスト管理における隠れた課題

複数の LLM プローバイダーを跨ぐ AI プロダクトを構築する際に直面する課題は、開発者が予測しないことが多い：コンテキストウィンドウは互換性がありません。見かけ上、マルチ LLM システムでのコンテキスト管理は簡易なように見えます。会話の長さを追跡し、必要な場合を削り、進めます。しかし、実際にはそれ以上の複雑さがあり、OpenAI、Anthropic、Google、Cohere、xAI など複数のプロバイダー間でリクエストをルートを設定する場合、製品の微妙な方法で破損する可能性がある根本的な不一致が存在します。 すべての主要な LLM プローバイダーは独自のトークナイザーを使用しています。これらのトークナイザーは合意していません。同じテキストブロックも、それを処理するモデルに応じて異なるトークンカウントを生み出します。その差は 10-20% にあり、時にはそれ以上に達します。 これは現実において何を意味するか：一つのモデルのコンテキストウィンドウには快適にフィットする会話が、もう一つのモデルでは静かに過剰になり得ます。OpenAI にルーティングされたプロンプトが 1,200 トークンとしてカウントされる場合、同じプロンプトが Claude にルーティングされた場合、1,450 トークンとなる可能性があります。そのギャップは重要です。 失敗モードは境界面で現れる傾向にあります。会話を途中のプロバイダー変換を行うと、新しいモデルは完全な前のコンテキストをインジェストする必要があります。コンテキスト管理レイヤーが前のモデルのトークナイザーに基づいて校正された場合、新しいモデルは、新しいことを反応する前に、すでに制限または超過の状態にあるコンテキストを見てしまいます。 これは一般的な 3 つの失敗パターンを生み出します： 1. 予期せぬコンテキストウィンドウの超過：以前は動作していた会話が今、制限を越えています 2. 一貫性の欠如した短縮：異なるモデルは異なる点で短縮し、モデルが実際に見る以前のコンテキストを変更します 3. システムで使用した数字がモデルが実際に使用した数字と一致しないため、予測できないルースティングの失敗 単一の「トークン見積もり」を十分な安全マージンと共に維持するという直感はあります。問題は、必要なマージンがプロバイダー、モデルバージョン、コンテンツタイプ（コードは文体よりも異なるトークン化される）によって変動することです。一つのユースケースに基づいて校正されたマージンは、他のユースケースでは失敗を引き起こすほど緊密、または不十分な短縮を招き、会話品質を低下させるほど寛大なものになります。 堅牢なマルチ LLM コンテキスト管理レイヤーは、トークンカウントをプロバイダー固有にします。単一の見積もりを維持する代わりに、実際の目標モデルがどのように測定するかのようにそれぞれのプロンプトを測定します。ルーティングレイヤーは、リクエストが送信される前にこれらのプロバイダー固有の測定値を用いて判断を行います。 これにより、システムはコンテキストの制限の前倒しで動作します。会話がいかにして制限の端に近づいているかを認識し、特定のモデルにリクエストを送信するために校正された履歴を削ったり圧縮したりし、間違ったトークンカウントから生じる価格や失敗の驚きから回避します。 結果としてユーザーが見るべきもの：どのモデルがそれを担当しているかに関わらず、スムーズな会話体験です。「すべてのモデルはわずかに異なるトークンの言語で話します」という複雑さは、プロダクトを使用する人々にとって目に見えないインフラストラクチャレイヤーの中に留まります。 これは、私たちが実施している適応コンテキストウィンドウ管理コンポーネントにおけるアプローチであり、それは私たちがより広くマルチ LLM ルーティングを考えている方法の一部となっています。 Rob Imbeault 2026 年 4 月 17 日

Why token counting isn't a solved problem when building across providers Building AI products that span multiple LLM providers involves a challenge most developers don't anticipate until they hit it: context windows are not interoperable. On the surface, managing context in a multi-LLM system seems straightforward. You track how long conversations get, trim when needed, and move on. In practice, it's considerably more complex — and if you're routing requests across providers like OpenAI, Anthropic, Google, Cohere, or xAI, there's a fundamental mismatch that can break your product in subtle ways. Every major LLM provider uses its own tokenizer. These tokenizers don't agree. The same block of text produces different token counts depending on which model processes it. The difference is often 10–20%, sometimes more. What this means in practice: a conversation that fits comfortably in one model's context window may silently overflow another's. A prompt routed to OpenAI might count as 1,200 tokens; the same prompt routed to Claude might count as 1,450. That gap matters. The failure modes tend to show up at the boundaries. When you switch providers mid-conversation, the new model has to ingest the full prior context. If your context management layer was calibrated to the previous model's tokenizer, the new model may see a context that's already at or over the limit — before it's even responded to anything new. This produces three common failure patterns: Unexpected context-window overflow: the conversation that worked before now breaches the limit Inconsistent truncation: different models truncate at different points, changing what prior context the model actually sees Routing failures that are unpredictable because the numbers your system used don't match the numbers the model actually used The instinct is to maintain a single "token estimate" with a generous safety margin. The problem is that the margin you'd need varies by provider, model version, and content type (code tokenizes differently than prose). A margin calibrated for one use case will either be too tight for another, causing failures, or too generous, causing unnecessary truncation that degrades conversation quality. A robust multi-LLM context management layer makes token counting provider-specific. Rather than maintaining a single estimate, it measures each prompt the way the actual target model will measure it. The routing layer uses these per-provider measurements to make decisions before requests are sent. This lets the system stay ahead of context limits: it knows when a conversation is approaching an edge, trims or compresses history calibrated to the specific model receiving the request, and avoids the pricing and failure surprises that come from miscounted tokens. The end result is what users should see: a smooth conversation experience, regardless of which model is serving it. The complexity of "every model speaks a slightly different token language" stays inside the infrastructure layer, invisible to the people using the product. This is the approach we've taken in our adaptive context window management component, and it's become a foundational part of how we think about multi-LLM routing more broadly. Rob Imbeault Apr 17, 2026