Каждая страница PDF в Claude Code = 1500-3000 токенов. Фикс

Грузил 50-страничный отчёт в Claude Code, чтобы быстро вытащить пару цифр. Через 4 минуты кругляш контекста загорелся жёлтым, через 8 - оранжевым, на 12-й я получил «достигнут лимит на 5 часов» и пошёл пить чай. Один файл выжег весь лимит подписки. Когда я полез в документацию Anthropic, оказалось что они это даже не прячут: одна страница PDF съедает 1500-3000 токенов ещё до моего первого вопроса. Не сама модель тупит и не лимит низкий - это PDF так работает в Claude.

В этой статье разберу почему страница PDF в Claude Code стоит в 7 раз дороже того же текста в Markdown, покажу математику на 15-страничном отчёте (135 000 токенов против 18 000), дам три рабочих способа конверсии и готовый bash-скрипт для папки документов.

Я не нашёл этой цифры в туториалах для новичков, поэтому большинство грузит PDF в Claude вслепую. Anthropic пишет её прямо в основной документации по PDF support, шапка раздела:

«Each page typically uses 1,500-3,000 tokens depending on content density. Since each page is converted to an image, the same pricing applies as for standard images.» - Anthropic, PDF support docs

В переводе: «Каждая страница обычно использует 1500-3000 токенов в зависимости от плотности контента. Поскольку каждая страница конвертируется в изображение, применяется та же стоимость, что и для обычных картинок.»

Дальше там же объяснение почему так дорого, в моём переводе с тех же доков Anthropic:

«Система конвертирует каждую страницу документа в изображение. Текст с каждой страницы извлекается и предоставляется вместе с изображением страницы. Claude анализирует и текст, и картинку, чтобы лучше понять документ.» - Anthropic, PDF support docs (перевод)

То есть Claude не доверяет своему OCR и берёт текст + картинку одновременно. Платишь за оба слоя сразу. Это видно на бенчмарке AWS Bedrock: один 3-страничный PDF в текстовом режиме - 1000 токенов, тот же файл с визуальным анализом - 7000 токенов. Включение картинок делает обработку в 7 раз дороже.

Скриншоты страниц - ещё хуже. Скриншот 1000×1000 пикселей стоит около 1300 токенов. Тот же кусок текста, скопированный руками, занимает 50-100 токенов. Разница в 13-26 раз. Знакомая ситуация: показал Claude кусок таблицы скриншотом всего экрана и через 5 запросов упёрся в потолок.

Если хочешь увидеть, сколько токенов реально потратил - запусти Claude Code с флагом отладки, он покажет input/output usage прямо в логах:

claude --debug "проанализируй этот PDF" report.pdf

В выводе ищи строки input_tokens и cache_read_tokens. Если рядом загруженный PDF, и видишь input_tokens в районе 20-30К на одну страницу - значит платишь за визуальный слой по полной.

Давай посчитаем на реальном сценарии. 15-страничный публичный отчёт, нужно прогнать через Claude в четырёх контекстах: разбор тезисов, цитаты по теме, перевод на английский, краткое summary.

Если каждый раз грузить PDF заново:

15 страниц × 2250 токенов × 4 чата = 135 000 токенов
При цене $3 за миллион токенов на Sonnet 4.x = $0.40 только на input

Если один раз сконвертить PDF в Markdown:

15 страниц × 300 токенов × 4 чата = 18 000 токенов
Стоимость = $0.054
Экономия 87% и $0.35 за один цикл

И это без учёта prompt caching. С кешем (TTL 5 минут по умолчанию, до 1 часа на расширенном тарифе) повторные вызовы внутри окна стоят 10% от обычной цены. Считай: один PDF в один и тот же чат 4 раза = первый вызов 2250 токенов на страницу, остальные три - по 225. На том же 15-стр отчёте выйдет около 50 600 токенов вместо 135 000. Уже минус 63% без всякой конверсии. С Markdown тот же приём даёт 6 500 токенов на 4 чата (95% экономии относительно сырого PDF).

Один источник по теме формулирует это резче:

«Если ты грузишь один и тот же 15-страничный PDF в 4 разных чата, ты только что сжёг 180 000 токенов на документе, который можно было сконвертировать в 2000 токенов чистого текста.» - codeitbro.com, гайд по лимитам Claude usage

Для подписки Claude Pro эта математика становится жёстче. Один 100-страничный отчёт может выжечь лимит на 5 часов. После конверсии в Markdown в тот же бюджет влезает десяток таких документов.

PDF - это формат для печати, не для ИИ. Когда я это понял, поведение поменялось целиком: любой документ перед заходом в Claude Code сначала прогоняется через конвертер, и только сжатый .md тащится в проект. Кругляш контекстного окна перестал загораться жёлтым.

Кстати, PDF - не единственное место, где Claude Code незаметно жжёт лимиты. Дисциплина «куда уходят токены» закрывает остальные восемь паттернов утечки контекста: длинная история чата, неоптимизированный системный промпт, тяжёлый CLAUDE.md, неиспользуемые MCP-серверы и ещё пять штук. Если эта тема тоже бьёт по лимиту - у меня собрана разбивка по 9 паттернов утечки токенов в Claude Code с цифрами и фиксами под каждый.

Я перепробовал шесть конвертеров за последние три месяца. Три выжили в ежедневном использовании. Покажу каждый с конкретными командами.

Это утилита от Microsoft AutoGen team, написана на Python. На GitHub 134 тысячи звёзд, лицензия MIT. Поддерживает PDF, DOCX, PPTX, XLSX, HTML, JSON, аудио с транскрипцией, изображения с OCR и даже YouTube-видео через captions.

Установка одной командой (нужен Python 3.10+):

pip install 'markitdown[all]'

Если не нужны все форматы и хочется лёгкую версию:

pip install 'markitdown[pdf, docx, pptx]'

Конверсия одного файла - тоже одна команда:

markitdown report.pdf > report.md

Дальше тащишь report.md в Claude Code через @report.md или просто кладёшь рядом с проектом и пишешь «вот документ, растащи по своим файлам». Claude разложит на структуру и дальше работает уже с разложенным текстом.

Если хочешь встроить в свой Python-скрипт:

from markitdown import MarkItDown md = MarkItDown() result = md.convert("research-paper.pdf") print(result.text_content) with open("research-paper.md", "w") as f: f.write(result.text_content)

Чего MarkItDown не умеет: OCR для сканов (на выходе пустой .md), сложный многоколоночный layout (может сломать порядок чтения), сохранение embedded URLs из PDF. Для обычных отчётов и статей - оптимальный выбор. Для сканов и научных PDF - смотрим дальше.

Проект Artifex Software на основе native C-движка MuPDF. Самый быстрый из PDF-конвертеров, GPU не нужен. Smart OCR применяется только к нечитаемым областям и снижает время обработки примерно вдвое. Единственный из популярных инструментов, который сохраняет embedded URLs и изображения из PDF в отдельной папке.

Установка:

pip install pymupdf4llm

Использование:

import pymupdf4llm md_text = pymupdf4llm.to_markdown("document.pdf") with open("document.md", "w") as f: f.write(md_text)

Или одной строкой из терминала:

python3 -c "import pymupdf4llm; \ open('document.md','w').write(pymupdf4llm.to_markdown('document.pdf'))"

Когда брать PyMuPDF4LLM, а не MarkItDown:

В PDF много гиперссылок, нужно их сохранить (MarkItDown их теряет)
Документ сканированный, нужен OCR
Нужна скорость на тысячах файлов локально - native C-движок быстрее Python-обёрток
Нужны картинки из PDF в отдельной папке для дальнейшей обработки

И теперь ловушка, на которой я залип с продуктовой работой - двойная лицензия. PyMuPDF4LLM распространяется под AGPL v3 ИЛИ коммерческой лицензией Artifex. AGPL означает: если ты используешь библиотеку в публичном SaaS-сервисе, ты обязан публиковать весь исходный код своего сервиса под той же AGPL. Для внутреннего скрипта на своём ноутбуке - никаких ограничений. Для коммерческого сервиса без раскрытия кода - надо покупать лицензию у Artifex, цены публично не указаны, запрашиваются у sales.

Если делаешь продукт для клиентов - проверь лицензию в первую очередь. MarkItDown (MIT) и Docling (MIT) для SaaS-сценариев безопаснее.

Если MarkItDown в режиме CLI - это «конвертирую руками заранее», то MCP-сервер - это «Claude Code сам решает, когда вызвать конвертер». Idle-стоимость около 110 токенов на описание скилла, ноль когда не нужен.

Установка:

pip install markitdown-mcp

Конфиг в .mcp.json (в корне проекта):

{ "mcpServers": { "markitdown": { "command": "docker", "args": ["run", "--rm", "-i", "markitdown-mcp:latest"] } } }

Чтобы Docker-контейнер видел локальные файлы - монтируй папку:

{ "mcpServers": { "markitdown": { "command": "docker", "args": [ "run", "--rm", "-i", "-v", "/Users/you/Documents:/workdir", "markitdown-mcp:latest" ] } } }

Перезапускаешь Claude Code, в списке MCP-серверов появляется markitdown. Дальше в чате:

Сконвертируй /workdir/report.pdf в Markdown и проанализируй основные тезисы.

Claude сам вызывает convert_to_markdown(uri), получает Markdown и работает с ним - PDF в контекст вообще не загружается. Поддерживаются file://, http://, https:// и data: (Base64 inline). По умолчанию сервер биндится на localhost, без авторизации - не открывай порт наружу без reverse-proxy.

Хорошая community-альтернатива - форк trsdn/markitdown-mcp с тремя инструментами: convert_file, list_supported_formats, convert_directory для batch-обработки целых папок (mcp.directory есть гайд по этому скиллу).

Самый рабочий приём, который я подсадил на трёх своих проектах: один раз настраиваешь скрипт, и любая новая папка с документами автоматически становится «Claude-readable» за один прогон.

Представь: у тебя 40 PDF и PPTX отчётов от клиентов в одной папке - брокерские выписки, договоры, презентации. В лоб грузить эту папку в Claude бесполезно - контекстное окно забьётся ещё до первого ответа. Прогоняешь всю папку через скрипт за один проход и работаешь дальше с лёгкими .md вместо тяжёлых PDF.

Сохрани как scripts/docs-to-md.sh в корне проекта:

#!/bin/bash # docs-to-md.sh - конвертит все документы в папке в Markdown через MarkItDown # Запуск: bash docs-to-md.sh ./documents set -e INPUT_DIR="${1:-./documents}" OUTPUT_DIR="${INPUT_DIR}/_md" mkdir -p "$OUTPUT_DIR" echo "Сканирую $INPUT_DIR..." for file in "$INPUT_DIR"/*.{pdf,docx,pptx,xlsx}; do [ -f "$file" ] || continue basename=$(basename "$file") name="${basename%.*}" output="$OUTPUT_DIR/${name}.md" if [ -f "$output" ] && [ "$output" -nt "$file" ]; then echo "Пропускаю $basename (уже сконвертирован)" continue fi echo "Конвертирую $basename..." markitdown "$file" > "$output" done echo "Готово. Результаты в $OUTPUT_DIR"

Делаешь исполняемым:

chmod +x scripts/docs-to-md.sh

Запускаешь:

bash scripts/docs-to-md.sh ./reports

После прогона в ./reports/_md/ лежат .md версии всех документов. В Claude Code тащишь через @reports/_md/ - работаешь с уже сжатыми текстами.

Скрипт автоматически пропускает уже сконвертированные файлы по mtime - повторный запуск дешёвый, не пересчитывает всё. Если хочешь ловить даже изменённые PDF (которые пересохранили с тем же именем) - замени mtime-проверку на content-hash:

hash=$(shasum -a 256 "$file" | cut -d' ' -f1) hash_file="$OUTPUT_DIR/.${name}.sha256" if [ -f "$hash_file" ] && [ "$(cat "$hash_file")" = "$hash" ]; then echo "Пропускаю $basename (хэш совпадает)" continue fi markitdown "$file" > "$output" echo "$hash" > "$hash_file"

Эта версия пересчитает файл только если его содержимое изменилось. На папке из 200 документов работает за минуту против 30 минут без проверки.

Я их видел у себя в первый месяц и у пары людей, кому помогал настраивать Claude Code. Каждая ошибка стоит десятков тысяч токенов на ровном месте.

Ошибка 1. Грузить один PDF в новый чат каждый раз. Claude Pro даёт лимит сообщений на 5 часов - один 50-страничный отчёт может выжечь весь лимит ещё до второго вопроса. У меня для этого простой принцип: одна задача - один чат. Когда ИИ начинает жрать немыслимое количество токенов, это говорит о том, что ты всё пихаешь в один чат и тащишь туда PDF снова и снова. Я в каждом окне держу одну микрозадачу. Документ конвертирую в Markdown один раз и потом тащу .md в каждое новое окно как файл рядом с проектом.

Ошибка 2. Скриншот вместо текста. Видел кучу раз: человек хочет показать Claude кусок кода или таблицу, делает скриншот всего экрана 1920×1080 и удивляется, что лимит кончился за 5 запросов. Скриншот 1000×1000 пикселей стоит около 1300 токенов. Тот же кусок, скопированный руками - 50-100 токенов. Разница в 13-26 раз. Решение: скриншоты обрезать туго (только важная часть), а лучше копировать текст напрямую.

Ошибка 3. Сканированный PDF без OCR. MarkItDown не умеет OCR. Если конвертируешь скан, на выходе пустой .md (или три строчки с шумом). Для сканов нужен PyMuPDF4LLM со встроенным smart OCR или Docling. Если получил пустой файл и забыл проверить - Claude молча ответит «в документе нет данных» и ты потратишь час на разборки.

Ошибка 4. Игнорировать лимит 100 страниц для моделей с 200K контекстом. Документация Anthropic даёт лимит 600 страниц на запрос, но по факту для Sonnet 4.x и Opus 4.x лимит ниже - 100 страниц. На 600 рассчитаны старые модели или специальные тарифы. Если грузишь 150-страничный отчёт в Sonnet 4.6, получишь ошибку или - хуже - Claude обработает только первые 100 страниц и сделает вид, что прочитал весь документ. Решение: разбивай длинные PDF на части перед загрузкой или конвертируй в Markdown (там лимита страниц нет, только токены).

Ошибка 5. Не использовать prompt caching на повторных запросах. Если работаешь с одним и тем же документом через API - оборачивай его в cache_control: ephemeral. Повторные вызовы в течение TTL стоят 10% от первоначальной цены. Первый запрос дороже, остальные - со скидкой 90%. Для всего, что грузишь больше одного раза, prompt caching включён по умолчанию через Claude Code, но через прямой API его надо настраивать руками.

Конверсия выигрывает почти всегда, но не везде. Три кейса, где Markdown проигрывает PDF.

Визуальный анализ диаграмм и графиков. Если Claude должен «прочитать» график - кривую цен, схему процесса, диаграмму архитектуры - в Markdown этой информации нет. Markdown сохраняет только подписи к рисункам, сам рисунок теряется. Решение: грузишь PDF, явно включаешь visual режим. На Claude API флаг автоматически работает, на AWS Bedrock нужен citations flag.

Сложные таблицы с merged cells. Markdown-таблицы плоские. Если в PDF таблица со слитыми ячейками, многоуровневыми заголовками или вложенными подтаблицами - конвертер либо сплющит её, либо потеряет связи. Решение: либо PDF напрямую, либо Docling (он лучше всех держит сложные таблицы), либо ручная разметка после конверсии.

Документ как артефакт с привязкой к страницам. Юридический договор, протокол, акт - тут важно цитировать с указанием «страница 7, абзац 3». В Markdown номера страниц теряются. Решение: PDF + Files API + prompt caching. Один раз загрузил, потом обращаешься по file_id, Claude видит pagination и ссылается на конкретные страницы.

Граница окупаемости конверсии - примерно 5+ страниц или 2+ использования одного документа. Меньше - грузи PDF напрямую, больше - конвертируй.

Если у тебя в проекте больше пяти PDF - поставь MarkItDown сегодня (5 минут, MIT, не палит при использовании в SaaS). Дальше любой документ проходит через markitdown file.pdf > file.md перед Claude Code.
Скрипт docs-to-md.sh сохрани в scripts/ любого проекта, где работаешь с клиентскими документами - это разовый сетап на 10 минут, который убирает 87% расходов на токены.
Для сканов и научных PDF держи отдельно PyMuPDF4LLM, но если ты собираешь публичный SaaS - проверь AGPL до того, как покупать лицензию у Artifex.
MCP-сервер ставь, когда документы лежат локально и не хочется заранее думать о конверсии. Для разовых задач CLI быстрее, для систематической работы - MCP комфортнее.
Скриншоты экрана для Claude забудь как класс. Селективный текст или вырезанный фрагмент - в 20 раз дешевле.

Конверсия PDF - один из приёмов экономии токенов. Сам по себе он не делает Claude точнее в ответе. Точность даёт дисциплина того, что ты кладёшь в контекст модели до момента, когда задаёшь вопрос. Это и есть канон контекст-инжиниринга в 2026 - подход, который Karpathy и Anthropic разнесли по постам почти одновременно весной этого года.

В 2026 году цена за миллион токенов падает примерно на 30-40% в год, а размер документов, которые мы грузим в ИИ, растёт быстрее. Через 18-24 месяца лимиты будут раздавать щедрее, но сжатие контекста до сути всё равно останется тем самым кирпичом, который отделяет работу с Claude как с надёжным напарником от работы как с цифровым попугаем.

А у тебя как: гонишь PDF в Claude сырьём или уже конвертишь? Если конвертишь - чем именно и какой инструмент оказался лучше для твоих документов?

Каждая страница PDF в Claude Code = 1500-3000 токенов. Фикс

Где Anthropic прямо признал: 1 страница = до 3000 токенов

PDF против Markdown: 135 000 токенов против 18 000 на одном отчёте

Три рабочих способа: MarkItDown, PyMuPDF4LLM, MCP-сервер

MarkItDown - универсал на каждый день

PyMuPDF4LLM - быстрый и с OCR, но AGPL

MarkItDown MCP-сервер - Claude сам решает, когда конвертить

Готовый bash-скрипт для папки документов

Пять ошибок, которые жгут токены каждый день

Когда PDF в Claude всё-таки лучше Markdown

Что я бы сделал на твоём месте