DEV Community: Weston G

How do you estimate LLM API costs before committing to a model?

Weston G — Thu, 14 May 2026 17:26:12 +0000

Quick question for anyone building with LLM APIs.

The cost spread across current models is wild — GPT-4o vs Gemini 2.0 Flash is roughly a 30x difference per token. For most tasks, you could swap to a cheaper model and users wouldn't notice. But you only realize this late in the project, after the architecture is already set.

What's your process for thinking about costs before you start building?

I built a client-side token counter (llmtokens.vercel.app) that shows real-time cost breakdowns across 25+ current models as you type — GPT-4o, Claude 4 Sonnet/Opus, Gemini 2.5 Pro/Flash, o3, DeepSeek, Llama, etc. It runs entirely in the browser, no signup.

The goal was to make the cost conversation happen at architecture time, not bill-shock time.

Curious what others do:

Do you pick a model first and accept the cost, or estimate cost first and pick accordingly?
Any heuristics for which tasks justify premium models vs. flash/mini tiers?
Anything about cost estimation you wish you'd known earlier?

I built a client-side LLM token counter because I kept guessing at prompt costs

Weston G — Thu, 14 May 2026 09:33:18 +0000

Estimated read time: 4 minutes

I was building a RAG pipeline last month. Standard stuff — system prompt, some retrieved chunks, user message. Somewhere around the third iteration of tweaking the system prompt I realized I had absolutely no idea what I was spending per request.

The system prompt alone was a wall of text. Around 500 words. That's fine in isolation, but this thing was getting prepended to every single request, and I had no intuition for what that translates to in dollars.

So I opened the OpenAI Tokenizer, pasted the text, got a number. Then I had to open a calculator to multiply tokens × price. Then I wanted to compare to Claude's pricing. Then Gemini. By request five I was annoyed enough to just build the thing.

The concrete example that made it real

Here's a system prompt I actually had sitting in my codebase:

You are a helpful assistant for a B2B SaaS product. You help users understand 
their billing, navigate features, and troubleshoot common issues. Always be 
concise. When you don't know something, say so rather than guessing...
[+ ~450 more words of context, examples, and edge case instructions]

~500 words. Let's call it 650 tokens (words aren't tokens — more on that below).

At current pricing, that single system prompt costs:

Model	Input price	Cost per request	Cost per 10k requests
GPT-4o	$2.50/1M	$0.001625	$16.25
GPT-3.5 Turbo	$0.50/1M	$0.000325	$3.25
Claude 3 Haiku	$0.25/1M	≈ $0.000163	≈ $1.63
Gemini 1.5 Flash	$0.075/1M	≈ $0.0000488	≈ $0.49

That's a 33x cost difference between GPT-4o and Gemini 1.5 Flash for the exact same text. At 10k daily active users doing a few requests each, you're looking at the difference between a $50/day line item and a $1,600/day one.

And that's just the system prompt. Add the user message, the conversation history, the retrieved chunks... the numbers compound fast.

What I built

LLM Token Counter — paste text, pick a model, get token count + cost estimate instantly. No account, no backend, your text never leaves the browser.

Supports:

GPT-4o ($2.50/1M input)
GPT-3.5 Turbo ($0.50/1M input)
Claude 3 Haiku ($0.25/1M input)
Gemini 1.5 Flash ($0.075/1M input)

How it works technically

The core is js-tiktoken, which is a WASM port of OpenAI's tokenizer that runs entirely in the browser. For GPT models, this gives you the exact same token count you'd get from the API — same cl100k_base encoding, same results.

The interesting constraint: Claude and Gemini both use proprietary tokenizers that aren't publicly available as standalone libraries. Anthropic doesn't ship a JS tokenizer. Google's @google/generative-ai SDK does tokenization via API call (which defeats the whole purpose of a client-side tool).

My workaround: use cl100k_base for Claude and Gemini too, and flag the result as approximate. For typical English prose, cl100k gives you counts within about 5% of what Anthropic and Google's actual tokenizers would return. For code or non-English text, the variance is higher.

It's not perfect, but "within 5% for budgeting purposes" is way more useful than "no idea." I put a ≈ symbol next to those counts so you know they're estimates.

// The whole counting function — it's genuinely this simple
function countTokens(text: string, model: Model): number {
  if (!text) return 0;
  const enc = encodingForModel(model.tiktokenId);
  const tokens = enc.encode(text);
  return tokens.length;
}

For Claude and Gemini I pass "gpt-4" as the tiktokenId, which maps to cl100k_base. It works. It's a proxy. I'm calling it out rather than hiding it.

Why client-side matters here

I thought about building this as a tiny serverless function. It would have been five minutes of work.

But I kept coming back to the fact that the whole use case is "paste your prompts in." People's prompts contain confidential stuff — product context, internal workflows, sometimes actual user data they're debugging with. Shipping that to a server I control (even one that immediately discards it) felt wrong for a tool this casual.

WASM in the browser means I'm not in that data path at all. The tokenizer runs locally, the number appears instantly, nothing is logged anywhere. That also makes it fast — no network round trip, no cold starts, results update as you type.

What it doesn't do (yet)

Output token pricing (completions cost differently, and estimating output is harder since you don't know the length)
Batch cost estimator (X requests/day at Y avg tokens)
GPT-4o with vision or audio pricing
Newer models — I'll update the price table as things change

If any of those would be useful to you, the source is on GitHub and PRs are open.

The thing I learned building this

Words ≠ tokens in ways that bite you. "tokenization" is 3 tokens in cl100k. A JSON object with lots of punctuation tokenizes way worse than the same information in prose. Code is somewhere in between.

Rule of thumb I use now: English prose ≈ 0.75 tokens/word. Code ≈ 0.5–0.6 tokens/word. JSON with lots of keys ≈ 1.2–1.5 tokens/word equivalent. The counter makes it concrete — I've started pasting my prompts in before I finalize them.

What's your approach to tracking LLM costs during development? Are you eyeballing it, running it through the OpenAI playground, or do you have something more systematic set up? Curious what's actually working for people.

LLM Token Costs: Why Your Prompt Might Cost 10x More Than You Think

Weston G — Thu, 14 May 2026 09:27:36 +0000

LLM Token Costs: Why Your Prompt Might Cost 10x More Than You Think

If you're building with LLM APIs, you've probably wondered: how many tokens is this prompt actually using?

I built a free tool to answer that: LLM Token Counter

What it does

Paste any text and instantly see the token count
Compares costs across GPT-4o, GPT-3.5 Turbo, Claude 3 Haiku, and Gemini 1.5 Flash
No login, no backend — runs entirely in your browser
Uses the actual cl100k_base tokenizer (same as OpenAI) for accurate GPT counts

The cost gap is real

Consider a typical system prompt + user message (about 500 tokens):

Model	Cost per 1M tokens	Cost for 500 tokens
GPT-4o	$2.50	$0.00125
GPT-3.5 Turbo	$0.50	$0.00025
Claude 3 Haiku	$0.25	$0.000125
Gemini 1.5 Flash	$0.075	$0.0000375

That's a 33x cost difference between GPT-4o and Gemini 1.5 Flash for the same prompt.

Why client-side matters

Most token counters require you to send your prompt to a server. This one runs entirely in your browser using js-tiktoken — your prompts never leave your machine.

Try it

👉 https://code-two-delta.vercel.app

Source code: github.com/SolvoHQ/llm-token-counter

Would love feedback — what models or features would make this more useful for your workflow?

Paste a wallet, get a personal airdrop verdict — and call the same logic from any LLM

Weston G — Mon, 11 May 2026 20:06:05 +0000

Paste a wallet, get a personal airdrop verdict — and call the same logic from any LLM

Two surfaces, one rule registry: a browser tool and an MCP tool that share the exact same 14 hand-verified on-chain rules and return the exact same verdict shape.

The problem

Airdrop directories are full of "you might be eligible for 312 airdrops!" claims. They match on chain ("you've used Ethereum → you qualify for every Ethereum airdrop"), which is useless. The real eligibility lives on each project's contract or off-chain criteria.

So I built a tool that does the opposite: a tiny number of hand-verified rules, each tied to a specific entry, evaluated against the wallet you paste. No signature, no signup, no server-side address logging — just RPC calls fanned out from the browser. And because the same rule registry feeds an MCP tool, any LLM client (Claude Desktop, Cursor, etc.) can call it directly without scraping the site.

The browser tool

Live at web3-discover.vercel.app/tools/eligibility.

Paste an EVM and/or Solana address. The page evaluates 14 rules against 42 curated entries and buckets the results into:

✅ Likely eligible — rule passes (e.g. eth_getTransactionCount on Linea ≥ 1, or you hold ≥ 1 PENDLE)
🟡 Keep farming — partial: you've started but not crossed the threshold (e.g. 2 Arbitrum tx when 5 are needed for Reya / Ostium)
⏭ Not relevant — rule fails outright
🔍 Manual check — entry lives on a chain we can't reach from the browser (Monad, MegaETH, Hyperliquid, Sui-based) or has off-chain criteria (KYC, Discord, Galxe quests)

Try vitalik.eth + a public Solana wallet — resolves in 2-5 seconds, 9 eligible at the time of writing.

How the browser side stays cheap

Every entry-page CTA deep-links to /tools/eligibility?focus=<slug>. A banner at the top of the results page names the entry the visitor came from, then after evaluation the matching card is scrolled into view and pulse-highlighted with a CSS keyframe. This costs zero extra requests — the focus logic is pure DOM-after-render.

Total RPC requests = one batched JSON-RPC POST per EVM chain (so 6 max for an EVM address) plus per-mint Solana calls. Each batch bundles eth_getTransactionCount + every eth_call(balanceOf) we need for that chain, so adding more rules on Ethereum costs zero additional requests.

The MCP tool

Same logic, exposed at https://web3-discover.vercel.app/api/mcp as the fourth tool of the web3-discover MCP server.

curl -s -X POST https://web3-discover.vercel.app/api/mcp \
  -H 'content-type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 7,
    "method": "tools/call",
    "params": {
      "name": "check_eligibility",
      "arguments": { "evm": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" }
    }
  }'

Returns the same verdict shape — eligible[], partial[], manual[], unavailable[], skip[] — but as machine-readable JSON each LLM client can render however it likes:

{
  "inputs": { "evm": "0xd8dA…6045", "sol": null },
  "rulesEvaluated": 14,
  "totalTracked": 42,
  "counts": {
    "eligible": 9,
    "partial": 0,
    "skip": 5,
    "manual": 28,
    "unavailable": 0
  },
  "eligible": [
    {
      "slug": "base-coinbase-l2",
      "project": "Base",
      "chain": "Base (Coinbase L2)",
      "verdictDetail": "70 tx on Base (≥ 1 required)",
      "officialUrl": "https://base.org"
    }
  ]
}

Drop-in for Claude Desktop / Cursor

{
  "mcpServers": {
    "web3-discover": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://web3-discover.vercel.app/api/mcp"]
    }
  }
}

Then ask: "What airdrops am I eligible for? My wallet is 0x…" and the model calls check_eligibility directly. No scraping, no flaky HTML parsing.

The one-file pattern that keeps both surfaces honest

Two surfaces means two ways for the rules to drift. The fix is one source of truth:

src/data/
  eligibility-rules.json   # source of truth
  eligibility-rules.ts     # typed wrapper for the Astro page

And during prebuild:

// scripts/build-airdrops-snapshot.mjs
fs.copyFileSync(
  path.join(ROOT, 'src/data/eligibility-rules.json'),
  path.join(ROOT, 'api/_eligibility-rules.json'),
);

The MCP serverless function reads the JSON at cold start; the Astro page imports the typed .ts wrapper. Same data, two consumers, zero drift.

Why this matters as a wedge

Most directory sites optimise for "discover something new". This optimises for the moment after you've already heard of a project: "do I, this wallet I'm holding, actually need to act on this?" That question doesn't compete with newsletters or Twitter — it complements them.

And exposing the same logic over MCP means the directory gets pulled into LLM chats as the user is making decisions, not after the fact. The two surfaces feed each other: the browser tool drives organic / shared discovery; the MCP tool drives in-chat utility when a user has Claude open anyway.

Try it

Browser: web3-discover.vercel.app/tools/eligibility
MCP: https://web3-discover.vercel.app/api/mcp — JSON-RPC 2.0, tools/list returns four tools
Source: the curated entries themselves live in a separate CC0 repo at SolvoHQ/web3-discover-data, auto-refreshed daily

Open to pull requests adding new rules — each one is ~5 lines in the JSON registry.

I shipped an MCP server for crypto airdrops — install in 1 config line

Weston G — Mon, 11 May 2026 14:13:59 +0000

I shipped a tiny MCP server last week that turns a curated crypto airdrop directory into 3 tools any LLM client (Claude Desktop, Cursor, Continue, Windsurf) can call directly.

This post is the install snippet + a screenshot of it returning real data — so you can decide in 30 seconds whether it's worth one config line.

What you get

Three tools, no signup, no API key, no rate limit:

list_active_airdrops(chain?, risk?, sort_by?, limit?) — browse 32 vetted active airdrops, filter by chain (Solana, Base, Ethereum…) or risk level (verified / unverified)
get_airdrop(slug) — full details for one campaign: action steps, weekly effort, cost floor, risk notes, official URL
check_wallet(addr) — paste an EVM or Solana address, fan out to 7 public RPCs (Ethereum, Base, Linea, Arbitrum, Polygon, BSC, Solana), and surface every tracked airdrop whose chain you've already touched

Hosted, JSON-RPC 2.0 over HTTP, CORS-open. Endpoint: https://web3-discover.vercel.app/api/mcp.

Install in Claude Desktop or Cursor

Add this one block to your MCP config:

{
  "mcpServers": {
    "web3-discover": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://web3-discover.vercel.app/api/mcp"]
    }
  }
}

That's it. Restart your client. Ask: "What active airdrops can I farm on Solana this week with under $100 capital?"

What it returns (live)

Here's the actual JSON-RPC 2.0 response from a real tools/call against the live endpoint — pulled the moment I wrote this article:

Verify it yourself:

curl -s -X POST https://web3-discover.vercel.app/api/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_active_airdrops","arguments":{"limit":3,"sort_by":"added"}}}'

You get back structured entries: slug, project, chain, blurb, deadline, effort estimate, cost floor, risk flag (verified means the team has publicly confirmed TGE plans; unverified means speculative), and the official URL.

Why this is interesting (beyond "another MCP server")

I run a curated airdrop directory at web3-discover.vercel.app. Every entry is hand-vetted, scam-filtered, and re-checked weekly. The web surface works well for humans who already know about it — but most retail farmers ask LLMs first now.

So I exposed the directory as MCP tools. Three things this unlocks that the web UI alone can't:

Natural-language filtering. "What's verified-only, ongoing, costs gas only?" — the LLM picks list_active_airdrops, filters by risk=verified, sorts by deadline, narrates the result.
Wallet-aware advice. check_wallet returns which chains your wallet has touched plus the entries on those chains. The LLM combines that with your stated risk tolerance and tells you what to prioritize, not just what exists.
Composition with other MCP servers. If you've got a wallet MCP server + this one, the LLM can chain "what airdrops am I close to qualifying for, given my actual on-chain history?"

No tracking. The directory has no signup. The check_wallet tool just reads from public RPCs — no address is logged.

Why hosted, not stdio?

Most MCP servers ship as npx some-package that runs on your machine. I went hosted (HTTP transport via mcp-remote bridge) for one reason: the data changes weekly. A stdio package would have to re-download the directory or hit an API anyway. Hosting it means the data refreshes when I do a freshness sweep, not when you remember to npm update.

Tradeoff: you trust me to keep the endpoint up. I run a freshness sweep weekly (the directory page shows a "last verified" date per entry). If you'd rather self-host, the source is MIT and the MCP handler is a single ~250-line file (api/mcp.mjs).

What works, what doesn't, what's next

Works today:

All 3 tools verified end-to-end on Claude Desktop and Cursor with mcp-remote
32 active entries, 7-chain wallet check
No auth, no rate limit at current load

Doesn't yet:

No eligibility scoring — check_wallet is a presence check, not an "are you actually eligible?" check. Most airdrops have additional criteria (volume, tx count, NFT holdings) that I'd need to wire per-entry.
No notifications — if a deadline shifts or an entry gets removed, you'll only see it next time you query.

Next:

subscribe_deadlines(addr) returning an iCalendar feed so deadlines land in your calendar
Per-entry eligibility checks where the airdrop has a public scoring API
Adding the directory as an MCP resource (not just tools) so LLMs can browse without explicit calls

Try it

Drop the config block above into Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS) or Cursor (Settings → MCP). Ask "What airdrops are worth farming this week?"

If it's useful, the directory itself lives at web3-discover.vercel.app — same data, human-shaped.

If something breaks or you want a tool added, open an issue.

Built with Astro + Vercel serverless. Three days, ~250 LOC for the MCP handler. The hardest part wasn't the code — it was making sure the underlying directory data was actually honest. (No paid placements pretending to be listings.)

Building a daily-refreshed, scam-flagged airdrop directory with Astro + IndexNow + GoatCounter

Weston G — Mon, 11 May 2026 12:57:42 +0000

I've been building web3-discover — a hand-vetted, scam-flagged directory of currently-claimable web3 airdrops — and I wanted to share the static-site + agent-driven pipeline behind it, because the architecture is unusual: there's no backend, no database, no editor login. Everything is git-tracked Markdown, every deploy is a static build, and content is refreshed daily by an autonomous workflow rather than human curators.

Live URL: https://web3-discover.vercel.app

The wedge (why "fewer entries" is the feature)

The crypto-airdrop site space is dominated by SEO-juiced aggregators listing 300+ "airdrops" — most of which are expired, scams, or paid placements pretending to be listings. The wedge is the opposite: ~30 hand-vetted entries, each with a concrete action, cost floor, deadline, risk flag, and a lastChecked date. If we can't verify an entry, we drop it.

The stack (and why each piece)

Astro 5 — chosen specifically because content collections give you a typed schema for markdown frontmatter, and the output is dead-static HTML. No client JS in the critical path. Every entry page is a 9KB document.

// src/content/config.ts
const airdrops = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    chain: z.enum(['Ethereum', 'Solana', 'Base', 'Arbitrum', /* ... */]),
    action: z.string(),
    costFloor: z.string(),     // "$0", "$50", "gas-only"
    deadline: z.string(),      // ISO date or "ongoing"
    riskFlag: z.enum(['verified', 'unverified', 'suspected-scam']),
    lastChecked: z.string(),
    officialUrl: z.string().url(),
    addedOn: z.string(),
  })
});

When an entry breaks schema, the build fails loudly. That's the whole content-CI layer — no DB migrations to run.

Vercel for hosting — vercel --prod from CLI. Free tier handles plenty of traffic. Sitemap pinned to @astrojs/sitemap@3.2.1 because newer versions broke our Astro 5 build chain.

JSON-LD for structured data — Organization + WebSite on every page (in Base.astro layout), ItemList on the airdrops index page, Article schema on each entry page (with datePublished from frontmatter addedOn, publisher logo, mainEntityOfPage, dateModified sourced from lastChecked). Verified live via curl — the JSON parses cleanly with python3 -m json.tool.

RSS at /rss.xml using @astrojs/rss. Each item carries the full action/effort/cost/deadline/risk block — readable in a feed reader without clicking through. GUIDs are entry URLs (canonical).

IndexNow for crawler push notifications — three endpoints pinged on every content update:

https://api.indexnow.org/indexnow → 202
https://www.bing.com/indexnow → 200
https://yandex.com/indexnow → 202 ({"success":true})

The verification key is a file at https://web3-discover.vercel.app/<hex>.txt. Don't delete that file — Bing re-validates on subsequent pings. I learned that the hard way trying to "clean up" the public dir.

GoatCounter for analytics. Privacy-friendly, no cookies, no consent banner needed. Embed is a 5-line <script>. The dashboard lives at <workspace>.goatcounter.com. Counts pageviews + referrers, exactly what I need to see whether a distribution channel actually works.

The agent-refresh loop (the unusual part)

The site is maintained by an autonomous workflow (Claude Code agent ticks running on a 30-second heartbeat). Every wake the agent reads the current Markdown entries, checks lastChecked against Date.now() - 7d, and queues stale entries for re-verification:

Fetch the project's official Twitter or docs page.
Re-confirm the deadline string.
Re-confirm the action steps still match what the project requires.
If anything has changed: update the frontmatter, bump lastChecked.
If the project has TGE'd (token generation event passed) or the airdrop is over: remove the entry from src/content/airdrops/ entirely.
Re-build, redeploy, ping IndexNow.

In the first sweep (22 → 32 entries) the agent caught three of my own false assumptions: Monad / MegaETH / Plasma are post-TGE, not pre-TGE. Sonic Labs Season 2 ended November 2025 — dropped. The point isn't that the agent is smarter than me; it's that running the verification loop on a 7-day cycle instead of "when I feel like it" surfaces drift fast.

Per-entry conversion pivot (a real lesson)

Initial v1 had a /tools/swap page with Jupiter Plugin (Solana) and Jumper deeplink (EVM) as a monetization path — integrator-fees on swaps. Every airdrop entry page had a "Sell when claimed" CTA pointing at /tools/swap?token=X&chain=Y.

The bug: the URL params were read by NO code. Every sell-CTA from 32 entry pages dumped users on a USDC-default swap. The single biggest pre-traffic conversion gap, sitting in production for ~24 hours before I caught it.

Fix: a slug→target registry mapping each entry's chain + symbol to a concrete token address. For Solana, that's the SPL mint passed into Jupiter.formProps.initialInputMint. For EVM, ?fromChain=…&fromToken=… on the Jumper deeplink. 12 verified Solana mints + 20 EVM token addresses are now hardcoded into a TypeScript const. Building this took ~25 minutes. The fact that an agent let it ship undetected for 24h is the cautionary tale — verification-before-completion is non-negotiable when your reviewer-of-last-resort is the same process that shipped the change.

Guides pillar (SEO + risk-awareness)

Three evergreen guides live at /guides/scams, /guides/taxes, /guides/wallet-hygiene. Every airdrop entry internally links to two risk-matched guides (a suspected-scam entry links to /guides/scams; a high-deadline entry links to /guides/wallet-hygiene). Indexable surface went from 35 to 39 URLs, every entry page gains internal-link equity.

The choice was deliberate: I'd rather have 3 deep guides than 30 shallow ones. Crawlers reward dwell time, and a 1500-word scams guide with concrete patterns ("if the claim URL doesn't match the project's official Twitter pinned tweet, walk away") does that better than 30x 200-word listicles.

What I'd tell anyone building in this category

Anti-features are the differentiation. "No wallet connect, no claim links, no paid listings" is not a copy gimmick — it's the reason I trust my own site, and it's the reason a user might. The competitive moat in any junk-flooded category is being the one that says "no" to the easy money.
Static + agent-refresh > headless CMS. A headless CMS gives editors a UI. I don't have editors. The git tree is the database; the deploy is the publish step; the agent is the editor. If your contributor list is 1, this collapses to dramatically less infra than "Strapi + Postgres + worker queue".
JSON-LD is free SEO money. Article schema with dateModified sourced from lastChecked tells Google "this is a fresh page". Cost: 12 lines per layout file. Benefit: every entry shows the freshness signal in SERPs.
IndexNow ≠ Google Search Console. GSC verification is an interactive OAuth flow with no zero-account path I could find. IndexNow accepts a static key file and gets you Bing + Yandex (the latter is non-trivial for crypto SEO, where Russian and Eastern European traffic is real). Don't burn hours on GSC; ship IndexNow and move on.

Try it

Site: https://web3-discover.vercel.app — currently 32 active entries, deadline-sorted, refreshed today.

If you spot an entry that's wrong, broken, or scammy I should flag harder — open an issue at the repo (linked in the footer). The whole content tree is public Markdown — feedback round-trips fast.

Tags: #astro, #web3, #staticsite, #seo, #crypto