Наблюдаемость с OpenTelemetry

Узнайте, как включить и настроить OpenTelemetry для Qwen Code.

• Наблюдаемость с OpenTelemetry
  • Ключевые преимущества
  • Интеграция с OpenTelemetry
  • Конфигурация
  • Телеметрия Aliyun
    • Ручной экспорт OTLP
  • Локальная телеметрия
    • Вывод в файл (рекомендуется)
    • Экспорт через коллектор (продвинутый)
  • Логи и метрики
    • Логи
    • Метрики

Ключевые преимущества

• 🔍 Аналитика использования: Понимайте паттерны взаимодействия и внедрение функций в вашей команде
• ⚡ Мониторинг производительности: Отслеживайте время ответа, потребление токенов и использование ресурсов
• 🐛 Отладка в реальном времени: Выявляйте узкие места, сбои и паттерны ошибок по мере их возникновения
• 📊 Оптимизация рабочих процессов: Принимайте обоснованные решения для улучшения конфигураций и процессов
• 🏢 Корпоративное управление: Мониторинг использования в командах, отслеживание затрат, обеспечение соответствия требованиям и интеграция с существующей наблюдаемой инфраструктурой

Интеграция с OpenTelemetry

Система наблюдаемости Qwen Code построена на OpenTelemetry  — отраслевом стандарте наблюдаемости, не зависящем от вендора — и предоставляет:

• Универсальная совместимость: Экспорт в любой бэкенд OpenTelemetry (Aliyun, Jaeger, Prometheus, Datadog и др.)
• Стандартизированные данные: Используйте единые форматы и методы сбора во всём инструментарии
• Интеграция, защищённая от будущего: Подключение к существующей и будущей наблюдаемой инфраструктуре
• Отсутствие привязки к вендору: Переключайтесь между бэкендами без изменения инструментации

Конфигурация

Всё поведение телеметрии управляется через файл .qwen/settings.json. Эти настройки могут быть переопределены переменными окружения или флагами CLI.

Чувствительные атрибуты спанов: Когда includeSensitiveSpanAttributes включён, происходит две вещи:

1. Нативные атрибуты спанов (qwen-code.interaction, api.generateContent*, tool.<name>) несут дословное содержимое разговора:

   • Пользовательские промпты (new_context)
   • Системные промпты (system_prompt — полный текст один раз за сессию, дедуплицируется по хешу SHA-256; последующие спаны содержат только system_prompt_hash + system_prompt_preview + system_prompt_length)
   • Схемы инструментов (передаются как события tool_schema, также дедуплицируются по хешу)
   • Входные данные инструментов (tool_input) и результаты инструментов (tool_result)
   • Вывод модели (response.model_output)

   Каждое значение обрезается до 60 КБ; флаги *_truncated и *_original_length сигнализируют, когда произошло усечение.

2. Спаны моста «логи → спаны» (используются, когда HTTP-трейсы экспортируются без эндпоинта для логов) сохраняют свои существующие поля prompt, function_args и response_text, вместо того чтобы быть отброшенными.

⚠️ Предупреждение безопасности: включение этого флага передаёт полную историю разговора, содержимое файлов, прочитанных командой read_file, команды оболочки и их вывод (включая секреты в переменных окружения или аргументах), а также ответы модели в настроенный OTLP-бэкенд. Относитесь к бэкенду как к привилегированному приёмнику данных. По умолчанию флаг равен false.

Стоимость / размер полезной нагрузки: Один «тяжёлый» оборот (60 КБ системного промпта + 10 вызовов инструментов, каждый до 60 КБ входных данных + 60 КБ результата, плюс 60 КБ вывода модели) может создать до ~1,5 МБ атрибутной нагрузки до сжатия OTLP. При использовании инструментов, читающих большие файлы (read_file и т.п.), в длительных сессиях следите за пропускной способностью экспортёра.

Эта настройка не отключает конфиденциальные данные в OTel-логах или других приёмниках телеметрии; телеметрия не-внутренних ответов API может заполнять response_text, поэтому OTel-логи, UI-телеметрия и запись чата могут получать текст ответов независимо от этой настройки. QwenLogger не включает response_text.

Маршрутизация сигналов HTTP OTLP: При использовании протокола HTTP (otlpProtocol: "http") Qwen Code автоматически добавляет специфичные для сигнала пути (/v1/traces, /v1/logs, /v1/metrics) к базовому otlpEndpoint. Например, http://collector:4318 становится http://collector:4318/v1/traces для трейсов. Если URL уже заканчивается путём сигнала, он используется как есть. Переопределения эндпоинтов для отдельных сигналов (otlpTracesEndpoint и т.д.) имеют приоритет над базовым эндпоинтом и используются дословно. Протокол gRPC использует маршрутизацию на основе сервисов и не добавляет пути.

Переменные окружения для эндпоинтов отдельных сигналов также принимают стандартные имена OpenTelemetry: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, OTEL_EXPORTER_OTLP_LOGS_ENDPOINT, OTEL_EXPORTER_OTLP_METRICS_ENDPOINT. Варианты QWEN_TELEMETRY_OTLP_* имеют приоритет над вариантами OTEL_*.

Подробную информацию обо всех параметрах конфигурации см. в Руководстве по конфигурации.

Атрибуты ресурсов

Атрибуты ресурсов — это статические пары ключ-значение, присоединяемые к каждому спану, логу и метрике, экспортируемым через OTLP. Используйте их для сегментации телеметрии по команде, окружению, региону развёртывания или любому другому измерению, которое поддерживает ваш бэкенд.

Два источника, объединяемые в порядке приоритета (низший → высший):

1. Стандартная переменная окружения OTEL_RESOURCE_ATTRIBUTES
2. telemetry.resourceAttributes в .qwen/settings.json (переопределяет окружение при конфликте ключей)

OTEL_SERVICE_NAME — это отдельный запасной вариант; когда он установлен, он переопределяет service.name из любого другого источника (в соответствии со спецификацией OpenTelemetry).

Примеры

Сегментировать всю телеметрию по команде / окружению:

export OTEL_RESOURCE_ATTRIBUTES="team=platform,env=prod,cost_center=eng-123"

Направить в сборщик для каждого арендатора через service.name:

export OTEL_SERVICE_NAME=qwen-code-ci

Базовая конфигурация для всех машин (~/.qwen/settings.json) + переопределение на конкретной машине:

{
  "telemetry": {
    "resourceAttributes": {
      "deployment.environment": "production",
      "service.namespace": "engineering-tooling"
    }
  }
}

# Добавить одноразовый тег без изменения настроек:
export OTEL_RESOURCE_ATTRIBUTES="debug_run=true"

Зарезервированные ключи

Некоторые ключи управляются во время выполнения и не могут быть переопределены:

• service.version — всегда устанавливается равным версии запущенного CLI. Установка из любого источника молча игнорируется с предупреждением.
• session.id — внедряется во время выполнения для каждой сессии. Значения, предоставленные пользователем из окружения или настроек, игнорируются с предупреждением. Причина в том, что атрибуты ресурса автоматически прикрепляются к каждой точке метрики; разрешение переопределения пользователем обошло бы Управление кардинальностью ниже. Спаны и логи всегда содержат session.id.

service.name не зарезервирован; он подчиняется цепочке приоритетов выше.

Формат

OTEL_RESOURCE_ATTRIBUTES следует спецификации OpenTelemetry: key1=value1,key2=value2 с процентным кодированием значений. Пробелы в значениях должны быть закодированы как %20, запятые — как %2C (незакодированные запятые разбивают значение по неправильной границе, и вторая половина отбрасывается как некорректная). Некорректные пары пропускаются с предупреждением, а не вызывают сбой при запуске телеметрии.

Устранение неполадок: когда пользовательский атрибут не применяется

Зарезервированные ключи (service.version, session.id), некорректные пары, значения параметров, не являющиеся строками, и недопустимое процентное кодирование автоматически отбрасываются с предупреждением, записываемым через диагностический канал OpenTelemetry. Этот канал направляет данные в файл отладочного журнала (~/.qwen/log/otel-*.log), а не в консоль, поэтому поведение может выглядеть как «тихий» сбой.

Если пользовательский атрибут ресурса не отображается в экспортируемой телеметрии:

1. Проверьте ~/.qwen/log/otel-*.log на строки, содержащие cannot override (отброшен зарезервированный ключ), Skipping malformed (некорректная пара env var) или must be a string (значение параметра не строка).
2. Убедитесь, что переменная окружения установлена в среде процесса qwen-code (не только в вашей оболочке) и что значения закодированы в процентах.
3. Подтвердите, что telemetry.enabled имеет значение true — инициализация телеметрии выполняется только при включённом состоянии.

Управление кардинальностью

Метрики агрегируются по набору атрибутов на бэкенде — каждая уникальная комбинация значений атрибутов создаёт новый временной ряд. Добавление поля с высокой кардинальностью, такого как session.id, в метрику вызывает разрастание временных рядов пропорционально количеству сессий, что быстро исчерпывает хранилище метрик.

Чтобы предотвратить это, Qwen Code по умолчанию не включает атрибуты высокой кардинальности в точки данных метрик. Спаны и логи являются по-событийными и не затрагиваются, поэтому они продолжают содержать session.id для корреляции трассировок и логов.

telemetry.metrics.includeSessionId (по умолчанию: false)

Установка значения true (через настройки или QWEN_TELEMETRY_METRICS_INCLUDE_SESSION_ID=true) повторно подключает session.id к каждой точке данных метрики.

⚠️ Предупреждение: каждый сеанс CLI создаёт новое значение. Оставление этой опции включённой для парка машин перегрузит хранилище метрик. Рекомендуется только для краткосрочной отладки. Для долгосрочной корреляции по сеансам используйте запросы к бэкендам трассировок или логов.

Миграция с более ранних версий

До этого релиза session.id по умолчанию добавлялся к метрикам. Если ваши запросы Prometheus / панели Grafana / правила оповещений ссылаются на session_id в метрике, у вас есть два варианта:

Вариант A — восстановить предыдущее поведение для краткосрочной отладки:

export QWEN_TELEMETRY_METRICS_INCLUDE_SESSION_ID=true

или:

{
  "telemetry": {
    "metrics": { "includeSessionId": true }
  }
}

Вариант B (рекомендуется) — перенести анализ на уровне сеанса из метрик. Спаны и логи по‑прежнему содержат session.id, а бэкенды трассировок/логов (Jaeger, Tempo, Loki, Aliyun SLS / ARMS Tracing) изначально поддерживают разбивку по сеансам без нагрузки на кардинальность.

Клиентский HTTP-спан для исходящих запросов fetch

Когда телеметрия включена, Qwen Code регистрирует UndiciInstrumentation, который создаёт клиентский HTTP-спан для каждого исходящего запроса fetch(), инициированного процессом, включая SDK LLM (openai, @google/genai, @anthropic-ai/sdk), клиент MCP StreamableHTTP, инструмент WebFetch и любые вызовы IDE-расширений вне процесса. Спан позволяет увидеть задержку сети (TTFB / передача тела ответа) отдельно от времени обработки модели на стороне провайдера, чего существующий спан api.generateContent сам по себе не может различить.

Эти спаны отправляются в ваш собственный коллектор OTLP (или в выходной файл) так же, как и остальная телеметрия — они не влияют на то, что записывается в сам исходящий HTTP-запрос. Будет ли заголовок W3C traceparent также записываться в поток исходящего запроса, контролируется отдельной, критической для безопасности настройкой, описанной в исходящая корреляция ниже.

Предотвращение обратной связи. SDK OTel использует fetch внутри для выгрузки данных OTLP. Без защиты инструментирование fetch привело бы к трассировке этих выгрузок, которые затем также выгружались бы, создавая бесконечный цикл. Инструментирование undici в Qwen Code настраивается с помощью ignoreRequestHook, который пропускает URL, соответствующие префиксам настроенных telemetry.otlpEndpoint / telemetry.otlpTracesEndpoint / telemetry.otlpLogsEndpoint / telemetry.otlpMetricsEndpoint. В режиме вывода в файл исходящих HTTP-выгрузок нет, поэтому хук является no-op.

Исходящая корреляция (КРИТИЧЕСКАЯ ДЛЯ БЕЗОПАСНОСТИ)

Эти настройки находятся в отдельном пространстве имён верхнего уровня, а не в telemetry.* намеренно: телеметрия управляет потоком данных в бэкенд наблюдаемости оператора, в то время как outboundCorrelation.* управляет тем, какие корреляционные данные на стороне клиента qwen-code записывает в исходящие потоки запросов к API LLM, которые достигают сторонних конечных точек провайдеров LLM (DashScope, OpenAI, Anthropic и т. д.). Разные получатели — разные согласия на обработку. Все значения по умолчанию выключены. См. обсуждение в обзоре PR #4390 для обоснования этого разделения.

outboundCorrelation.propagateTraceContext

"outboundCorrelation": {
  "propagateTraceContext": false // по умолчанию
}

Когда false (по умолчанию), Qwen Code устанавливает no-op TextMapPropagator в SDK OTel. UndiciInstrumentation всё ещё создаёт клиентские HTTP-спаны для вашего коллектора OTLP, но propagation.inject() является no-op, поэтому заголовок traceparent не записывается в исходящие запросы. Идентификаторы трассировки остаются внутренними для коллектора оператора. Когда true, устанавливается стандартный составной пропагатор W3C SDK (tracecontext + baggage), и стандартный заголовок traceparent записывается в каждый исходящий fetch:

traceparent: 00-<32-hex traceId>-<16-hex parentSpanId>-<01-sampled | 00-not-sampled>

Включайте эту опцию только в том случае, если LLM-провайдер также передаёт данные в ваш OTel-коллектор для сквозной сшивки трейсов между процессами — например, ARMS Tracing, обслуживающий DashScope. Для большинства операторов значение false; сквозное продолжение трейса между разными поставщиками — нишевая задача.

Зависит от telemetry.enabled: true. OTel SDK инициализируется только при включённой телеметрии, поэтому propagateTraceContext действует только в этом состоянии. Установка true при отключённой телеметрии — это тихий no-op: ни SDK, ни пропагатора, ни traceparent в сети. Проверяйте оба флага при настройке корреляции ARMS + DashScope:

{
  "telemetry": {
    "enabled": true,
    "otlpTracesEndpoint": "http://tracing-analysis-...",
  },
  "outboundCorrelation": {
    "propagateTraceContext": true,
  },
}

Другие заголовки исходящей корреляции

X-Qwen-Code-Session-Id и X-Qwen-Code-Request-Id не входят в этот PR. Они будут спроектированы и предложены в отдельных последующих PR в том же пространстве имён outboundCorrelation.*, каждый со своей моделью угроз и процедурой согласия оператора. В ревью PR #4390 (LaZzyMan) был установлен принцип: «телеметрия не должна отправлять идентификаторы LLM-провайдерам»; работа над заголовками корреляции переносится в отдельное обсуждение архитектуры, а не реализуется в составе телеметрии.

Телеметрия Alibaba Cloud

Ручной экспорт по OTLP

Чтобы просматривать телеметрию Qwen Code в Alibaba Cloud Managed Service for OpenTelemetry, настройте Qwen Code на экспорт в OTLP-эндпоинт, предоставленный ARMS.

Установка только "target": "gcp" не настраивает адрес экспорта. Если otlpEndpoint не задан, Qwen Code по-прежнему использует http://localhost:4317. Если задан outfile, он переопределяет otlpEndpoint, и телеметрия записывается в файл, а не отправляется в Alibaba Cloud.

1. Включите телеметрию в файле .qwen/settings.json и укажите OTLP-эндпоинт:

   Вариант A: протокол gRPC (стандартный OTLP-эндпоинт):

   {
     "telemetry": {
       "enabled": true,
       "target": "gcp",
       "otlpEndpoint": "https://<your-otlp-endpoint>",
       "otlpProtocol": "grpc"
     }
   }

   Вариант B: протокол HTTP с эндпоинтами для каждого сигнала (для бэкендов, использующих нестандартные пути, например, /api/otlp/traces вместо /v1/traces):

   {
     "telemetry": {
       "enabled": true,
       "otlpProtocol": "http",
       "otlpTracesEndpoint": "http://<host>/<token>/api/otlp/traces",
       "otlpLogsEndpoint": "http://<host>/<token>/api/otlp/logs",
       "otlpMetricsEndpoint": "http://<host>/<token>/api/otlp/metrics"
     }
   }

   Примечание: При использовании протокола HTTP только с otlpEndpoint (без переопределений для отдельных сигналов) Qwen Code добавляет к базовому URL стандартные пути OTLP (/v1/traces, /v1/logs, /v1/metrics). Если ваш бэкенд использует другие пути, применяйте переопределения эндпоинтов для каждого сигнала, как показано в варианте B.

2. Если ваш эндпоинт Alibaba Cloud требует аутентификации, передайте заголовки OTLP через стандартные переменные окружения OpenTelemetry, такие как OTEL_EXPORTER_OTLP_HEADERS (или их варианты для конкретных сигналов). В настоящее время Qwen Code не предоставляет возможность напрямую указывать заголовки аутентификации OTLP в .qwen/settings.json.

3. Запустите Qwen Code и отправьте запросы.

4. Просматривайте телеметрию в Managed Service for OpenTelemetry:

   • Обзор продукта: Что такое Managed Service for OpenTelemetry? 
   • Начало работы: Начало работы с Managed Service for OpenTelemetry 
   • Точки входа в консоль:
     • Материковый Китай: trace.console.aliyun.com  (устаревшая консоль: tracing.console.aliyun.com )
     • Международная: arms.console.alibabacloud.com 
   • В консоли используйте раздел Applications для просмотра трейсов и топологии сервисов.
   • Чтобы найти OTLP-эндпоинт и информацию для доступа:
     • Новая консоль (trace.console.aliyun.com или международная): перейдите в Integration Center.
     • Устаревшая консоль (tracing.console.aliyun.com): перейдите в Cluster Configurations → Access point information.

Локальная телеметрия

Для локальной разработки и отладки вы можете собирать данные телеметрии локально:

Вывод в файл (рекомендуется)

1. Включите телеметрию в файле .qwen/settings.json:

   {
     "telemetry": {
       "enabled": true,
       "outfile": ".qwen/telemetry.log"
     }
   }

   Примечание: Когда задан outfile, экспорт по OTLP автоматически отключается. Настройки target и otlpEndpoint не нужны для вывода только в файл, их можно безопасно опустить в конфигурации.

2. Запустите Qwen Code и отправьте запросы.

3. Просматривайте логи и метрики в указанном файле (например, .qwen/telemetry.log).

Экспорт на основе Collector (продвинутый)

1. Запустите скрипт автоматизации:

   npm run telemetry -- --target=local

   Он выполнит следующее:
   • Загрузит и запустит Jaeger и OTEL collector
   • Настроит вашу рабочую область для локальной телеметрии
   • Предоставит интерфейс Jaeger по адресу http://localhost:16686 
   • Сохранит логи/метрики в ~/.qwen/tmp/<projectHash>/otel/collector.log
   • Остановит collector при выходе (например, Ctrl+C)
2. Запустите Qwen Code и отправьте промпты.
3. Просмотрите трейсы по адресу http://localhost:16686 , а логи/метрики – в файле лога collector.

Логи и метрики

В следующем разделе описывается структура логов и метрик, создаваемых для Qwen Code.

• sessionId включается как общий атрибут во все логи и метрики.

Логи

Логи – это записи определённых событий с временной меткой. Для Qwen Code логируются следующие события:

• qwen-code.config: Это событие происходит один раз при запуске с конфигурацией CLI.

  • Атрибуты:
    • model (строка)
    • sandbox_enabled (логическое)
    • core_tools_enabled (строка)
    • approval_mode (строка)
    • file_filtering_respect_git_ignore (логическое)
    • debug_mode (логическое)
    • truncate_tool_output_threshold (число)
    • truncate_tool_output_lines (число)
    • hooks (строка, типы событий хуков через запятую; опускается, если хуки отключены)
    • ide_enabled (логическое)
    • interactive_shell_enabled (логическое)
    • mcp_servers (строка)
    • output_format (строка: “text” или “json”)

• qwen-code.user_prompt: Это событие происходит, когда пользователь отправляет промпт.

  • Атрибуты:
    • prompt_length (целое)
    • prompt_id (строка)
    • prompt (строка; этот атрибут исключается, если log_prompts_enabled настроен в false)
    • auth_type (строка)

• qwen-code.tool_call: Это событие происходит для каждого вызова функции.

  • Атрибуты:
    • function_name
    • function_args
    • duration_ms
    • success (логическое)
    • decision (строка: “accept”, “reject”, “auto_accept” или “modify”, если применимо)
    • error (если применимо)
    • error_type (если применимо)
    • content_length (целое, если применимо)
    • metadata (если применимо, словарь строка -> любое)

• qwen-code.file_operation: Это событие происходит для каждой операции с файлом.

  • Атрибуты:
    • tool_name (строка)
    • operation (строка: “create”, “read”, “update”)
    • lines (целое, если применимо)
    • mimetype (строка, если применимо)
    • extension (строка, если применимо)
    • programming_language (строка, если применимо)
    • diff_stat (json-строка, если применимо): JSON-строка со следующими полями:
      • ai_added_lines (целое)
      • ai_removed_lines (целое)
      • user_added_lines (целое)
      • user_removed_lines (целое)

• qwen-code.api_request: Это событие происходит при отправке запроса к Qwen API.

  • Атрибуты:
    • model
    • request_text (если применимо)

• qwen-code.api_error: Это событие происходит, если запрос к API завершился ошибкой.

  • Атрибуты:
    • model
    • error
    • error_type
    • status_code
    • duration_ms
    • auth_type

• qwen-code.api_response: Это событие происходит при получении ответа от Qwen API.

  • Атрибуты:
    • model
    • status_code
    • duration_ms
    • error (необязательно)
    • input_token_count
    • output_token_count
    • cached_content_token_count
    • thoughts_token_count
    • response_text (если применимо)
    • auth_type

• qwen-code.tool_output_truncated: Это событие происходит, когда вывод вызова инструмента слишком велик и усекается.

  • Атрибуты:
    • tool_name (строка)
    • original_content_length (целое)
    • truncated_content_length (целое)
    • threshold (целое)
    • lines (целое)
    • prompt_id (строка)

• qwen-code.malformed_json_response: Это событие происходит, когда ответ generateJson от Qwen API не может быть разобран как json.

  • Атрибуты:
    • model

• qwen-code.flash_fallback: Это событие происходит, когда Qwen Code переключается на flash как запасной вариант.

  • Атрибуты:
    • auth_type

• qwen-code.slash_command: Это событие происходит, когда пользователь выполняет слэш-команду.

  • Атрибуты:
    • command (строка)
    • subcommand (строка, если применимо)

• qwen-code.extension_enable: Это событие происходит, когда расширение включено.

• qwen-code.extension_install: Это событие происходит, когда расширение установлено.

  • Атрибуты:
    • extension_name (строка)
    • extension_version (строка)
    • extension_source (строка)
    • status (строка)

• qwen-code.extension_uninstall: Это событие происходит, когда расширение удалено.

Метрики

Метрики – это численные измерения поведения во времени. Для Qwen Code собираются следующие метрики (имена метрик остаются qwen-code.* для совместимости):

• qwen-code.session.count (Счетчик, Целое): Увеличивается на 1 при каждом запуске CLI.

• qwen-code.tool.call.count (Счетчик, Целое): Подсчитывает вызовы инструментов.

  • Атрибуты:
    • function_name
    • success (логическое)
    • decision (строка: “accept”, “reject” или “modify”, если применимо)
    • tool_type (строка: “mcp” или “native”, если применимо)

• qwen-code.tool.call.latency (Histogram, ms): Измеряет задержку вызова инструмента.

  • Атрибуты:
    • function_name
    • decision (string: “accept” (принять), “reject” (отклонить) или “modify” (изменить), если применимо)

• qwen-code.api.request.count (Counter, Int): Считает все запросы к API.

  • Атрибуты:
    • model
    • status_code
    • error_type (если применимо)

• qwen-code.api.request.latency (Histogram, ms): Измеряет задержку запросов к API.

  • Атрибуты:
    • model

• qwen-code.token.usage (Counter, Int): Считает количество использованных токенов.

  • Атрибуты:
    • model
    • type (string: “input” (входные), “output” (выходные), “thought” (мыслительные) или “cache” (кеш))

• qwen-code.file.operation.count (Counter, Int): Считает количество операций с файлами.

  • Атрибуты:
    • operation (string: “create” (создание), “read” (чтение), “update” (обновление)): Тип операции с файлом.
    • lines (Int, если применимо): Количество строк в файле.
    • mimetype (string, если применимо): MIME-тип файла.
    • extension (string, если применимо): Расширение файла.
    • model_added_lines (Int, если применимо): Количество строк, добавленных/изменённых моделью.
    • model_removed_lines (Int, если применимо): Количество строк, удалённых/изменённых моделью.
    • user_added_lines (Int, если применимо): Количество строк, добавленных/изменённых пользователем в предложенных ИИ изменениях.
    • user_removed_lines (Int, если применимо): Количество строк, удалённых/изменённых пользователем в предложенных ИИ изменениях.
    • programming_language (string, если применимо): Язык программирования файла.

• qwen-code.chat_compression (Counter, Int): Считает количество операций сжатия чата.

  • Атрибуты:
    • tokens_before (Int): Количество токенов в контексте до сжатия.
    • tokens_after (Int): Количество токенов в контексте после сжатия.