用途：面向需要在单次请求中处理超大代码库、书籍、日志或文档集，并做跨文档推理的场景，说明如何启用并善用 Claude 的 1M token 上下文窗口。
主要能力与启用方式：Claude Opus 4.6 与 Sonnet 4.6 支持 1M token 上下文，需带 beta 头 context-1m-2025-08-07；不带该头时超过 200K token 的请求会报错。示例： const response = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 4096, messages: [{ role: "user", content: giantDocument + "\n\nSummarize." }] }, { headers: { "anthropic-beta": "context-1m-2025-08-07" } });
定价与取舍：超过 200K 输入 token 按长上下文定价，资料称约为基础费率的 2 倍，输出价格不变，具体费率需查当前供应商。若只用 200K 就不必启用 1M。1M 上下文适合跨文档综合、全代码库重构、整体代码审查、单次分析、探索性任务；RAG 适合每小时更新的数据、超过 1M 的无界语料、需隐私隔离的个人数据、大量廉价小查询、已知查询模式。混合做法：用 RAG 取回前 500K token 再放入 1M 上下文。
组织长输入以提升召回：指令放在末尾；用 XML 标签做分节（如 <document index="1" title="...">）；关键指令在开头和结尾各重复一次；避免无差别的文本块，用分隔符切分。
结合提示缓存：对同一语料多次提问时，把静态部分放入 system 并设 cache_control: { type: "ephemeral", ttl: "1h" }，首次全价，TTL 内后续调用缓存部分约为输入成本的 10%。
延迟与计数：1M 输入处理较慢，TTFT 可能 10–30 秒，建议流式输出；可用 client.messages.countTokens 预估 input_tokens，超过 1_000_000 时报错，并留 5% 安全余量。
反模式：小请求也常开 1M、无结构地倾倒文本、指令只放开头、重复查询不做缓存。
限制：资料未提供具体价格数值、各平台支持差异及完整参数说明，需以官方当前文档为准。