Что такое TL и зачем он нужен LLM
TL расшифровывается как token-efficient language, то есть язык, оптимизированный под расход токенов. Его целевой исполнитель - большая языковая модель: она читает и пишет код в сжатом виде, а человек работает с привычным кодом, который получается обратной конвертацией. Автор формулирует принцип коротко: убрать или сократить максимум ненужного синтаксиса, сохранив структуру, которой достаточно для надёжного понимания и генерации кода.
Это специализированный язык под LLM, а не очередной диалект для людей. TL поддерживает только NodeJS, лежит в открытом репозитории krdanny/tl-lang и пока не имеет независимых проверок.
Почему синтаксис языков программирования - это налог на токены
Автор перечисляет элементы, которые стоят токенов, но нужны в первую очередь человеку: фигурные скобки, закрывающие кавычки, лишние пробелы, переводы строк и длинные имена переменных. Именно они делают код читаемым для разработчика: блок видно по отступу, строку - по кавычкам, назначение переменной - по её имени.
Для модели задача другая. Она предсказывает следующий токен по контексту, и служебные символы в этой задаче почти не несут информации: закрывающая скобка в конце блока предсказуема, а место в бюджете контекста занимает такое же, как значащий идентификатор. Чем больше в файле служебного синтаксиса, тем больше запросов уходит на его передачу и тем быстрее расходуется окно контекста.
Отсюда метафора налога: каждый вызов ассистента платит за читаемость, которая модели не нужна. TL - попытка этот налог снизить.
Как родилась идея TL: от лимитов Claude Code до нового языка
Отправной точкой стали лимиты подписки. Автор проекта пишет в посте на r/LocalLLaMA: «Last week, I ran out of tokens on my Claude Code subscription. Again.» Проблема не гипотетическая: активная работа с кодом через Claude Code упирается в квоту, и дальше либо ждать сброса, либо искать способ тратить меньше.
Логика рассуждения простая. Если ограничение упирается в токены, а часть токенов уходит на синтаксис, нужный человеку, значит, можно сократить именно эту часть. Так появился TL: «I created TL - a token-efficient language designed for LLMs». История создания объясняет и характер проекта: это ответ на практическую боль, а не академическое исследование.
Как TL экономит токены: принцип работы и заявленные 30-60%
Экономия строится не на сжатии готового файла, а на другом представлении кода, с которым работает модель. Ниже - что именно меняется и насколько надёжна цифра в 30-60%.
Что именно убирает или сокращает TL
Из формулировки автора следует набор решений: отказ от закрывающих скобок и кавычек там, где структура однозначна; сокращение пробелов и переводов строк; работа с длинными именами, которые в обычном коде тоже расходуют бюджет. Насколько агрессивно сокращаются имена, из описания не следует: автор называет их среди статей расхода, но конкретных правил не приводит.
Планка, которую TL не переходит: структура должна оставаться достаточной для надёжного понимания и генерации. Это важное отличие от простой минификации. Минификатор сохраняет грамматику языка и убирает в основном пробелы, переводы строк и комментарии: код остаётся валидным JavaScript, просто нечитаемым. TL меняет сам синтаксис под модель, поэтому сравнивать его с минификатором корректно по цели экономии, а не по механике.
Есть и третья линия, к которой TL может двигаться: промежуточные представления вроде AST, где код уже разобран на структуру. AST несёт много служебной информации о дереве и для чтения человеком не предназначен; TL ищет баланс между компактностью и однозначностью для модели.
Насколько можно верить цифрам 30-60%
Цифра взята из бенчмарка самого автора, который прогнал TL на нескольких open-source проектах. Он заявляет «roughly 30 to 60% fewer tokens, depending on the codebase». Независимого подтверждения нет: других замеров, рецензий или воспроизведённых результатов по TL на момент публикации не описано.
Разброс в два раза объясним. Экономия зависит от кодовой базы: от стиля форматирования, плотности служебного синтаксиса, длины имён и доли кода, который вообще попадает в контекст. Проект с длинными осмысленными именами и щедрыми отступами сожмётся сильнее, чем плотный код с короткими идентификаторами. Поэтому 30-60% корректно читать как диапазон оценки, а не как гарантированный коэффициент.
Проверить идею на своём проекте предлагает сам автор: в том же посте он просит фидбэк и проверку на практике. Это единственный способ получить цифры для вашей кодовой базы, пока нет независимых замеров с воспроизводимой методикой.
Как использовать TL: VS Code, NodeJS и рабочий процесс
Рабочий процесс строится на разделении ролей: LLM работает с компактным представлением, разработчик - с обычным кодом. Между ними стоит конвертация.
Расширение для VS Code: как читать и править сжатый код
Автор сделал расширение для VS Code, которое превращает TL в обычный человекочитаемый код для ревью и редактирования. Смысл в том, что разработчику не нужно разбирать сжатый текст: он смотрит привычные конструкции, правит их и отдаёт обратно. Без такого слоя подход был бы неудобен для сопровождения, поэтому расширение здесь не украшение, а условие работоспособности всей схемы.
Ограничение: пока только NodeJS
TL сейчас работает только с NodeJS. Пишете на Python, Go, Rust или Java - инструмент в текущем виде вам не подойдёт: поддержки этих языков нет. Это ключевое ограничение для оценки применимости.
Отсюда практический вывод по стеку: сначала проверьте, что основная масса генерации кода у вас идёт на NodeJS. Только потом имеет смысл тратить время на освоение нового представления кода.
Ограничения и риски TL: что важно знать перед использованием
Что пока не реализовано: другие языки и промежуточное представление
Планы автор заявляет прямо: расширить TL на другие языки и потенциально превратить его в собственное независимое от языка промежуточное представление. Обе вещи - планы, а не текущие возможности. В активе на сегодня только NodeJS.
Почему независимая проверка пока отсутствует
Проект открыт на GitHub и живёт в формате авторского поста с просьбой проверить идею. Независимых бенчмарков, отзывов и разборов от третьих лиц в материалах о TL нет. Для ранней стадии это нормально, но накладывает ограничения на выводы: цифру 30-60% стоит держать как заявление автора, пока её не воспроизвели на другой кодовой базе.
Отдельно про риски, которые стоит держать в голове. Любая конвертация между двумя представлениями - место, где возможны потери и ошибки. Отладка кода, прошедшего через промежуточный формат, усложняется: стек-трейс и логи вы видите уже после обратной конвертации. Рабочий процесс завязан на расширение VS Code, то есть на инструмент раннего проекта. Эти риски не означают, что подход плох, но проверять его разумно на отдельной ветке и на некритичных задачах.
Кому и зачем может пригодиться TL
Сценарии, где экономия токенов критична
Целевой пользователь TL - разработчик на NodeJS, который активно гоняет код через LLM-ассистенты и упирается в лимиты. Выгода заметна в больших репозиториях, где в контекст попадают целые модули; при частой генерации и переписывании кода в течение дня; в командных подписках, где квота делится между людьми.
Экономия токенов влияет и на деньги. Если вы платите за инференс или упираетесь в лимит подписки, снижение расхода на 30-60% по заявлению автора означает либо больше работы в рамках той же квоты, либо меньший счёт. Альтернативный путь решить ту же задачу - сменить модель: например, GLM 5.2 даёт цену инференса примерно в 30 раз ниже Opus 4.8. TL и выбор модели друг друга не исключают.
Ещё один сценарий - команды, которые уже строят пайплайны вокруг Claude Code. Пример архитектуры с CLI-сессиями, git worktree и веб-дашбордом разобран в материале про пет-проект на Java с Claude Code. В таких пайплайнах расход токенов становится метрикой, которую видно на дашборде и можно целенаправленно снижать.
Когда TL не нужен
Если вы не используете LLM для генерации кода, оптимизировать нечего. Если ваш стек - Python, Go или Rust, текущая версия не подойдёт. Если лимиты токенов не проблема, выгода от сжатия останется теоретической, а расходы на освоение нового представления кода - вполне реальными. В этих случаях разумнее следить за развитием проекта, чем внедрять его сейчас.
Планы развития и как поддержать проект
Заявленное направление: поддержка других языков программирования и превращение TL в независимое от языка промежуточное представление. Второй пункт интереснее первого: если TL станет общим IR, его можно будет подключать к разным стекам, а не только к NodeJS. Сроков автор не называет и обязательств не даёт.
Повлиять на развитие можно по-разному: прогнать TL на своём проекте и сравнить расход токенов с обычным кодом, оставить issue с ошибкой конвертации, предложить правила для нового языка. Автор прямо просит фидбэк и проверку идеи на практике (пост на r/LocalLLaMA). Для проекта на ранней стадии обратная связь от практиков ценнее любых обещаний.
Итог: стоит ли пробовать TL
TL - эксперимент по снижению расхода токенов при генерации кода. Идея понятная: платить модели за смысл, а не за скобки и отступы. Заявленные 30-60% экономии на open-source проектах выглядят достаточно интересно, чтобы проверить инструмент на своих задачах, но это цифра из бенчмарка автора, независимых подтверждений нет.
Практический фильтр простой. Пишете на NodeJS, регулярно работаете с LLM-ассистентами и упираетесь в квоты - заходите в репозиторий krdanny/tl-lang, ставьте расширение для VS Code и замеряйте расход на своей кодовой базе. Не подходите под эти условия - держите проект в поле зрения: планы на другие языки и промежуточное представление могут изменить картину.