Я навчив AI рахувати власні токени. А потім він почав їх економити

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Я досить багато працюю з OpenCode. Використовую його не тільки для написання коду, але й для досліджень, роботи з великими документами та довгих сесій, де AI поступово набирає контекст і стає набагато кориснішим співрозмовником.

У таких довгих сесіях досить швидко з’являється практична проблема: токени стають ресурсом. Причому сам AI цей ресурс майже не бачить.

Він може витратити величезний шматок контексту на читання статті, хоча для поточної задачі потрібні лише кілька абзаців. Може використати сильну модель для роботи, з якою нормально впоралась би безкоштовна. При цьому з його точки зору все гаразд: задача виконується.

У якийсь момент я подумав, що це трохи дивна ситуація. Ми просимо AI оптимізувати код, архітектуру, робочі процеси, але він при цьому не бачить економіку власної роботи.

Тому ми почали з простого питання: скільки токенів у нас взагалі залишилося?

Покажчик пального для OpenCode

З’ясувалося, що нормально отримати цю інформацію зсередини OpenCode не так просто, як мені спочатку здавалося. Ми кілька разів підходили до задачі з різних боків і зрештою зробили невеликий tool.

Він дивиться на останню завершену відповідь assistant у базі OpenCode, бере звідти кількість використаних токенів і порівнює її з практичним лімітом сесії.

Ось увесь файл context_status.ts:

import { tool } from "@opencode-ai/plugin"

const PRACTICAL_LIMIT = 140_000

export default tool({
  description:
    "Report current session context usage against the conservative 140k practical limit. Use before and after context-expensive work.",
  args: {},
  async execute(_args, context) {
    const sessionID = context.sessionID.replaceAll("'", "''")
    const query = `
      SELECT json_extract(data, '$.tokens.total') AS total
      FROM message
      WHERE session_id = '${sessionID}'
        AND json_extract(data, '$.role') = 'assistant'
        AND json_extract(data, '$.finish') IS NOT NULL
        AND json_extract(data, '$.tokens.total') IS NOT NULL
      ORDER BY time_created DESC
      LIMIT 1;
    `
    const output = await Bun.$`opencode db ${query} --format json`.text()
    const rows = JSON.parse(output) as Array<{ total: number }>
    const used = Number(rows[0]?.total)

    if (!Number.isFinite(used)) {
      return JSON.stringify({
        available: false,
        retry: true,
        reason: "No completed assistant response exists yet in this new session.",
      })
    }

    const remaining = Math.max(PRACTICAL_LIMIT - used, 0)
    const state =
      used >= 120_000
        ? "restart"
        : used >= 100_000
          ? "preserve"
          : used >= 70_000
            ? "caution"
            : "normal"

    return JSON.stringify({
      available: true,
      used,
      practicalLimit: PRACTICAL_LIMIT,
      remaining,
      percentUsed: Math.round((used / PRACTICAL_LIMIT) * 1000) / 10,
      state,
    })
  },
})

Ліміт у 140 000 токенів тут не означає технічний максимум моделі. Це консервативний практичний ліміт, який я вибрав для своєї роботи.

Ідея проста: агент отримує не тільки число, але й стан.

До 70 тисяч — normal.

Після 70 тисяч — caution.

Після 100 тисяч — preserve.

Після 120 тисяч — restart.

По суті ми просто додали покажчик пального.

Але після цього стало можливим те, чого раніше не було: AI міг не просто працювати, а бачити, скільки коштує його робота.

Скільки коштує одне дослідження

Ми почали дивитися на різні типи задач і досить швидко побачили, що одним із головних пожирачів контексту є research.

Типовий сценарій виглядає невинно. Треба знайти кілька джерел, прочитати статті, порівняти інформацію і зробити висновок.

Потім агент відкриває велику статтю на 20-30 тисяч токенів і затягує її майже повністю в основний контекст. Через кілька таких джерел значна частина робочого вікна вже використана.

При цьому часто з усієї статті реально потрібен один розділ або кілька абзаців.

Тоді ми спробували інший підхід. Якщо OpenCode вміє працювати з кількома моделями, навіщо сильній моделі самостійно виконувати всю механічну частину дослідження?

Так поступово з’явився окремий skill, який ми назвали research-economy.

Його задача вже не просто рахувати токени. Він описує спосіб проведення дослідження з урахуванням вартості контексту.

Ось повний файл SKILL.md:

---
name: research-economy
description: Use before web research, multi-model work, large source reads, or other context-expensive investigation to budget tokens and route overview work to free models.
---

# Research Economy

Protect the main session's practical context budget without reducing useful autonomy.

## Before research

1. Call `context_status`.
   If the first call in a new session returns `retry: true`, call it once more in the next tool round.
2. State one research question, the expected output, and a stopping condition.
3. Set a main-context budget. Default to at most 5,000 additional tokens for one research block.

## Route work by cost

- Use the `research-free` subagent for a general overview or broad source discovery. It is pinned to an `opencode/*-free` model. Request a compact answer with sources and uncertainties.
- Add a second free model only for genuinely parallel coverage or focused criticism, not duplicate work.
- Keep synthesis and project-specific judgment in the main model.
- Verify only decision-critical claims.
- Do not import raw research material when a bounded summary will answer the question.

## Source retrieval gate

- Do not fetch article pages or PDFs of unknown size directly into the main context.
- For verification, first obtain an abstract, metadata record, or one exact excerpt.
- Route required full-source reading to a free model and request at most 600 tokens with a URL and precise locator.
- Fetch a full source directly only when the claim is decision-critical and the compact route is insufficient; state a per-source budget first.
- Never batch-fetch multiple sources of unknown size.

## Stop and measure

Call `context_status` after the block and compare `used` with the initial value.

- `normal`: ordinary work is safe.
- `caution`: require an explicit budget for further research.
- `preserve`: delegate breadth and return only compact findings to the main context.
- `restart`: do not begin broad research; preserve current state and prepare a fresh session.

Record cost only when it teaches a reusable lesson: action, token delta, useful result, and keep/change/reject decision.

Тобто головна модель залишається тією, яка розуміє задачу, вирішує, що шукати, ставить підзадачі і збирає результат. Але широкий пошук, первинний перегляд джерел або читання великого документа можна віддати безкоштовній моделі.

Якщо мені потрібна лише анотація великої статті, немає сенсу тягнути всю статтю в основний контекст.

Якщо потрібна конкретна частина документа, можна попросити іншу модель знайти її і повернути, наприклад, 600 токенів разом із точним посиланням на місце в джерелі.

А сильна модель уже працює з цим компактним результатом.

Мінус приблизно 30 000 токенів

Коли в нас з’явився інструмент для вимірювання, стало можливим порівнювати різні способи роботи не тільки на рівні відчуттів.

На одному з дослідницьких сценаріїв використання безкоштовної моделі для допоміжної роботи зекономило близько 30 000 токенів контексту основної моделі.

Саме число тут не таке важливе. Моделі дешевшають, контекстні вікна ростуть, через рік конкретні 30 тисяч токенів можуть виглядати не дуже вражаюче.

Мені цікавішою здалася сама послідовність подій.

Спочатку AI не бачив, скільки ресурсів витрачає. Потім ми дали йому інструмент, яким це можна виміряти. Після цього змогли подивитися на реальну роботу, знайти дороге місце, спробувати інший спосіб і порівняти результат.

Вийшла приблизно така послідовність:

не бачу витрати
    ↓
вчуся їх вимірювати
    ↓
дивлюся на реальну роботу
    ↓
знаходжу дороге місце
    ↓
пробую альтернативу
    ↓
порівнюю
    ↓
залишаю те, що працює краще

І ось тут цей маленький експеримент став для мене цікавішим за початкову задачу економії токенів.

Що тут насправді цікаво

Поки що тут немає ніякого self-improving AI.

Проблему з токенами спочатку помітив я. Я приблизно знав, скільки контексту ми можемо практично використати. Разом з AI ми шукали спосіб побачити ці витрати зсередини OpenCode, вирішували, чи має це бути skill або окремий tool, а потім дивилися на результати.

Після появи вимірювання ми побачили проблему в research. Потім спробували безкоштовні моделі. Після цього змінили спосіб роботи з великими статтями та іншими дорогими джерелами.

Тобто людина поки що була важливою частиною цього циклу.

Але результат для мене цікавий з іншої причини.

У системи з’явився новий інструмент спостереження за самою собою. І після появи цього інструмента змінилася її поведінка.

Спочатку вона просто виконувала research.

Тепер перед дорогим дослідженням вона може запитати: скільки в мене залишилося контексту, який бюджет має ця задача, чи потрібно мені читати це джерело повністю і чи не варто частину роботи віддати іншій моделі.

Це все ще дуже проста річ.

Але тепер мені цікаво інше питання.

Скільки ще таких речей AI міг би поступово навчитися помічати у власній роботі?

Не тому, що ми заздалегідь написали великий framework з усіма можливими правилами, а тому, що під час реальної роботи з’явилася проблема, потім спосіб її виміряти, потім експеримент і врешті новий спосіб поведінки.

Саме це мені цікаво перевірити далі...