DEV Community: Ruslan Sivak

Панель говорила «осталось $189». Консоль говорила «$291». Оба числа были неверны.

Ruslan Sivak — Sat, 17 Oct 2026 01:49:15 +0000

Наша статус-панель показывала израсходовано $10.80 из $200.00, осталось $189.20. Консоль провайдера в соседней вкладке показывала осталось $291.77. Один аккаунт, один день.

Оба числа были неверны, и по разным причинам. Это разбор того, как найти число, которое на самом деле верно, и того изменения в дизайне, после которого панель больше не сможет смешать две разные системы учёта.

Что за задача

Это плагин для агентной обвязки Claude Code: мод, который регистрирует панель интерфейса и перерисовывает её по таймеру. Панель показывает остаток на счету рядом с окнами лимитов, заполнением контекста и стоимостью сессии. Написан на TypeScript, подгружается исходником при старте сессии, и у него есть набор тестов, который прогоняет его через поддельный движок.

Провайдер — реселлер, работающий на new-api, открытой консоли, на которой построена изрядная доля реселлеров LLM-API (её предок one-api ведёт себя так же). Эта деталь пригодится дальше.

Ошибка первая: лимит, которого никто не задавал

Панель сравнивала расход с budgetUsd — настройкой со значением по умолчанию 200:

const DEFAULT_BUDGET_USD = 200

Эти 200 никто не измерял. Это была заглушка, которая уехала в релиз, и поскольку она рисовалась с двумя знаками после запятой рядом с настоящим расходом, читалась она как данные. Панель уверенно сообщала, что осталось 189 долларов, — а это ровно тот сорт неверного ответа, который хуже, чем «неизвестно»: по нему начинаешь действовать.

Расход брался из billing-API:

GET /v1/dashboard/billing/usage
{"total_usage": 3004}   // центы

Это endpoint, совместимый с OpenAI, и у этого провайдера он отдаёт другое число, чем консоль. Об этом ниже.

Ошибка вторая: считалось не то

Консоль отдаёт сам аккаунт:

GET /api/user/self
Authorization: Bearer <токен консоли>
New-Api-User: <числовой id пользователя>

{"data": {"quota": 145883249, "used_quota": 16616751}, "success": true}

quota — сколько осталось, used_quota — сколько сожжено. Оба в единицах квоты, не в центах и не в долларах.

Две засады, каждая стоила лишнего круга:

Заголовок New-Api-User не опционален. Без него запрос падает так, что это выглядит как плохой токен, — и идёшь перевыпускать токен на ровном месте.
Нужен коэффициент единиц. new-api и one-api по умолчанию кладут 500 000 единиц на доллар США, но это настраивается на конкретной установке, так что хардкодить его второй раз нельзя.

Впрочем, искать коэффициент не пришлось. Подсказка была в самих числах: quota + used_quota дало 162 500 000, а собственная страница консоли показывала аккуратные $325.00 итого. Круглые итоги случайно не получаются. 162 500 000 / 325 = 500 000.

Так что честное прочтение такое: осталось $291.77, израсходовано $33.23, всего $325.00. (Именно «всего» и позволило вычислить коэффициент; сама панель его больше не тащит — об этом в конце.)

Две системы учёта не сходятся

Источник	Израсходовано
`/v1/dashboard/billing/usage`	$30.04
Консоль (`used_quota`)	$33.23

Ни то, ни другое не ошибка округления. Если усреднить, получится число, верное сразу нигде. Решение здесь не арифметическое — надо выбрать, какой источник главный, и пометить каждую цифру тем, откуда она пришла, чтобы две системы учёта никогда не смешались молча.

Это размеченное объединение и null:

export type QuotaOrigin = 'console' | 'billing'

export type QuotaBudget = {
  at: number
  origin: QuotaOrigin
  balanceUsd: number | null   // только консоль
  spentUsd: number | null     // только billing
  budgetUsd: number
  // ...
}

А слияние снимков переносит цифры только из прошлого снимка того же источника:

const merged = (was: QuotaBudget | null, now: QuotaBudget): QuotaBudget => {
  const same = was !== null && was.origin === now.origin ? was : null

  return {
    origin: now.origin,
    balanceUsd: now.balanceUsd ?? same?.balanceUsd ?? null,
    spentUsd: now.spentUsd ?? same?.spentUsd ?? null,
    // ...
  }
}

Разбор ответа намеренно строг в том, что вообще считается ответом:

const balanceOf = (body: unknown, quotaPerUnit: number) => {
  if (typeof body !== 'object' || body === null) return null
  const data = (body as Record<string, unknown>).data
  if (typeof data !== 'object' || data === null) return null

  const { quota } = data as Record<string, unknown>
  if (typeof quota !== 'number' || !Number.isFinite(quota) || quota < 0) return null

  return { balanceUsd: quota / quotaPerUnit }
}

Всё, что не конечное неотрицательное число, возвращает null, а null рисуется как «данных нет» — не как ноль и не как прошлонедельное число, выданное за сегодняшнее.

Главный источник теперь консоль, а billing-API остался запасным путём на случай, когда токен консоли не задан: он работает с токеном сессии, который есть всегда. Процент принадлежит только запасному пути — это доля от предела, который назван в той же строке, — а в строке консоли одно число, и делить его не на что:

const budgetPercent = (shown: QuotaBudget) =>
  shown.spentUsd === null || shown.budgetUsd <= 0
    ? 0
    : Math.max(0, Math.min(100, (shown.spentUsd / shown.budgetUsd) * 100))

Тест, который держит это честным

Самый полезный тест в наборе — тот, который проверяет, что запрос не был сделан:

test('остаток счёта берётся из консоли, а billing-API не спрашивается', async ($, on) => {
  const asked: string[] = []
  on('http.fetch', (_$, e) => {
    asked.push(e.url)
    if (e.url.includes('/api/user/self')) return { value: SELF }
    if (e.url.includes('/api/log/self?p=1')) return { value: logPage(ones(1), 1) }
    return { value: { status: 404, ok: false, headers: {}, text: '' } }
  })

  // ...
  expect(await ui.find({ text: /^остаток \$291\.77$/ })).toBeDefined()
  expect(asked.some(url => url.includes('/v1/dashboard/billing/usage'))).toBe(false)
})

Плюс отдельный — на заданный коэффициент единиц, и ещё один: консоль отвечает 500, а панель обязана показать прошлый консольный остаток, помеченный как устаревший, и с причиной:

остаток $291.77 · 5 мин назад · ответ 500

Устаревшее с честной пометкой лучше свежего и выдуманного. Обе проверки привязаны к строке целиком: если рядом с остатком снова появится второй доллар, набор упадёт, а не пропустит его обратно.

Что я сделал бы иначе

Никогда не выпускать правдоподобное значение по умолчанию для измерения. Именно 200 в роли «лимита» и был настоящей ошибкой. Значение по умолчанию, похожее на данные, прочитают как данные. Если значение неизвестно, интерфейс должен это сказать.
Коэффициент единиц — в настройки, а не во вторую константу. Коэффициент — свойство конкретной установки, и если он настраивается на стороне сервера, его в конце концов настроят.
Дать «неизвестно» собственное состояние. Пусто, ноль и устаревшее — три разные вещи. Схлопывание их в одно и есть то, из-за чего панель уверенно ошибается.
Токен сессии отправлять только на тот хост, для которого он настроен. Панель читает переменную окружения, в которой лежит в том числе учётка сессии; перед тем как её приложить, она сверяет хост запроса с настроенным базовым адресом провайдера, и на это поведение есть тест. Панель — отличное место, чтобы случайно утечь токеном.

Сейчас панель показывает остаток $291.77, ровно как консоль провайдера. Она перестала угадывать.

Вместе с этим ушли «всего» и полоса, показывавшая, какая доля пополнения израсходована. Когда есть остаток, по которому и принимаешь решение, это были ещё два числа в ответ на вопрос, которого никто не задавал, — а проценту полосы на экране не осталось знаменателя, чтобы хоть что-то значить.

Что уже писали по этой теме

Материалы с DEV, которые повлияли на то, как я об этом думал:

Monitoring API credit usage before an automation runs out — messora. Тот же отказ: сборщик совершенно здоров и тихо ничего не собирает, потому что баланс дошёл до нуля.
Three Ways to Monitor Prepaid API Balances (Excel, Python + Cron, Power Automate) — saint_vandora. Полезно о том, где такая проверка должна жить в конвейере, а не в интерфейсе.
Hard caps on autonomous agent API spend — infracore. Вопрос сложнее того, о котором эта панель только сообщает: как потолок не наблюдать, а обеспечивать.

The budget panel said $189 left. The console said $291. Both numbers were wrong.

Ruslan Sivak — Sat, 17 Oct 2026 01:48:35 +0000

Our little status pane said $10.80 spent of $200.00, $189.20 left. The provider's console, open in the next tab, said $291.77 remaining. Same account, same day.

Both numbers were wrong, and for different reasons. This is the write-up of finding the number that is actually true, and of the one-line-shaped design change that stops the pane from ever mixing two accountings again.

The setup

It's a plugin for the Claude Code agent harness: a mod that registers a UI pane and redraws it on a timer. It shows the account's remaining balance next to the rate-limit windows, the context fill, and the session cost. It runs in TypeScript, it is loaded as source at session start, and it has a test suite that drives it through a mocked engine.

The provider is a reseller running new-api, the open-source console that a lot of LLM API resellers are built on (its ancestor, one-api, behaves the same way). That detail matters later.

Bug one: a budget nobody set

The pane compared a spend figure against budgetUsd, a config value with a default of 200:

const DEFAULT_BUDGET_USD = 200

Nobody measured that 200. It was a placeholder that shipped, and because it was rendered with two decimal places next to a real spend number, it read as data. The pane confidently announced that 189 dollars were left, which is exactly the kind of wrong answer that is worse than "unknown" — you act on it.

The spend figure came from the billing API:

GET /v1/dashboard/billing/usage
{"total_usage": 3004}   // cents

That endpoint is the OpenAI-compatible one, and on this provider it reports a different number from the console. More on that below.

Bug two: it was counting the wrong thing

The console exposes the account itself:

GET /api/user/self
Authorization: Bearer <console token>
New-Api-User: <numeric user id>

{"data": {"quota": 145883249, "used_quota": 16616751}, "success": true}

quota is what's left; used_quota is what's been burned. Both are in quota units, not cents, not dollars.

Two gotchas, both of which cost me a round trip:

The New-Api-User header is not optional. Without it the request fails in a way that looks like a bad token, so you go and re-paste the token for no reason.
You need the unit ratio. new-api and one-api default to 500,000 units per US dollar, but it's configurable per deployment, so it is not something to hardcode a second time.

I didn't have to look the ratio up, though. The tell was in the numbers: quota + used_quota came to 162,500,000, and the console's own page showed a tidy $325.00 total. Round totals don't happen by accident. 162,500,000 / 325 = 500,000.

So the honest reading was: $291.77 left, $33.23 spent, $325.00 total. (The total is what pinned the ratio down; the pane itself no longer carries it — more at the end.)

The two accountings do not reconcile

Source	Spent
`/v1/dashboard/billing/usage`	$30.04
Console (`used_quota`)	$33.23

Neither is a rounding error. If you average them you get a number that is true in no system. The fix is not arithmetic — it's to decide which source is authoritative and to label every figure with where it came from, so two accountings can never be silently blended.

That's a discriminated union and a null:

export type QuotaOrigin = 'console' | 'billing'

export type QuotaBudget = {
  at: number
  origin: QuotaOrigin
  balanceUsd: number | null   // console only
  spentUsd: number | null     // billing only
  budgetUsd: number
  // ...
}

And the merge function only carries figures across from a previous snapshot of the same origin:

const merged = (was: QuotaBudget | null, now: QuotaBudget): QuotaBudget => {
  const same = was !== null && was.origin === now.origin ? was : null

  return {
    origin: now.origin,
    balanceUsd: now.balanceUsd ?? same?.balanceUsd ?? null,
    spentUsd: now.spentUsd ?? same?.spentUsd ?? null,
    // ...
  }
}

The parsing is deliberately strict about what counts as an answer:

const balanceOf = (body: unknown, quotaPerUnit: number) => {
  if (typeof body !== 'object' || body === null) return null
  const data = (body as Record<string, unknown>).data
  if (typeof data !== 'object' || data === null) return null

  const { quota } = data as Record<string, unknown>
  if (typeof quota !== 'number' || !Number.isFinite(quota) || quota < 0) return null

  return { balanceUsd: quota / quotaPerUnit }
}

Anything that isn't a finite, non-negative number returns null, and null renders as "no data" — not as zero, and not as last week's number dressed up as this week's.

The console is now the primary source, and the billing API survives only as a fallback for when the console token isn't configured, because it works with the session token that's always present. The percentage is the fallback's alone — a share of a limit that the same line spells out — while the console's line is one number with no denominator to divide by:

const budgetPercent = (shown: QuotaBudget) =>
  shown.spentUsd === null || shown.budgetUsd <= 0
    ? 0
    : Math.max(0, Math.min(100, (shown.spentUsd / shown.budgetUsd) * 100))

The test that keeps it honest

The most useful test in the suite is the one that asserts a request was not made:

test('balance comes from the console and the billing API is never asked', async ($, on) => {
  const asked: string[] = []
  on('http.fetch', (_$, e) => {
    asked.push(e.url)
    if (e.url.includes('/api/user/self')) return { value: SELF }
    if (e.url.includes('/api/log/self?p=1')) return { value: logPage(ones(1), 1) }
    return { value: { status: 404, ok: false, headers: {}, text: '' } }
  })

  // ...
  expect(await ui.find({ text: /^balance \$291\.77$/ })).toBeDefined()
  expect(asked.some(url => url.includes('/v1/dashboard/billing/usage'))).toBe(false)
})

Plus one for a configured unit ratio, and one where the console answers 500 and the pane is required to show the previous console balance, marked stale, with the reason:

balance $291.77 · 5 min ago · response 500

Stale-and-labelled beats fresh-and-fabricated. Both assertions are anchored to the whole line, so a second dollar figure reappearing next to the balance fails the suite rather than sneaking back in.

What I'd do differently

Never ship a plausible default for a measurement. 200 as a "budget" was the actual bug. A default that looks like data will be read as data. If the value isn't known, the UI should say so.
Make the unit ratio config, not a second constant. The ratio is a property of the deployment, and if it's configurable on the server side, it will eventually be configured.
Give "unknown" its own state. Empty, zero, and stale are three different things. Collapsing them is how a panel ends up confidently wrong.
Only send the session token to the host it was configured for. This pane reads an env var that also carries the session credential; it checks that the request's host matches the configured provider base URL before attaching it, and a test pins that behaviour. A panel is a nice place to accidentally exfiltrate a token from.

The pane now reads $291.77 left, which is what the provider's own console says. It stopped being a guess.

The console's total went with it, and so did the bar showing what share of the top-up was gone. Once the remaining balance is the number you act on, those were two more figures answering a question nobody asked — and the bar's percentage had no denominator left on screen to mean anything.

Community wisdom

Prior art that shaped how I thought about this, from the DEV archive:

Monitoring API credit usage before an automation runs out — messora. Same failure mode: a scraper that is perfectly healthy and quietly producing nothing because the balance hit zero.
Three Ways to Monitor Prepaid API Balances (Excel, Python + Cron, Power Automate) — saint_vandora. Useful on where the check belongs in a pipeline rather than in a UI.
Hard caps on autonomous agent API spend — infracore. The harder question this pane only reports on: enforcing a ceiling instead of watching one.

relnotes: Release Notes From Git History, Generated by an Open-Weight Model

Ruslan Sivak — Wed, 14 Oct 2026 16:58:04 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

relnotes — a CLI that turns your git history into user-facing release notes, generated by an open-weight model running on your own machine.

The thing it fixes is small and annoyingly real: every project ships, nobody writes the changelog, and the release goes out with either no notes or "bug fixes and improvements". relnotes reads the git log between two refs and rewrites it into grouped, plain-English bullets — the way a human would have written them if they had twenty minutes they don't have.

Who would pay for it: anyone shipping software on a schedule. Freelancers billing clients for a monthly release, small teams that maintain a public changelog, maintainers of side projects who abandoned theirs six months in. It's the exact "tedious task that someone keeps complaining about" the prompt describes.

Demo

$ relnotes.py --offline

### Added

- initial CLI skeleton with offline template rendering

### Changed

- add README and relnotes agent skill
- cover conventional-commit parsing and CLI end to end

That is the tool's real output on its own repository, run offline — commit
6f795d2 exists
because of it. With a local open-weight model the same command produces the
same shape, only the bullets get rewritten into end-user language. The full
project is at github.com/Mystical89/relnotes.

Code

github.com/Mystical89/relnotes — MIT licensed, Python 3.10+, no dependencies, 5 passing tests.

relnotes.py          # the CLI: git log -> model -> changelog
test_relnotes.py     # parsing, grouping, and end-to-end CLI tests
skills/relnotes/     # agent skill, so an agent can run it for you

How I Built It

The open-source AI part is the core of how it works, not a garnish:

Open-weight model: any OpenAI-compatible endpoint backed by an open-weight model — Ollama by default (qwen2.5:3b), or LM Studio, llama.cpp, vLLM with one flag.
A strict system prompt does the rewriting: group under Added / Fixed / Changed, ≤12 words per bullet, no commit hashes, no file names, no "refactor"/"chore" jargon, drop uninformative commits. Temperature 0.3 so two runs of the same release produce the same notes.
Open-source agent harness integration: it ships as a Hermes skill following the Agent Skill Open Standard, so an agent can be told "write the release notes since v1.2.0" and call it directly.

Conventional Commits drive the section grouping, which is what makes the offline fallback structurally identical to the model output.

Why Does Open Innovation Matter?

Three reasons, all of which change whether the tool is actually viable:

It costs nothing per release. A 3B model on a laptop replaces a hosted API bill for summarising text you already own. At one release a week it's noise, but for the solo dev shipping every other day it's the difference between a tool they use and one they try twice.

Your commit history never leaves the machine. This is the part that made me build it this way rather than as a hosted web app. Commit messages leak internal project names, unreleased features, and occasionally a pasted secret. You cannot safely send that to a third-party API, so a hosted version of this tool either asks you to trust it with your history or strips out everything interesting. Local inference makes the safe version the default version.

No vendor lock-in. The model is a flag, not a decision. Swap qwen2.5:3b for something bigger as hardware allows, or point it at a different server — no code changes.

Not yet — this is day one of the project. The plan is to run it on the next release of this very repo and paste the result in as a comment, which is either a good demo or an honest bug report.

Update, same day: the plan took about ten minutes. relnotes has now been run on its own repository — commit 6f795d2 exists because of it:

$ relnotes.py --offline

### Added

- initial CLI skeleton with offline template rendering

### Changed

- add README and relnotes agent skill
- cover conventional-commit parsing and CLI end to end

Two honest notes on that run. First, there is no model endpoint on this machine yet, so this is the deterministic template path, not the model path — the README says so too. Second, the first attempt was wrong: --since <root> printed nothing under Added, because root..HEAD excludes the root commit itself. I caught it by diffing the output against git log, and it is now the first pitfall in the README. Writing the tool's own release notes found a real bug in the tool, which is either a good sign or a very small sample.

Nobody has paid yet. Next step is qwen2.5:3b through Ollama so the model path gets the same real run.