One key, several coding agents: making API bills readable

Keep Video — Sun, 08 Nov 2026 05:59:30 +0000

Running Claude Code, Codex and Cursor in the same team is normal. The friction rarely shows up while writing code. It shows up at the end of the month: three bills, three billing units, three vocabularies, and nobody able to say where the money went. The only decision left is "use it less".

What follows is a repeatable accounting method. It does not depend on one platform; Nbility is used as the example because the relevant pages sit together.

Step one: make spend attributable

A bill becomes unreadable when every request leaves through one key. The log then says "this much was used on Tuesday" and nothing about which tool or project spent it.

The fix is unglamorous: one token per tool. One for Claude Code, one for Codex, another for batch scripts. Name them by purpose, such as claude-code-laptop or codex-backend-refactor. Filtering request logs by token then separates spend by tool automatically.

If several people share a budget, split by person as well and use a workspace: members keep their own accounts, enterprise-key usage is charged to the owner’s wallet, and audits can move from the aggregate down to an individual.

Step two: understand what a "group" really is

Multi-model gateways usually offer several groups. The same model costs different amounts in different groups, and the difference typically comes from the upstream route, its stability and its concurrency headroom. Switching to the cheapest group without testing tends to surface a different problem: rate limits, timeouts, or behaviour that does not match expectations.

Treat a group as a trade-off rather than a discount:

Get the workflow working on the default group first, confirming client, parameters and response format.
Move non-critical work (tests, comments, documentation) to a cheaper group afterwards.
Keep the critical path on a stable group, especially where long context and continuous tool calls matter.

Pricing pages usually place the official price next to the group multiplier. That is more useful than memorising unit prices: you can see how much a route costs relative to the official rate without converting between billing units.

Step three: count the retries

One cost is routinely missed: retries. A timeout that triggers three retries appears as four calls in the ledger, while only one produced the result you wanted.

Request logs answer three concrete questions:

Which tool fails most often? If errors cluster around 401 or 403, the problem is authentication or group permissions, not the model.
Are failed requests billed? That depends on which layer failed; check the specific error and the billing rules.
Did average latency or time-to-first-token degrade in a particular window? That usually points at upstream congestion, where changing groups helps more than rewriting prompts.

The status page helps here: if the group’s recent success rate has dropped, suspect the route before suspecting your own configuration.

Step four: decide with one week of records

Do not decide "is it worth it" by feel. Take an ordinary work week and note three things every time you hit a limit or a slowdown:

What you were doing, and whether it had to finish right then.
How long the interruption lasted, and whether you switched to other useful work meanwhile.
What you would have paid to avoid that interruption.

A week later, two patterns usually appear. Some interruptions were "wait a few minutes" cases whose real cost was far below the felt cost. Others cluster around one specific task, which is where an upgrade or a different route is actually justified.

Finally: write the conclusions down

The point of accounting is not to save money; it is to give the decision something behind it. Put these in the team handbook: which tool uses which token, which tasks may run on a low-cost group, and who to ask when a particular error appears. The next time someone asks why this month cost more, the answer should be in the logs rather than in a guess.

Reference pages:

Model directory and group pricing: https://nbility.ai/models
Pricing and billing explanation: https://nbility.ai/pricing
Account and billing docs: https://nbility.ai/docs/billing
Model status: https://nbility.ai/status

Note: Nbility is a third-party AI API gateway with no affiliation with OpenAI, Anthropic or Google. Model availability, group multipliers and prices follow the upstream providers and may change; check the site for current figures. Nothing here is a cost guarantee.

Saving video, audio and subtitles offline: where a downloader stops

Keep Video — Sat, 07 Nov 2026 11:27:57 +0000

Every "video downloader" question eventually turns into the same argument: why can't it just give me the best quality, why is there no audio-only option on this page, why did the subtitle file come out empty. The answers are less about the tool and more about what the source page is willing to hand over.

These notes come from building and running Keep Video, a browser-based tool with an open-source desktop app, so they are written from the boring side of the problem.

The source decides the ceiling

A downloader resolves a media URL and lists what the source exposes. It does not re-encode a better version, and it cannot invent a 4K stream that the page never served. If a platform only ships a 720p progressive file to anonymous visitors, that is the ceiling. The same goes for containers: a tool can remux, but remuxing does not create data that is not in the stream.

The practical consequence for anyone building this: your UI should show the formats that actually came back from the extractor, not a fixed dropdown of "1080p / 720p / 480p". A fixed list lies to the user the moment the source changes.

Audio-only is a stream choice, not a conversion magic trick

Extracting audio is usually cheap because most sources already ship separate audio streams. What a tool should not promise is vocal removal or "improving" quality: if the source audio is a 64 kbps AAC track, an MP3 conversion will preserve the loss, not repair it.

For the desktop app we keep an audio guide that walks through MP3 conversion and the FFmpeg settings involved, because that is where the quality questions really live.

Subtitles are a track you either have or you don't

Subtitle handling is the most misunderstood part. SRT output means the source already had a subtitle track: text plus timecodes, no video processing. If a video has no captions, nothing is transcribed; that is a different product with a different cost model. The subtitle guide covers how track selection works and why storing the SRT next to its video file helps players pick it up.

Two rules that save support tickets:

Show the list of available languages from the source, not a hardcoded list.
Say "existing subtitles" in the product copy, and mean it.

Server-side processing or local processing

The browser tool at keep.video/app runs on a server: paste a public URL, get a finished file, no install and no account. That trade is convenience for two costs, the server does the work and the file sits in temporary storage until you download it.

The desktop builds for macOS, Windows and Linux flip that trade. Processing happens locally, there are queues and local file management, and you can use your own signed-in session for sources that need one. They also ask you to bring your own runtime dependencies (yt-dlp and FFmpeg are not bundled), which keeps the installer small and the licensing clean, at the price of one setup step.

What we refuse to write in the copy

"Unlimited free" or "100% success" claims, because site support changes weekly.
"No data leaves your device" for the online tool, because that is simply false.
"Automatic transcription" for a subtitle saver.

If you are building something in this space, the honest limits are also the best documentation: quality is capped by the source, audio is a stream choice, subtitles only exist if the source has them, and local processing is a setup decision rather than a feature bullet.

The code is MIT licensed at github.com/oiov/keep.video, and the tool is at keep.video.

Only download content you own or have permission to save.

DEV Community: Keep Video