Clarification requested

What is the supported way to let an application own conversation compaction completely, without OpenAIAdapter silently trimming earlier messages? In newer releases, is maxInputTokens: Infinity an intentional, supported configuration, or merely an implementation detail? Could the adapter documentation include this use case and its prompt-cache implications?

Our production app is pinned to @copilotkit/runtime, react-core, and react-ui 1.10.6. We initially worked around the unconditional cutoff locally. Before filing, we researched the newer implementation and found that a configurable limit already exists. This is not another request to add maxInputTokens.

Prior research and existing explanation

• 🐛 Bug: OpenRouter models default to 128k token limit instead of actual model limits #1950 already reported the 128k fallback for OpenRouter model IDs. Its proposed PR fix: allow maxTokens override for unrecognized OpenAI-compatible models (#1950) #3809 was closed without merging.
• 🚀 Feature Request: Make the LLM input token limits configurable #2405 requested configurable input limits, including for larger model context windows. fix: add configurable maxInputTokens to OpenAI and Anthropic adapters (#2405) #3823 merged that option on April 16, 2026. We inspected published package sources: 1.56.0 lacks maxInputTokens; 1.56.1 has it.
• 🐛 Bug: Conversation gets broken if token limit message trim is applied between tool_use and tool_result #2450 / fix: ensure tool_result messages have matching tool_use after token trimming (#2450) #3820 cover tool-result pairing after trimming in the Anthropic adapter, a separate consequence of trimming.
• docs(backend): message-history trimming recipe for agents that store their own history #6898 / feat(core): let an app trim the history it sends to a runtime agent #6926 and the message-history guide concern reducing browser-forwarded history for backends that already store it. That is a different layer from this legacy OpenAI adapter's input cutoff.
• 🚀 Feature Request: App Context / state note in system_message invalidates provider prompt caching on every turn #7480 discusses prompt-cache invalidation from dynamic application context, rather than removal of earlier conversation turns.
• We searched open/closed issues and PRs for limitMessagesToTokenCount, maxInputTokens, Infinity, token limits, trimming, compaction, and cache/cost effects. We did not find an explicit supported no-trimming contract or documentation for app-owned compaction.

The code and adapter docs explain trimming as a way to fit the model context window. The historical token-counting change replaced tokenization with text.length / 3 for performance. We understand the default overflow-protection goal; the missing guidance is how an application with its own context budgeting and compaction opts out reliably.

At inspected main commit cf326fab12f1738f95ba23553634b9ce6fb73227, the constructor exposes maxInputTokens and passes it to the limiter. The limiter still uses a 128,000 fallback for unrecognized model IDs. forwardedParameters.maxTokens controls output (max_completion_tokens), not this input budget.

Why we flagged this: long-session input costs

Our app uses OpenRouter through the OpenAI-compatible adapter and already has an explicit compaction flow that replaces history with a handover. Between compactions, preserving the conversation prefix is important for provider prompt caching.

Once the stored conversation grew beyond the adapter's approximate 128k budget, dropping the oldest turns changed the prefix repeatedly. The outgoing request could remain around 125k tokens, but much less of it was cached. Representative recorded requests from one session, on the same DeepSeek model and Together provider:

That is roughly 18 times the input charge for almost the same input size, making continued long sessions unexpectedly expensive. Across the session, chat had an 87.5% token-weighted cache rate; a separate sandbox conversation bypassing this adapter achieved 97.4%.

These are observations, not a controlled provider benchmark or a claim that every miss comes from trimming. We verified the local cutoff mechanism and its removal separately. We excluded an isolated 0% request after a long idle gap from this comparison. Together's caching documentation explains why truncating or rewriting earlier history invalidates cache reuse from that point onward.

Small local reproduction / configuration check

Exercising the current limiter with an unrecognized model ID and this synthetic history:

const messages = [
  { role: "system", content: "policy" },
  { role: "user", content: "oldest instruction" },
  { role: "assistant", content: "x".repeat(500_000) },
  { role: "user", content: "newest instruction" },
];

• Default limit: only the system and newest user message remain.
• 0: same default cutoff, not an opt-out.
• Infinity: all four messages remain.
• A sufficiently large finite override also preserves these messages, but eventually starts trimming again.

This suggests the following configuration can replace our patch after an upgrade, but we would appreciate confirmation that it is supported:

new OpenAIAdapter({ openai, model, maxInputTokens: Infinity });

Our temporary workaround on 1.10.6

We remove only the OpenAI adapter's limiting call:

- openaiMessages = limitMessagesToTokenCount(openaiMessages, tools, model);
+ // Preserve history; the application owns compaction.

A version-checked, idempotent pre-dev/pre-build script applies this to the published CommonJS and ESM adapter copies, validates both before writing, and fails if the expected version or code shape changes. It leaves upstream message conversion, tool-result filtering, and streaming intact. This is a compatibility workaround for our old pin, not a recommendation that current users patch dependencies.

We tested the actual runtime with history, system prompts, and schemas beyond the old limit, plus tool pairs and images. An isolated Nix-packaged app smoke test also sent the full oversized synthetic history to a local mock OpenRouter and streamed the reply back. No paid inference was needed for those tests. Provider context-limit errors remain visible; our app's compaction handles reducing the conversation.

Requested documentation / guidance

1. Is maxInputTokens: Infinity a supported no-trimming mode for applications that own compaction? If so, please document and regression-test it; otherwise, what is the supported alternative?
2. Is automatic trimming intended strictly as a default overflow guard, and should app-owned compaction bypass it rather than set a larger finite estimate?
3. Could the docs warn that repeated removal of early turns can substantially increase input costs by invalidating prompt caches, even while the visible transcript still contains those turns?
4. If v1 deprecation changes the recommended solution, please point to the v2 configuration/adapter path that preserves application-managed history without an implicit cutoff.