Cost Engineering — $20 vs $200/мес: как платить в 10 раз меньше за те же результаты

Время: ~25 мин теории + 30 мин практики

Суть урока

Между $20/мес и $200/мес — не в 10 раз больше работы. Чаще — в 10 раз больше неоптимизированного кода.

Тот же чат-бот, та же контент-машина, тот же агент. Один разработчик платит $200 потому что отправляет всё в Opus, без кеша, real-time, передаёт всю историю в каждый запрос. Второй платит $20 за тот же результат — потому что роутит модели по сложности, кеширует системный промпт, batch-обрабатывает что не срочно.

Этот урок — карта 9 техник cost engineering. Каждая техника даёт от 30% до 99% экономии на своём типе нагрузки. Сложенные вместе — снижают счёт в 5-10 раз без потери качества.

🎨 Образ: платить $200 за то же, что у соседа за $20 — как ехать на такси из дома в кафе через всю Москву через Сочи. Можно дойти за 10 минут пешком. Но привычка нажать "вызвать такси" — это неоптимизированный ход. Этот урок — карта коротких путей.

🎯 Decision tree: стоит ли оптимизировать прямо сейчас

Прежде чем тратить 4-8 часов на caching и batch processing — проверь имеет ли это смысл.

Текущие costs >$200/мес?
  → Да → ОПТИМИЗИРУЙ. ROI явный.
  → Нет → Скоро вырастет до $200+ за 2-3 месяца?
    → Да → Подготовь infrastructure сейчас (техники 1 + 5)
    → Нет → Не трать время. Continue building features.

Правило окупаемости: экономия должна быть >$100/мес чтобы окупить setup time (4-8 часов первый раз + 2-3 часа debugging cache invalidation + 1 час quarterly maintenance).

🎨 Образ: ставить солнечные панели на гараж где лампочка горит 10 минут в день — глупо. Ставить их на дом с электромобилем — окупается за 3 года. Оптимизация костов работает по той же логике: сначала рост счёта, потом инфраструктура.

Ключевые концепции

• Right-sizing — выбор модели под сложность задачи (Haiku → Sonnet → Opus), а не "всё в самую умную на всякий случай"
• Prompt caching — повторяющийся контекст кешируется на 5 минут или 1 час, цена при cache hit падает в 10 раз и больше
• Batch API — асинхронная обработка до 100K запросов с дедлайном до 24 часов даёт скидку 50%
• Response caching — финальный ответ модели сохраняется в KV/Redis, повторный запрос возвращает результат без вызова LLM
• Embeddings classification — задачи классификации делаются через cosine similarity на embeddings, на порядки дешевле LLM-вызова
• Context discipline — управление окном контекста (RAG, sliding window, summary) вместо "отправим всю историю"
• Local models — типовые задачи (классификация, перевод, summarization) уходят на Ollama, costs обнуляются
• Budget alerts — автоматические триггеры на $50/$100/$200 чтобы поймать аномалию до конца месяца

Теория

Техника 1: Right-size модели (Haiku vs Sonnet vs Opus)

Anthropic держит несколько уровней моделей с разной ценой: Haiku (простые быстрые задачи), Sonnet (основная рабочая модель), Opus (сложные задачи) и Fable (самые долгие и сложные задачи). Использовать Opus для классификации тикетов — то же самое что нанимать McKinsey-консультанта чтобы он сортировал почту.

Pricing comparison (per 1M tokens, на октябрь 2026; актуальные цены и версии: Актуальное сейчас):

Соотношения (на октябрь 2026):

• Opus 5.5 / Sonnet 5.5: 2x (у Opus 4.1 к Sonnet 4 было 5x) — переключение Opus → Sonnet даёт меньше экономии чем раньше
• Sonnet 5.5 / Haiku 4.5: 2x на input и 2x на output — переход Sonnet → Haiku по-прежнему даёт ощутимую экономию
• Opus 5.5 / Haiku 4.5: 4x, Fable 5.1 / Haiku 4.5: 10x — основная вилка экономии: правильно использовать Haiku на массовых задачах

🎨 Образ: раньше Opus был как такси бизнес-класса (в 5 раз дороже эконома). На октябрь 2026 Opus — это эконом+ (всего вдвое дороже Sonnet). Главная экономия теперь не "уходи с Opus", а "не используй Sonnet там, где справится Haiku".

Правило 80/15/5 (ориентир, не закон):

• 80% задач должны идти на Haiku (classification, simple lookups, brief summaries) — здесь главная экономия
• 15% задач — на Sonnet (drafts, code, multi-step reasoning)
• 5% задач — на Opus (architecture decisions, complex strategy, critical code review) — теперь не так больно платить

Реализация роутинга в коде:

// router.ts — выбор модели по типу задачи
type TaskType = "classify" | "summarize" | "draft" | "code" | "architect";

const MODEL_MAP: Record<TaskType, string> = {
  classify: "claude-haiku-4-5",       // дёшево и быстро
  summarize: "claude-haiku-4-5",      // дёшево и быстро
  draft: "claude-sonnet-5-5",         // нужна связность
  code: "claude-sonnet-5-5",          // нужна корректность
  architect: "claude-opus-5-5",         // нужно глубокое reasoning
};

function pickModel(task: TaskType): string {
  return MODEL_MAP[task];
}

// Использование
const model = pickModel("classify");
const response = await anthropic.messages.create({
  model,
  max_tokens: 100,
  messages: [{ role: "user", content: userMessage }],
});

Сэкономишь: заметную долю costs если правильно роутишь (главное — массовые задачи на Haiku, не на Sonnet). Пример — Кейс 1 ниже (цифры иллюстративные).

Важное предупреждение про токенизатор: модели 4.7 и новее (в том числе Opus 5.5 и Sonnet 5.5) используют новый токенизатор: на тот же текст выходит примерно на 30% больше токенов, чем у Sonnet 4.6 и более ранних моделей (по документации Anthropic на октябрь 2026). Закладывай это в расчёт при переходе со старых моделей.

Про вывод моделей из API: на октябрь 2026 Haiku 4.5 остаётся в API, но ближайшая возможная дата его вывода — 15.10.2026. Следи за страницей model deprecations и держи имена моделей в одном месте кода, как в router.ts выше.

Техника 2: Prompt caching (скидка 90%)

Anthropic prompt caching — это когда повторяющийся блок контекста (системный промпт, документы, brand-voice.md, codebase context) кешируется на стороне Anthropic. При следующем вызове в течение 5 минут — этот блок стоит в 10 раз дешевле на input (у Opus 5.5 и Fable 5.1 скидка на чтение из кеша ещё больше).

Когда работает:

• Блок не короче минимума для модели (на октябрь 2026: 512 токенов у Sonnet 5.5 и Opus 5.5, 4096 токенов у Haiku 4.5; более короткий блок кеш не примет)
• Тот же контекст переиспользуется в течение 5 минут (default TTL) или 1 часа (extra TTL, чуть дороже на write)
• Cache hit — exact match на cached prefix

Множители (на октябрь 2026):

Конкретные суммы для Sonnet 5.5 (base input $2/MTok, на октябрь 2026):

Конкретные суммы для Haiku 4.5 (base input $1/MTok):

Write дороже на 25%, но hit — в 10 раз дешевле базовой. Кеш окупается после первого cache hit (5-min) или после двух (1-hour).

Реализация (Anthropic SDK):

import anthropic

client = anthropic.Anthropic()

# Большой системный промпт (длиннее минимума для кеша) — кешируем
SYSTEM_PROMPT = """[длинный brand-voice + style guide + context — 5000 токенов]"""

response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1000,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}  # 5-min cache
        }
    ],
    messages=[
        {"role": "user", "content": "Напиши пост про X"}
    ]
)

Где cache даёт максимум (ориентировочно, зависит от доли повторяющегося контекста):

• Чат-бот с большим системным промптом (FAQ + tone + examples) — 70-80% экономии
• Code assistant с проектным контекстом — 50-70%
• RAG-система с цитатами документов — 40-60%

Сэкономишь: обычно 40-60% общих costs на read-heavy workload.

Источник: platform.claude.com/docs/en/build-with-claude/prompt-caching

Техника 3: Batch API (скидка 50%)

Anthropic Batch API — отправляешь до 100,000 запросов одним батчем, получаешь все ответы в течение 24 часов. Скидка 50% на все токены (и input, и output).

Batch pricing для актуальных моделей (на октябрь 2026):

Где работает идеально:

• Генерация контента для блога (10 статей к утру)
• Массовый перевод
• Summarization архива
• Embeddings precomputation (хотя для embeddings — отдельные дешёвые модели)
• Тестовая прогонка промптов на разных моделях

Где НЕ подойдёт:

• Реалтайм чат
• Customer support
• Voice agents
• Любое где user ждёт ответ < 1 минуты

Реализация:

import anthropic

client = anthropic.Anthropic()

# Создаём batch из 1000 запросов на summarization
requests = []
for article in articles:
    requests.append({
        "custom_id": f"article-{article.id}",
        "params": {
            "model": "claude-sonnet-5-5",
            "max_tokens": 200,
            "messages": [
                {"role": "user", "content": f"Сожми в 3 буллета:\n\n{article.text}"}
            ]
        }
    })

batch = client.messages.batches.create(requests=requests)
print(f"Batch ID: {batch.id}, status: {batch.processing_status}")

# Через час-два проверяем
result = client.messages.batches.retrieve(batch.id)
if result.processing_status == "ended":
    # Скачиваем результаты
    for output in client.messages.batches.results(batch.id):
        print(output.custom_id, "".join(b.text for b in output.result.message.content if b.type == "text"))

Сэкономишь: 50% на любом bulk job. Пример расчёта (Sonnet 5.5, на октябрь 2026): 1000 статей в месяц, по ~3000 токенов на входе и ~200 на выходе. Без batch это 3M × $2 + 0.2M × $10 = $8, с batch — $4.

Источник: platform.claude.com/docs/en/build-with-claude/batch-processing

Техника 4: Local models (Ollama) для типовых задач

Open-source и open-weights модели (семейства Llama, Qwen, Gemma, Mistral, DeepSeek, gpt-oss) работают локально через Ollama. Бесплатно. Без счёта. Актуальный список моделей и тегов — в библиотеке Ollama.

🎨 Образ: облачная модель через API — арендованная машина с почасовой оплатой. Ollama — свой велосипед в гараже. На длинные дистанции velosiped проигрывает, на типовые поездки в магазин — выигрывает всегда.

Hardware (ориентиры, зависят от модели и сжатия):

• Около 16 ГБ памяти (Mac с общей памятью или видеокарта с 12 ГБ) → модели 7B-14B
• Около 32 ГБ → модели до 32B
• 64 ГБ и больше или видеокарта с 24 ГБ → 70B в сжатом (quantized) виде

Где локальные модели работают (на простых задачах качество близко к облачным):

• Классификация коротких текстов
• Извлечение entities (NER)
• Простые переводы RU↔︎EN, RU↔︎ES
• Summarization коротких документов
• Sentiment analysis
• Intent detection в чат-боте
• Reformatting (JSON → markdown, и обратно)

Где локальные НЕ работают (качество заметно ниже облачных):

• Production-grade code generation
• Long context reasoning (>32K tokens)
• Сложный multi-step reasoning
• Творческий писательский текст высокого уровня
• Tool use / function calling сложные

Установка Ollama:

# Mac (5 минут)
brew install ollama
ollama serve  # запускает локальный сервер на http://localhost:11434

# Скачиваем модель
ollama pull llama3.3:70b           # пример: ~40GB, занимает 10-30 минут
ollama pull qwen2.5-coder:32b      # пример: ~20GB, модель для кода
ollama pull qwen3:8b               # пример: небольшая универсальная модель
# свежие модели и теги — в ollama.com/library

# Тест
ollama run llama3.3 "Классифицируй: 'Купил билет' → spam/inbox/promo"

Использование через OpenAI-compatible API:

from openai import OpenAI

# Ollama exposes OpenAI-compatible endpoint
local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = local.chat.completions.create(
    model="llama3.3:70b",
    messages=[
        {"role": "user", "content": "Классифицируй email: 'Купил билет на самолёт' → spam/inbox/promo"}
    ]
)
print(response.choices[0].message.content)

Сэкономишь: 100% costs на задачах которые локалка вытягивает. Электричество не считаем — ноутбук под нагрузкой кушает порядка 30W, это центы в месяц.

См. урок Локальные AI модели для deep dive в локальные модели.

Источник: ollama.com

Техника 5: Response caching (KV / Redis)

Если 30% твоих запросов — повторяющиеся (типичные вопросы в support, стандартные переводы, classic FAQ), кешируй финальный ответ в KV-store или Redis.

Логика:

// hash request → KV lookup → если есть, возвращаем cached; если нет — вызываем LLM + сохраняем
import { createHash } from "crypto";

async function getCachedOrCall(userMessage: string, env: Env): Promise<string> {
  const key = createHash("sha256").update(userMessage.toLowerCase().trim()).digest("hex");

  // 1. Lookup в KV
  const cached = await env.RESPONSE_CACHE.get(key);
  if (cached) {
    console.log("Cache HIT");
    return cached;
  }

  // 2. Cache miss — вызываем LLM
  const response = await callClaude(userMessage);

  // 3. Сохраняем на 30 дней
  await env.RESPONSE_CACHE.put(key, response, { expirationTtl: 60 * 60 * 24 * 30 });

  return response;
}

Cloudflare KV pricing: есть бесплатный уровень с дневными лимитами на чтения и записи, сверх них оплата по факту; актуальные лимиты и цены смотри на странице тарифов Cloudflare.

Для большинства проектов остаёшься на free tier.

Где работает:

• Customer support чат-бот (типичные вопросы ~30%)
• Multi-language переводы стандартных фраз
• Поисковый автокомплит
• "Похожие товары / рекомендации" если они стабильны

Сэкономишь: до 30-50% costs если у тебя repetitive workload.

🎨 Образ: ресторан с меню. Шеф готовит каждое блюдо с нуля? Дорого. Заранее заготовленные соусы и базы (mise en place) — это response cache. Та же ситуация: повторяющиеся вопросы готовим один раз, отдаём из холодильника.

Техника 6: Embeddings вместо LLM для классификации

Задача "к какой категории относится этот текст?" — не требует LLM. Достаточно embeddings + cosine similarity.

Pricing comparison (на октябрь 2026):

Embeddings на порядки дешевле Sonnet 5.5 на input, не считая output (которого у embeddings вообще нет).

Логика:

from openai import OpenAI
import numpy as np

client = OpenAI()

# 1. Заранее embed категории
CATEGORIES = {
    "spam": "Рекламные сообщения, скам, фишинг, ненужные предложения",
    "billing": "Вопросы про оплату, счета, refund, подписка",
    "tech": "Технические проблемы, баги, не работает функция",
    "feature": "Запрос новой фичи, suggestion, идея",
}

def embed(text: str) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=text)
    return np.array(r.data[0].embedding)

category_embeddings = {name: embed(desc) for name, desc in CATEGORIES.items()}

# 2. Классификация нового сообщения
def classify(message: str) -> str:
    msg_emb = embed(message)
    similarities = {
        name: np.dot(msg_emb, emb) / (np.linalg.norm(msg_emb) * np.linalg.norm(emb))
        for name, emb in category_embeddings.items()
    }
    return max(similarities, key=similarities.get)

print(classify("Не могу войти в аккаунт"))  # → "tech"

Сэкономишь: ~99% на классификации vs LLM-based. Реальный кейс при 100K classifications/мес (avg 30 input + 5 output tokens):

• На Sonnet 5.5: ~$6/мес input + $5/мес output ≈ $11/мес
• На Haiku 4.5: ~$3/мес input + $2.50/мес output ≈ $5.50/мес
• На embeddings: центы в месяц (на входе те же ~3M токенов, по цене embedding-модели)

Embeddings выигрывают с большим отрывом даже у самой дешёвой модели, Haiku 4.5.

См. урок RAG для deep dive в RAG и embeddings.

Техника 7: Streaming + early stopping

Если результат может быть короче чем max_tokens — используй streaming с stop conditions. Output tokens в 5 раз дороже input — резать output даёт выгоду.

Пример: classifier который возвращает одно слово. Без streaming ты ставишь max_tokens=10 "на всякий". Со streaming + stop="\n" модель отдаст одно слово и остановится.

with client.messages.stream(
    model="claude-haiku-4-5",
    max_tokens=10,
    stop_sequences=["\n", ".", ","],  # стоп на любом разделителе
    messages=[
        {"role": "user", "content": "Категория одним словом: 'Не могу войти'"}
    ]
) as stream:
    for text in stream.text_stream:
        print(text, end="")

Сэкономишь: 20-40% на output tokens где результат короткий.

Техника 8: Context window discipline

Самая распространённая ошибка джунов: "уберём проблему просто отправив больше context". Каждый новый запрос заново оплачивает всю накопленную историю, поэтому счёт за длинный разговор растёт быстрее длины самого разговора.

Anti-pattern:

# ❌ ПЛОХО: отправляем всю историю в каждом запросе
messages = []
for turn in conversation_history:  # может быть 100+ turns
    messages.append({"role": turn.role, "content": turn.text})
messages.append({"role": "user", "content": new_message})
# Result: 50K tokens input на каждый ответ → ~$0.10 за turn (Sonnet 5.5, на октябрь 2026) → ~$10 за разговор из 100 turns

Правильно:

# ✅ ХОРОШО: sliding window + summary
def build_context(history, new_message):
    # Последние 10 turns в полном виде
    recent = history[-10:]

    # Старые turns — суммируем (или RAG-retrieval)
    if len(history) > 10:
        old_summary = summarize(history[:-10])  # делается раз, кешируется
        messages = [{"role": "system", "content": f"Контекст:\n{old_summary}"}]
        messages.extend(turn.to_message() for turn in recent)
    else:
        messages = [turn.to_message() for turn in history]

    messages.append({"role": "user", "content": new_message})
    return messages

Техники context discipline:

• Sliding window: последние N сообщений
• Summarization: старая часть → один компакт-блок
• RAG retrieval: доставать только relevant chunks, не отправлять весь knowledge base
• /compact: в Claude Code вручную сжимает историю сессии; при заполнении окна контекста сжатие срабатывает и автоматически (порог настраивается командой /autocompact)

Сэкономишь: 50-70% costs на длинных разговорах.

Техника 9: Free tier hopping (этично, не для production)

Бесплатные tier'ы существуют — но только для prototyping и personal projects, не для production:

Условия бесплатных уровней у хостингов и API меняются часто: проверяй страницу тарифов перед тем как строить на них. Актуальные цены и версии: Актуальное сейчас.

Этика и ограничения:

• Production требует SLA — free tiers его не дают
• Risk ban за commercial use где free только для personal
• Read terms of service внимательно
• Не используй free tier как permanent infrastructure — это нечестно к провайдеру и нестабильно

Сэкономишь: 100% во время exploration phase. После найди paid tier с adequate SLA.

Кейсы экономии

Цифры в кейсах ниже иллюстративные: это расчёты для тренировки, а не измерения реальных проектов. Цены моделей даны на октябрь 2026.

Кейс 1: Контент-конвейер (блог агентства недвижимости)

Сэкономлено: 80% ($145/мес = $1740/год)

Разбор экономии: главный вклад дают не сами cheaper-модели (Opus теперь только вдвое дороже Sonnet — не критично), а Haiku 4.5 на массовых задачах tagging + Batch API ночью + prompt cache на brand-voice.md.

Кейс 2: Customer support бот

Сэкономлено: 70% ($175/мес = $2100/год)

Главный driver — embeddings вместо LLM для routing.

Кейс 3: Voice support (см. урок Call Support AI)

Сэкономлено: 58% на минуту ($180/мес на 1000 минут, $900/мес на 5000 минут)

Маркетинговые $0.05/мин — только плата Vapi за платформу: распознавание, LLM, голос и телефония оплачиваются отдельно по ценам провайдеров (на октябрь 2026), поэтому итоговая цена минуты зависит от выбранного стека.

Cost monitoring tools

Без мониторинга оптимизация — слепота. Установи это с дня 1.

Spend limit в Anthropic Console: Settings → Billing → Spend limits → Adjust limit. Лимит ставится один: месячный потолок ниже потолка твоего тарифа. Когда он достигнут, API возвращает ошибку, пока ты не поднимешь лимит (или не наступит новый месяц), поэтому ставь его с запасом выше обычного счёта. Предупреждения на $50 и $100 сделай сам: скрипт, который раз в день читает расходы со страницы Usage, или ежедневный отчёт, как в разделе ниже.

Бюджет-дисциплина (рабочие правила)

• Daily budget check: автоматически проверяй at start of day. Если уже 80% месячного лимита — пауза или эскалация к человеку
• Per-feature budget: каждый feature имеет explicit budget. "Customer support бот: $50/мес максимум" — записан в README, отслеживается
• Anomaly detection: spike >2x average daily spend — investigate в течение часа
• Quarterly cost review: что выросло за квартал, что можно убрать, какие фичи перерасходуют

🎨 Образ: банковский счёт без выписок — не финансы, а гадание. То же с LLM-costs: без monitoring ты не управляешь, а надеешься.

Anti-patterns (НЕ делай)

• ❌ Использовать Opus для всего "чтобы наверняка"
• ❌ Передавать всю историю в каждом запросе (используй summarization)
• ❌ Не использовать prompt cache когда есть повторяющийся context >1024 tokens
• ❌ Real-time когда подойдёт Batch API (24h delay vs 50% saving)
• ❌ Скрытые API calls в loop без budget check (можно за ночь сжечь $500)
• ❌ Free tier hopping для production (нет SLA, ban risk)
• ❌ Оптимизировать когда счёт $20/мес (ROI отрицательный из-за setup time)
• ❌ Не ставить spend limit и предупреждения (узнаешь о $800 счёте только в начале месяца)

Audience рейтинг (с чего начать)

Новичок (счёт $20-50/мес, learning curve):

• Техника 1 (right-size модели) — закрывает 40-50% overspend
• Техника 8 (context discipline) — закрывает ещё 20-30%
• Итого: -50-70% costs за 2 часа работы

Средний (счёт $50-200/мес, production setup):

• • Техника 2 (prompt caching) — на 40-60% input cost
• • Техника 3 (batch API) — где не realtime
• • Техника 5 (response cache) — на типовых задачах
• Итого: дополнительно -50%

Профессионал (счёт $200+/мес, scaling):

• Все 9 техник
• Langfuse/LangSmith monitoring
• Budget alerts настроены
• Quarterly cost review в календаре
• Production discipline = costs предсказуемы

Скрытая стоимость "сэкономить"

Cost engineering — это work. Учитывай:

Правило ROI: экономия должна быть >$100/мес чтобы окупить setup time (8h × $50/h = $400 разовых — за 4 месяца отбивается).

🎨 Образ: заточить топор перед рубкой леса — оправдано когда рубишь день. Глупо когда нужно срубить одно дерево.

Чеклист (✅)

После урока у тебя должно быть:

• Понял какие 3 техники из 9 дают тебе самый большой эффект (зависит от workload)
• Задан spend limit в Anthropic Console и свои пороги предупреждений ($50 / $100 / $200 — пример)
• Знаешь свой month-to-date spend по каждому provider (Anthropic, OpenAI, Voyage, Ollama-electricity)
• Установлено разделение моделей по сложности задачи (в коде или в системном промпте orchestrator'а)
• Identified топ-3 features которые жрут больше всего токенов (через Langfuse, LangSmith или manual analysis)
• Decision tree применён: "стоит ли оптимизировать сейчас или строить фичи"

Инструменты и ресурсы

• claude.com/pricing — тарифы подписок и API
• platform.claude.com/docs/.../pricing — полная API docs с pricing
• Актуальное сейчас — сводка актуальных моделей и цен нашего курса
• Prompt caching docs — официальная документация cache_control
• Batch API docs — bulk processing с 50% скидкой
• Anthropic Console — usage tab + spend limits
• OpenAI Usage — то же для OpenAI стека
• Ollama — локальные модели за 5 минут (Llama, Qwen, Gemma, gpt-oss и др.)
• Helicone — LLM observability; с марта 2026 в режиме поддержки
• LangSmith — tracing и cost per trace
• Langfuse — open-source observability alternative
• PromptLayer — prompt versioning + analytics

Ключевые выводы

Между $20/мес и $200/мес не в 10 раз больше работы — это разница между неоптимизированным и оптимизированным кодом. Те же фичи, та же надёжность, в 10 раз дешевле — это вопрос дисциплины, не таланта.

3 техники закрывают 70% потенциала экономии: right-sizing моделей (правило 80/15/5), prompt caching на повторяющийся контекст, и context window discipline. Остальные 6 техник — для production-grade команд со счётом $200+/мес.

Оптимизируй когда счёт >$200/мес или растёт к этой отметке. Раньше — пустая трата времени; setup caching стоит 8 часов, а экономит $20/мес — это отрицательный ROI. Сначала фичи, потом оптимизация.

Следующий урок

→ Graduation — итоги первой части. Про observability, alerting и incident response для LLM-приложений: Production Observability