LLM Cost & Token Estimator — Work

ALL PROJECTS/LLM COST & TOKEN ESTIMATOR

Overview

LLM Cost & Token Estimator is an open-source developer tool that answers the two questions every engineer building on language models asks all day — how many tokens is this prompt? and what will this call cost? — without leaving the editor, without an API key, and without a single network request.

It ships as two products from one engine. The VS Code extension puts the answer on five surfaces: a hover tooltip over any prompt string, a CodeLens above detected prompts, a live status-bar readout of the current selection, a full comparison dashboard with a draggable output-token slider, and a workspace-wide scan that reports what every prompt in the project costs per run. The MCP server exposes the same engine as three tools to Claude, Cursor or any MCP client, so the same question can be asked in a chat instead.

Twenty-eight models across seven providers are priced out of the box — the GPT-4o/4.1/o-series, Claude 4/3.7/3.5, Gemini 2.5/2.0/1.5, DeepSeek, Mistral, Llama and Grok — and the comparison is always side by side, cheapest first, because the point is the trade-off, not a single number. It is MIT-licensed and published to Open VSX, npm and the Official MCP Registry.

Problem

The honest version of this problem is harder than "count the tokens".

Only OpenAI publishes a tokenizer you can run locally. Anthropic, Google and everyone else do not, so any tool claiming an exact count for Claude or Gemini is guessing and hiding it. A cost tool that quietly presents a guess as a fact is worse than no tool — an engineer will make a real budgeting decision on it.

Token count is also only half the price. What a call actually costs is input plus the completion the model writes back, and output is usually priced several times higher than input. A tool that reports only input tokens gets the number that matters wrong by an order of magnitude, and the completion length is a guess that belongs to the user, not the tool.

Then there is the shape of the thing. An editor extension that reaches out to a pricing API is a tool that fails offline, leaks what you are writing, and needs a key before it is useful. And the same engine had to serve two very different front ends — an editor with a UI, and a chat client with a tool protocol — without either one forking the logic.

System Design

How It Works

01/04

Hover a prompt, see the trade-off

How a prompt string in a file becomes a ranked, honest cost comparison without a single network call.

1A string literal is recognised as prompt-like from its shape and the identifier next to it
2The text is tokenized once per encoding — exactly for OpenAI, approximately for the rest — and cached so models sharing an encoding are not re-tokenized
3Each model is priced at its own input and output rate, using the assumed completion length from settings
4Results are sorted cheapest first, approximations are marked, and anything over a model's context window is flagged
5The comparison renders inline — in the hover, the CodeLens and the status bar, from the same result

Drag the assumption

How the dashboard makes the output-token guess — the variable that dominates the bill — something you can move.

1The panel receives the whole catalogue priced at the current assumption, along with each model's raw rates
2Moving the slider recomputes every row in the panel itself, so no re-tokenization is needed
3Twenty-eight models re-rank instantly, and columns can be sorted or filtered down to just the configured set
4The resulting table can be copied as Markdown for a pull request or a budget discussion

Price the whole project

How a repository of prompts becomes a single number an engineer can take to a planning meeting.

1One command walks the workspace and scans every supported file for prompt-like strings
2Each prompt is tokenized and priced on the first configured model, and totals are aggregated per file
3A report shows estimated cost per run, prompt count and token count, ranked by cost
4Every row links straight to the prompt that produced it

One tag ships both artifacts

How a version tag turns into a published extension and a published MCP server with no manual step.

1Every push runs lint, strict type-check, the unit and load suites, and an end-to-end run against a mocked editor
2A version tag re-runs the full verification, then packages the extension and builds the MCP server
3Both are published to their registries and the build is attached to a GitHub release
4The MCP server's registry manifest is published in the same run, so the two never drift apart

Key Features

Multi-model comparison — token count and estimated cost across every configured model, side by side, cheapest first
Five in-editor surfaces — hover tooltip, CodeLens above detected prompts, live status-bar readout, comparison dashboard and workspace scan report
28 models across seven providers out of the box, with a visual picker for choosing which to compare
Exact OpenAI tokenization on the machine; every approximate count marked with a `~` and an explicit disclaimer
Live output-token slider that re-ranks the whole catalogue instantly, plus sortable columns and a configured-models filter
Workspace scan — one command reports the estimated cost per run of every prompt in the project, with a clickable per-file breakdown
Custom models and negotiated rates from settings, validated on load, with invalid entries reported rather than dropped
Optional live pricing from a maintained public source, cached, with an offline fallback — plus context-window warnings, Markdown export, and an MCP server exposing the same engine to any MCP client

Outcomes

Shipped a working developer tool end to end and published it to three registries — the extension to Open VSX, the MCP server to npm, and the server to the Official MCP Registry
Built one engine that serves two products: the MCP server imports the extension's own tokenizer, pricing and estimator rather than reimplementing them, so the two can never disagree
Made the tool's own uncertainty a feature — exact and approximate counts are visually distinguished everywhere, and bundled prices are labelled as representative and verifiable against each provider
Kept it genuinely local-first: the extension ships a single runtime dependency, and there is no API key, no account and no network call in the default path
Held it to product standards rather than side-project standards — 60 unit and load tests, strict types, lint and an end-to-end run gating every push, with contributor docs, a code of conduct and issue templates in the repository
Open-sourced under MIT, with the repository already picking up forks and outside pull requests