# Kimi Context Window: 2M Token Architecture, Limits, and Workspaces

Moonshot AI set an early benchmark for consumer AI context with a 2-million-character window in Kimi Chat, scaling frontier models like Kimi K3 to 1 million tokens. While massive context windows accommodate large documents, in-context ingestion introduces latency penalties, file upload ceilings, and attention degradation. Decoupling reference storage into persistent Fast.io workspaces accessible via remote MCP servers keeps prompts lean and avoids context rot.

Source: https://fast.io/resources/kimi-context-window/
Author: [Derek Labian](https://fast.io/authors/derek-labian/)
Last reviewed: 2026-10-11

## How the Kimi Context Window and Token Scaling Work

Dumping a five-hundred-page technical specification directly into an LLM context window feels like a breakthrough until you observe the time to first token and notice subtle constraints vanishing from the middle of the response. The Kimi context window refers to Moonshot AIs two-million-token input capacity, allowing the model to ingest up to two million Chinese characters or roughly one and a half million English words in a single inference session. When Moonshot AI introduced this two-million-character capacity to Kimi Chat in March 2024, it expanded the boundary of consumer AI document processing.

Understanding the difference between raw character counts and tokenizer tokens is essential when evaluating Moonshot AI's architecture. Large language models do not process raw text strings directly. Instead, tokenizers segment text into sub-word tokens that map to vector embeddings. The relationship between character volume, token count, and actual information density determines how much text fits into active memory before the system hits physical hardware limits.

### Character Versus Token Accounting in Bilingual Models

Tokenization efficiency varies across human languages and programming syntaxes. For English prose, common Byte-Pair Encoding (BPE) tokenizers average roughly four characters per token, or about three-quarters of a word per token. A technical document containing one hundred thousand English words converts to approximately one hundred thirty-three thousand tokens.

In Chinese text processing, character-to-token ratios behave differently. Moonshot AI's custom bilingual tokenizers are optimized for Han characters. While unoptimized tokenizers might consume two to three tokens per Chinese character by splitting UTF-8 byte sequences, Moonshot AI's vocabulary mapping compresses Chinese text efficiently. In Kimi's architecture, one token maps to roughly one and a half to two Chinese characters depending on semantic density.

As a result, an input capacity framed around two million Chinese characters corresponds to roughly one million tokens of dense Chinese text. When processing English documents, Kimi's ceiling accommodates over a million words across several thousand pages. That capacity equals approximately three thousand pages of single-spaced text, forty average-length non-fiction books, or an entire enterprise documentation library loaded into one prompt.

### The Kimi Model Lineup and Evolution to K3

Moonshot AI has structured its model ecosystem around distinct context tiers and specialized tasks. The legacy moonshot-v1 model family offered tiered context lengths before being retired on August 31, 2026, alongside kimi-k2.5 to focus resources on modern frontier models.

As of October 2026, the active Kimi production lineup includes three primary architectures:

* kimi-k3: The flagship foundation model featuring native visual understanding and deep reasoning for software engineering and complex knowledge work.
* kimi-k2.7-code: A specialized coding model designed to follow instructions across complex multi-file repositories with a dedicated high-speed variant.
* kimi-k2.6: A versatile multimodal model supporting image and video inputs alongside tool calling and flexible thinking modes.

While kimi-k3 and Kimi Chat accommodate massive input volumes, running inferences across hundreds of thousands of tokens introduces compute trade-offs that every technical team must evaluate.

## What Governs Kimi File Upload Limits and In-Context Parsing

To feed documentation into the Kimi context window, users and developers interact with Kimi's automated document extraction pipeline. In the Kimi Chat web interface and mobile applications, users drag and drop files directly into the prompt composer. In automated workflows, developers upload source materials through the Kimi Open Platform Files API using the purpose parameter set to file-extract.

In the Kimi API Platform, individual file uploads support up to 100 MiB per file with an organization storage quota of 10 GiB. Documents exceeding this file boundary return an immediate file-too-large error. Moonshot AI does not impose a rigid cap on the total count of files an organization can upload, managing usage through an organization-wide storage quota.

### Supported Formats and Server-Side Text Extraction

When a document is uploaded with purpose file-extract, Kimi does not pass raw binary data directly to the neural network. Instead, an ingestion pipeline parses the document server-side, extracts the textual content, normalizes formatting structures, and outputs clean Markdown text.

Kimi supports a comprehensive array of enterprise document and code formats:

* Formatted Documents: PDF (.pdf), Microsoft Word (.doc, .docx), Rich Text (.rtf), and EPUB eBooks (.epub).
* Structured Data: Spreadsheets (.xls, .xlsx, .csv), JSON (.json), YAML (.yaml, .yml), and configuration files (.ini, .conf).
* Presentations: Microsoft PowerPoint (.ppt, .pptx).
* Plain Text and Markup: Text files (.txt), Markdown (.md), and HTML pages (.html).
* Source Code: C (.c, .h), C++ (.cpp, .cxx, .cc), C# (.cs), Python (.py, .py3), TypeScript (.ts, .tsx), JavaScript (.js), Go (.go), Java (.java), PHP (.php), and styling sheets (.css).

The server-side parser preserves structural elements such as headings, bulleted lists, and table borders as Markdown syntax. This extracted Markdown is then injected into the conversation messages array as context before the model generates a response.

### Session Storage Ceilings and Multi-Document Context Ingestion

In Kimi Chat, user sessions can attach dozens of individual documents within a single conversation thread. This multi-document capability allows teams to cross-reference multiple quarterly reports, product specifications, and policy documents simultaneously.

However, document extraction introduces operational boundaries. While text extraction from standard PDFs operates reliably, complex visual diagrams, scanned handwriting, and embedded chart graphics inside PDFs require multimodal processing rather than text extraction. For image-heavy documents, files must be submitted through vision endpoints using purpose image.

Furthermore, once extracted text is added to the conversational context, it consumes active tokens for the duration of that session. Attaching twenty lengthy technical manuals can quickly consume several hundred thousand tokens before a developer writes their first prompt instruction.

## How Kimi, Claude, and Gemini Context Windows Compare

The expansion of LLM context capacity has created multiple approaches to document ingestion. Frontier AI providers balance context limits, file upload mechanics, and infrastructure economics differently.

The following comparison details current context windows, single-file upload thresholds, multi-file rules, and ingestion approaches across leading foundation models as of October 2026:

| Platform and Model | Context Window Limit | Single File Upload Limit | Multi-File Session Rules | Processing Architecture | Verification Date |
|---|---|---|---|---|---|
| Moonshot Kimi K3 | 1,000,000 tokens | 100 MiB per file | 10 GiB organization storage | Server-side Markdown extraction | 2026-10-11 |
| Moonshot Kimi Chat / k1.5 | 2,000,000 characters | 100 MiB per file | Up to 50 files per session | Extracted text prompt injection | 2026-10-11 |
| Anthropic Claude 3.5 / 3.7 Sonnet | 200,000 tokens | 500MB (chat) / 30MB (Projects) | Up to 20 files per chat; unlimited project files bounded by context | Native multimodal and text parsing | 2026-10-11 |
| Google Gemini 1.5 Pro | 2,000,000 tokens | 2 GB per file via File API | Up to 2M tokens total session payload | Direct multimodal tokenization | 2026-10-11 |
| OpenAI GPT-4o | 128,000 tokens | 512MB per file | Up to 20 files per assistant / 10,000 files per vector store | Automated file search and vector retrieval | 2026-10-11 |

Each platform architecture reflects different engineering priorities. While Anthropic focuses on deep reasoning within a 200,000-token window and OpenAI pairs 128,000 tokens with built-in vector search, Moonshot AI and Google have pushed native context windows to one and two million tokens.

### Comparing Frontier Model Context Windows

Anthropic documents strict boundaries for Claude file uploads. In standard Claude chat uploads, users can attach up to 20 files at up to 500MB each, while project file count is unlimited within the context window. In Claude Projects, individual files are limited to 30MB each. While Claude Projects imposes no numerical file-count cap, all uploaded project files must fit collectively within Claude's 200,000-token context window. If a team attaches five dense documents, the project context is fully exhausted, leaving no token headroom for system prompts or multi-turn queries.

Google Gemini 1.5 Pro takes an alternative approach by supporting a two-million-token window with direct audio and video ingestion. Users can upload video files spanning several hours or audio recordings spanning days through the Gemini File API.

Moonshot AI's Kimi bridges these worlds by providing extensive context capacity in kimi-k3 and Kimi Chat, backed by fast server-side text extraction for code and office documents. However, operating at the outer edge of these massive windows exposes fundamental physical constraints.

### When Context Windows Hit Hard Compute Constraints

Engineers frequently assume that a massive context window eliminates the need for external search indexing or database architecture. In practice, stuffing an entire repository or document archive into an active model prompt shifts the architectural bottleneck from storage capacity to compute efficiency.

When an LLM processes an input prompt, every input token must attend to every other token in the sequence. While long-context models employ advanced techniques like RingAttention, FlashAttention, and grouped-query attention to make computation feasible, the memory footprint required to store attention key-value states scales linearly with context length.

As context scales toward one and two million tokens, model inference encounters physical latency, cost, and attention retention trade-offs that in-context ingestion cannot bypass on its own.

## Why In-Context Ingestion Triggers Context Rot and Latency Spikes

Relying exclusively on massive context windows to read large document libraries creates three distinct operational points of failure: retrieval degradation, latency spikes, and compounding API billing. When an application loads hundreds of thousands of tokens of raw documentation into an inference call, the model must maintain attention across tens of thousands of sentences simultaneously. While synthetic needle-in-a-haystack benchmarks test whether a model can retrieve a single isolated sentence hidden in a text corpus, real-world document synthesis requires complex multi-hop reasoning. In production environments, models struggle to synthesize disparate facts scattered across hundreds of pages when those facts are surrounded by irrelevant text. These friction points undermine the perceived convenience of monolithic prompt loading.

### Attention Dilution and Retrieval Degradation Across Massive Windows

Attention dilution, commonly known as the lost-in-the-middle phenomenon, occurs when a transformer model exhibits higher retrieval accuracy for information located near the very beginning or the very end of a prompt compared to information located in the center.

When documentation spanning hundreds of thousands of tokens fills the context window, the middle portion of that payload experiences weaker attention weighting. Subtle constraints, such as specific compliance exceptions, edge-case configuration flags, or version incompatibilities, are frequently overlooked during response generation.

Furthermore, packing massive amounts of unstructured reference text into a prompt increases the probability of hallucinations. When an LLM attempts to resolve a query against hundreds of pages of contradictory meeting transcripts or evolving code versions, it frequently blends incompatible implementation details from different eras of the project.

### The Compounding Latency and Cost of Multi-Turn Context Resending

The second failure point is inference latency. Time to first token (TTFT) measures how long an application waits between submitting a request and receiving the first word of the response. Processing a one-million-token prompt requires reading tens of gigabytes of key-value cache data from GPU high-bandwidth memory. A query that would return in hundreds of milliseconds on a concise prompt can require twenty to forty-five seconds of prefill computation on a multi-hundred-thousand-token prompt.

The third failure point is financial cost. In a multi-turn conversational session, LLM APIs are stateless. Every subsequent turn resends the entire conversation history, including all previously attached documents.

Consider a software development team that uploads multiple dense technical manuals into an active session. When the user asks repeated follow-up questions, the application reprocesses the entire conversation history on every turn, multiplying token usage and API charges across the session. Even with context caching discounts, repeated prefill cycles inflate cloud bills and consume rate-limit quotas rapidly.

## How to Decouple Storage from Context with Fast.io and Remote MCP

The architectural solution to context exhaustion is decoupling storage from context. Instead of treating the LLM context window as an ephemeral filing cabinet, engineering teams use [shared workspaces](/product/workspaces/) to store the master organizational corpus permanently.

Fast.io provides organization-owned [intelligent agent workspaces](/storage-for-agents/) where human teams and AI assistants collaborate across the same files and knowledge base. Rather than uploading dozens of individual PDFs into every chat thread, teams maintain a single, persistent workspace that indexes documentation automatically on arrival.

Workspaces support multiple ingestion pathways without local disk I/O. Teams can upload files directly or configure Cloud Sync to connect Google Drive, Dropbox, Box, and OneDrive on a schedule or on demand. URL import allows pulling remote documentation directly into workspace storage.

Once files enter a Fast.io workspace, Intelligence Mode automatically indexes the text for hybrid search, combining exact keyword matching, semantic vector retrieval, and search-by-metadata-value. When an AI assistant needs information to answer a prompt, it does not ingest the entire hundred-page document. Instead, it queries the workspace through the Model Context Protocol (MCP) and retrieves only the specific three-hundred-token passage relevant to the question.

### Automated Hybrid Indexing and Metadata Views for Long Documents

Fast.io differentiates pure textual search from structured document understanding through [Metadata Views](/product/document-data-extraction/). Metadata Views turn unstructured documents into live, queryable databases without requiring manual optical character recognition (OCR) rules or rigid extraction templates.

Users describe the fields they need in plain English, such as contract effective dates, governing laws, liability caps, or invoice totals. AI analyzes the files in the workspace and populates a typed spreadsheet supporting Text, Integer, Decimal, Boolean, URL, JSON, and Date and Time data types. New columns can be added at any time without reprocessing files.

This structured extraction layer allows AI assistants to filter documents by metadata value before performing text retrieval. An agent evaluating vendor agreements can filter the workspace for contracts active in 2026 before querying specific indemnification clauses, drastically reducing the search space and saving valuable prompt tokens.

### Configuring Fast.io Remote MCP for Dynamic Document Retrieval

Fast.io exposes a consolidated MCP toolset over Streamable HTTP at `https://mcp.fast.io/mcp/tools`. Because Fast.io operates as a remote MCP server, teams connect AI clients directly without configuring local Node.js processes, Python wrapper environments, or background bridging daemons.

Interactive clients such as Claude Desktop, Claude web, and general MCP clients connect using OAuth sign-in, while automated agent scripts and developer runtimes send a scoped API key as a Bearer token in the Authorization header. For setup steps and connection workflows, visit the official guide at https://mcp.fast.io/docs.

Developers configuring custom agents or desktop MCP clients can declare the Fast.io connection in their client configuration:

```json
{
  "mcpServers": {
    "fast-io": {
      "url": "https://mcp.fast.io/mcp/tools"
    }
  }
}
```

When an agent needs to retrieve information from a workspace, it calls the storage tool over Streamable HTTP:

```bash
curl -X POST https://mcp.fast.io/mcp/tools \
  -H "Authorization: Bearer your-fastio-api-key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "storage",
      "arguments": {
        "action": "search",
        "query": "Moonshot Kimi context window limits and file upload parsing"
      }
    }
  }'
```

Every document stored in Fast.io retains a complete per-file version history, allowing teams to audit modifications and restore previous iterations. Workspace activity is recorded in a detailed activity log that captures actions performed by people and AI agents. Collaborative Notes allow team members and assistants to draft specifications jointly, while ownership transfer enables an agent to generate an entire project workspace and transfer administrative control to a human team lead.

Fast.io operates on a transparent subscription model. Creating an account is free; doing real work requires an organization on a paid subscription. Monthly plans start with a 14-day free trial that requires a credit card. Teams can choose from three subscription tiers:

| Plan | Monthly Pricing | Annual Pricing | Included Seats | Included Storage | Workspaces Included | Monthly AI Credits | Upload Limit |
|---|---|---|---|---|---|---|---|
| Starter | $9.99/mo | $99 a year | 3 seats | 250 GB | 5 workspaces | 100,000 credits | 25 GB |
| Business | $49.99/mo | $499 a year | 10 seats | 5 TB | 50 workspaces | 600,000 credits | 50 GB |
| Enterprise | $199.99/mo | $1,999 a year | 30 seats | 25 TB | 200 workspaces | 3,000,000 credits | 100 GB |

Review complete plan details on the [Fast.io pricing](/pricing/) page.

## Frequently asked questions

### How big is the Kimi AI context window?

Kimi Chat supports an input capacity of up to two million Chinese characters or roughly one and a half million English words. In Moonshot AI's API platform, the flagship kimi-k3 model provides a one-million-token context window, while specialized models like kimi-k2.7-code and kimi-k2.6 support two hundred fifty-six thousand tokens.

### Can Kimi analyze entire books or code repositories?

Yes. With a multi-hundred-thousand token capacity, Kimi can ingest multiple complete books, extensive legal case files, or large code repositories in a single session. However, processing massive single prompts increases response latency and can lead to attention dilution across the middle of the document.

### What are the file upload limits in Kimi?

In the Kimi API Platform, individual file uploads support up to 100 MiB per file with an organization storage quota of 10 GiB. In the Kimi Chat web interface, users can upload dozens of documents per conversational session, covering PDF, Word, Excel, PowerPoint, and source code files.

### How does Kimi's context window compare to Claude and Gemini?

Kimi Chat and kimi-k3 sit between Claude Sonnet's two-hundred-thousand-token window and Gemini Pro's multi-million-token window. While Claude emphasizes deep reasoning within focused project boundaries, Kimi focuses on high-speed bilingual text parsing and cost-effective context caching.

### What causes context rot in ultra-long LLM sessions?

Context rot happens when an LLM is overloaded with hundreds of thousands of tokens of unstructured text. As sequence length increases, the model's attention mechanism experiences dilution across the middle of the prompt, resulting in overlooked instructions, lower retrieval accuracy, and potential hallucinations.

### How do remote MCP workspaces save tokens compared to full-file ingestion?

Instead of uploading entire multi-megabyte documents into every prompt, remote MCP workspaces like Fast.io pre-index documents with hybrid full-text and semantic search. When an assistant needs information, it queries the workspace via MCP tools and retrieves only the relevant passage, keeping active context clean and reducing API costs.

### What file formats can be uploaded to Kimi for document extraction?

Kimi supports PDF, DOC, DOCX, XLS, XLSX, PPT, PPTX, EPUB, TXT, CSV, JSON, Markdown, HTML, and popular source code formats including Python, TypeScript, JavaScript, Go, C++, and Java. Image files require upload through dedicated vision endpoints.

## Sources

- [Kimi API Platform: Upload File](https://platform.kimi.ai/docs/api/files-upload): In the Kimi API Platform, individual file uploads support up to 100 MiB per file with an organization storage quota of 10 GiB.
- [Anthropic Help Center: Upload files to Claude](https://support.claude.com/en/articles/8241126-upload-files-to-claude): In standard Claude chat uploads, users can attach up to 20 files at up to 500MB each, while project file count is unlimited within the context window.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.