DEV Community: tine

I ran the same text through two tokenizers. They disagreed by 20%.

tine — Tue, 18 Aug 2026 10:26:27 +0000

SpendGuard 文章 03 — Your cost estimates are 20% off

目标平台：dev.to → 拆 5 条 X thread（自动发）
定位：文章 01（定价杠杆）02（账单实测）之后的「测量误差」篇——成本工具的隐性错误
数据：tiktoken 本地实测（同文本 cl100k 2,496 vs o200k 1,949）

I ran the same text through two tokenizers. They disagreed by 20%.

Here's a small experiment you can repeat in five minutes. Take one Chinese paragraph, run it through two tokenizers, and compare:

cl100k_base (the encoder behind GPT-3.5/4-class models): 2,496 tokens
o200k_base (GPT-4o class): 1,949 tokens

Same string. Same meaning. 20% apart. Neither is "wrong" — tokenizers are just vocabularies, and different vocabularies cut the same text at different places.

The problem is what happens when you estimate cost with the wrong one.

DeepSeek estimates are structurally off

DeepSeek uses its own vocabulary, and it isn't published the way OpenAI's is. So every cost tool that claims to estimate DeepSeek usage is approximating with a tiktoken encoder that was trained on different data. The error isn't a rounding issue. It's a structural one, in a known direction, and it varies by language: Chinese text gets hit harder than English because the vocab match is worse.

I've seen dashboards show "estimated tokens" for DeepSeek calls that are off by 20-30%. Nobody flags it. The number just looks authoritative.

The fix costs nothing

Every DeepSeek API response contains the real token counts. input_tokens, output_tokens, and for cached calls, the cache hit tokens, all returned in the response object.

Read them. Stop estimating. If your cost tool shows a number that isn't coming from the actual API response, it's a guess wearing a dashboard.

Why this matters more than it sounds

Cost optimization amplifies measurement error. The 30x cache lever I wrote about last week works on cache hit tokens — if your tool miscounts the input side by 20%, your cache hit rate is also wrong by 20%, and every optimization decision you make inherits that error. You can't manage what you're measuring wrong.

What this means for your stack

If you track LLM costs, log the token fields from responses, not estimates
If a tool claims DeepSeek support, ask what tokenizer it uses
For Chinese-heavy workloads, distrust any estimate more than usual

That last point is why SpendGuard reads real response counts instead of estimating: cache hit rate as a first-class metric, per-model and per-project breakdowns, and no guesswork in the numbers. Open source, local-first: github.com/caresotin/spendguard.

Check your own numbers this week. If your cost tool can't show you where they come from, that's your answer.

I watched my LLM bill for 30 days. The 30x cache lever is real.

tine — Tue, 18 Aug 2026 08:14:31 +0000

SpendGuard 文章 02 — I watched my LLM bill for 30 days

目标平台：dev.to → 拆 5 条 X thread（自动发）
定位：文章 01（30× cache 杠杆）的「实测证据篇」——个人实测 + 诚实结论
风格：去 AI 味（少破折号、少对称排比、真人口气、具体数字）

I watched my LLM bill for 30 days. The 30x cache lever is real.

Last week I wrote about DeepSeek V4's pricing mechanic that nobody talks about: cached input tokens cost $0.007 per million, uncached cost $0.22. Same tokens, 31x apart. A few people asked the obvious follow-up: "okay, but does it actually matter in practice?"

So I did the boring thing. I logged my own LLM usage for 30 days. Every session, every cron job, every API call. Here's what the numbers said.

The bill is tiny. That's the point.

My total spend: about $0.90 a month. Ten sessions a day, twenty agent steps each, DeepSeek flash off-peak. At that scale, nobody needs a cost tool. If your monthly bill is under $10, the best cost optimization is to stop thinking about it.

The interesting part is what the breakdown looked like, because that's where the levers show up.

One pattern ate 80% of the cost

My agent sessions resend the whole conversation history on every step. A 20-step session with a 10K-token history pays for that history 20 times. That's ~10.5K input tokens per step on average, and whether those tokens hit cache decides the bill:

cache hit: $0.007/M -> a 100K-token context costs about $0.004
cache miss: $0.22/M -> the same context costs $0.025

Six times more. On a 50-calls-a-day RAG workload, that difference is the difference between $6/month and $38/month. The cache hit rate is not a technical detail. It's the whole bill.

What kills cache hits: anything that changes the prompt prefix. A timestamp in the system prompt, a reordered tool list, an auto-updating "today is" line. One moving byte invalidates the entire prefix cache.

My tokenizer measurements were off by 20%

I took the same Chinese text and ran it through two tokenizers. One counted 2,496 tokens. The other counted 1,949. Same string, 20% apart. DeepSeek uses its own vocabulary, so anything you estimate with tiktoken is an approximation with a known error direction.

The fix is free: if you're reading real API responses, the exact token counts are in the response. Use them. Stop estimating.

Peak pricing doubles silently

Off-peak vs peak is a 2x multiplier on everything. I moved my cron jobs to off-peak hours and the batch bill halved. It's one config change.

What I actually changed

System prompt is now frozen. No timestamps, no dynamic parts. One moving byte in the prefix invalidates the whole cache, and it's the cheapest fix I found.
Cron jobs run off-peak. Same work, half the price.
Retries capped at 2 with backoff. A retry storm triples the bill and almost never fixes the prompt that caused it.
I stopped estimating tokens. Every aggregator reads the real counts from API responses.

The honest conclusion

Individuals don't need a cost tool. Teams running production workloads with five-figure bills do. If your bill is that big, the cache hit rate is your first audit point, and most dashboards don't even show it. That gap is why I'm building SpendGuard: cache hit rate as a first-class metric, pricing checked against the official page, per-model and per-project breakdowns. Open source, local-first: github.com/caresotin/spendguard.

Your first move costs nothing: check your cache hit rate this week. If you can't see it, that's your answer.

DeepSeek V4 pricing: the 30x cache lever your cost tool isn't showing you

tine — Tue, 18 Aug 2026 03:28:22 +0000

DeepSeek V4 pricing: the 30x cache lever your cost tool isn't showing you

内容管线 #1 ｜母题：热点/避坑（DeepSeek V4 定价）｜目标平台：dev.to（caresodev）→ 后续 X/HN 分发
SEO 关键词：deepseek v4 pricing, deepseek cache pricing, llm cost, deepseek tokenizer
CTA：SpendGuard 预登记（落地页部署后换链接；当前引 GitHub 仓库）

When DeepSeek shipped V4 pricing, one number got almost no attention. Input tokens with a cache hit cost $0.007 per million. Without a cache hit, the same input costs $0.22 per million. That's a 31x difference on the same tokens.

If you run agent loops, cron jobs, or anything with a repeating prompt against DeepSeek, this single mechanic decides whether your monthly bill is a rounding error or a surprise.

The actual V4 prices

Verified from the official pricing page (2026-08):

1M tokens, USD	deepseek-v4-flash	deepseek-v4-pro
Input, cache hit	$0.007	$0.022
Input, cache miss	$0.22	$0.66
Output	$0.66	$1.98

All prices double during peak hours. Output is the most expensive line item on every row.

What cache pricing means in practice

Every API call has a prefix. Same prefix, same order, and the provider can serve most of it from cache. Three patterns dominate real bills:

Agent loops. Every step resends the whole conversation. A 20-step session with a 10K-token history pays for that 10K prefix 20 times. Cache hit makes each resend cost $0.007/M instead of $0.22/M. No cache, and the same session costs 31x more for the input portion.

Cron and batch jobs. Deterministic prompts with a stable system prompt are the easiest cache wins in existence.

RAG with a fixed system prompt. The retrieved chunks change, but the instructions don't. A stable instruction prefix keeps the cache alive.

The catch: any change to the prefix kills the cache for the whole request. A timestamp injected into the system prompt, a reordered context block, even a trailing newline in the wrong place. Cache is fragile by design, and it's invisible unless you measure it.

Why generic cost tools get DeepSeek wrong

Two structural problems, both measurable.

Pricing tables updated by community PRs. LiteLLM and similar tools track prices from community submissions. When DeepSeek changes pricing, there's a window between the change and the merged PR where every estimate is wrong. V4's cache-hit tier is exactly the kind of change that breaks old estimates, and it's the tier that matters most.

Tokenizer mismatch. Most tools estimate tokens with OpenAI's tiktoken. DeepSeek ships its own tokenizer. I measured the same Chinese text with both: cl100k_base counts 2,496 tokens, o200k_base counts 1,949. That's a 20% spread on the same string. Estimate a bill with the wrong tokenizer and the numbers are fiction.

What actually cuts a DeepSeek bill

Keep prefixes stable. Same system prompt, same ordering, no timestamps. Cache hit rate is the single biggest lever on the bill.
Run batch jobs off-peak. Prices double in peak hours. Nightly processing at 3am is half price for the same work.
Cap retries. A retry storm multiplies the bill 3x and produces nothing.
Watch output. Output tokens are the most expensive row on the table. Long generations are the real spend.

Real numbers from my own usage

A simple Q&A (2K input + 1K output) costs $0.0011. A 100K-token context call costs $0.0253, or $0.0040 if the prefix caches (84% off). Individual requests are cheap. Bills explode from repetition: agent loops, cron, retries, context you keep resending. None of it shows up in a per-request view.

The gap

The popular observability tools show total spend. Almost none show cache hit rate as a first-class metric, and that's the number that actually determines DeepSeek cost. I'm building SpendGuard to fix exactly this: pricing checked against the official page instead of community PRs, cache hit rate visibility, off-peak scheduling suggestions, and cost reports that don't need a spreadsheet. Pre-registration opens soon, watch the repo to get notified.

Data verified against api-docs.deepseek.com pricing page, 2026-08-18. Prices change; check the official page before making decisions.

I built a local CLI to audit my LLM bill, and it caught a 6.9% overcharge

tine — Sun, 16 Aug 2026 14:33:34 +0000

Last month my OpenAI bill didn't match my own logs. Cached tokens were being
billed at the full uncached rate. 6.9% over a month. The observability tools I
pay for showed me what I spent, but not what I was overcharged.

So I built SpendGuard, a local-first CLI for LLM cost. It runs entirely on your
machine.

What it does:

generates independent receipts (versioned pricing, cache hit/miss dual pricing) and checks them against your provider invoice
runs as a local proxy with a hard budget cutoff (returns 429 instead of letting the bill climb)
suggests cheaper models and more caching, which cut my test case about 79%

Why local-first: your API keys and call data never leave your machine. You can
read the code, and the code checks your bill. No accounts, no telemetry.

Try it:

pip install spendguard
spendguard audit your-bill.csv

Plain Python, no dependencies (tiktoken is optional). MIT, 13 unit tests, CI on
GitHub Actions.

Repo: https://github.com/caresotin/spendguard

I'm sure there are edge cases I've missed (retries, streaming, batch calls). If
you use the OpenAI or Anthropic API, I'd like to know what breaks.

opensource, ai, python, productivity

Building a Zero-Dependency MCP Server for the Timestamp Bugs LLMs Get Wrong

tine — Sat, 08 Aug 2026 12:26:49 +0000

Building a Zero-Dependency MCP Server for the Timestamp Bugs LLMs Get Wrong

This is a build log for tsforge-mcp — a pure Node.js MCP server with 16 timestamp/date tools. No npm dependencies, dual transport (stdio + Streamable HTTP). Repo: https://github.com/caresotin/tsforge-mcp

The problem

Most MCP time servers give you get_current_time and convert_time. Fine — but those are also the two things you can just ask the model directly. The real failures show up at the edges:

Cron next fire: 0 0 29 2 * (Feb 29) must skip to 2028, not "next year".
Excel serial 60: 60 decodes to 1900-02-29 — a date that never existed (the famous 1900 leap-year bug).
ISO-8601 week: 2016-01-01 is week 53 of 2015, not week 1.
DST-aware tz: Asia/Shanghai → America/New_York is not a fixed offset.
SQL dialects: UNIX_TIMESTAMP() vs TO_TIMESTAMP() vs strftime() vs DATEADD — all different.

Every one of those, asked of a frontier model, returns a confident wrong answer. So I extracted boundary-correct algorithms into tools.

Architecture (no dependencies)

One codebase, two transports:

stdio for Claude Desktop / local MCP clients.
Streamable HTTP for ChatGPT Apps SDK / remote clients.

Everything is Node.js built-ins: JSON-RPC 2.0 framing, HTTP session management, and the algorithms in a single module.

// cron_next: handle the 29 Feb edge case
function cronNext(expr, n = 1) {
  const sched = parseCron(expr);
  const out = [];
  let cur = new Date();
  while (out.length < n) {
    cur = nextMatch(sched, cur);
    if (cur) out.push(cur);
    cur = new Date(cur.getTime() + 1000);
  }
  return out;
}

The Excel bug is just a constant offset with a conditional:

function excelSerialToDate(s) {
  // Excel wrongly treats 1900 as a leap year; serial 60 = fake Feb 29
  const base = new Date(Date.UTC(1899, 11, 30));
  const d = new Date(base.getTime() + (s - (s > 60 ? 1 : 0)) * 86400000);
  return d;
}

Why this helps the web side

The same engine powers a free converter at https://gotimestamp.com/sql-timestamp-converter.html, and we documented the per-dialect gotchas as language guides:

MySQL: https://gotimestamp.com/timestamp/mysql
PostgreSQL: https://gotimestamp.com/timestamp/postgresql
SQLite: https://gotimestamp.com/timestamp/sqlite
Node.js: https://gotimestamp.com/timestamp/nodejs

If you're shipping MCP servers, what edge cases have you had to hand-code? Curious whether others hit the same date/time boundary traps.

Repo: https://github.com/caresotin/tsforge-mcp

前端用 Intl 展示时间戳，ISO8601 规范化，附速查页

tine — Mon, 03 Aug 2026 20:38:29 +0000

前端用 Intl 展示时间戳，ISO8601 规范化，附速查页

作者是前端 / Intl / ISO8601 方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。

背景

做前端 / Intl / ISO8601 时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。

我踩过的坑（举几个）

秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。
时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。
2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。
夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。

我顺手做的东西

转换速查页：https://gotimestamp.com/timestamp/typescript
相关语言页：https://gotimestamp.com/timestamp/go
开源 MCP：https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。

小结

时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。

100 城时区页给跨区调度当速查，DST 自动算

tine — Mon, 03 Aug 2026 20:33:10 +0000

100 城时区页给跨区调度当速查，DST 自动算

作者是数据管道 / 跨时区调度方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。

背景

做数据管道 / 跨时区调度时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。

我踩过的坑（举几个）

秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。
时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。
2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。
夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。

我顺手做的东西

转换速查页：https://gotimestamp.com/timezone/new-york
相关语言页：https://gotimestamp.com/timezone/london
开源 MCP：https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。

小结

时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。

Node Date 的 epoch 毫秒坑 + 用 MCP 把转换塞进 AI 流

tine — Mon, 03 Aug 2026 20:33:09 +0000

Node Date 的 epoch 毫秒坑 + 用 MCP 把转换塞进 AI 流

作者是 Node.js / JS 时间方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。

背景

做 Node.js / JS 时间时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。

我踩过的坑（举几个）

秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。
时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。
2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。
夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。

我顺手做的东西

转换速查页：https://gotimestamp.com/timestamp/nodejs
相关语言页：https://gotimestamp.com/timestamp/javascript
开源 MCP：https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。

小结

时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。

SQL 里时间戳的 4 个真坑 + 用 tsforge-mcp 在 LLM 里直接算

tine — Mon, 03 Aug 2026 20:26:07 +0000

SQL 里时间戳的 4 个真坑 + 用 tsforge-mcp 在 LLM 里直接算

作者是 DBA / SQL 时间函数方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。

背景

做 DBA / SQL 时间函数时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。

我踩过的坑（举几个）

秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。
时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。
2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。
夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。

我顺手做的东西

转换速查页：https://gotimestamp.com/timestamp/mysql
相关语言页：https://gotimestamp.com/timestamp/postgresql
开源 MCP：https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。

小结

时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。

写 Python 时被 datetime 时区坑过，顺手做了转换页 + 开源 MCP

tine — Mon, 03 Aug 2026 20:26:05 +0000

写 Python 时被 datetime 时区坑过，顺手做了转换页 + 开源 MCP

作者是 Python 后端 / datetime 时区坑方向的开发者。这篇不是广告，是踩坑记录 + 顺手做的工具。

背景

做 Python 后端 / datetime 时区坑时，时间戳转换是最常被低估的雷区。16 个时间戳工具(Unix 转换/时区/ISO8601/Cron/Duration…) 已覆盖日常；但每个语言/框架的坑都不一样，所以又补了 30 个语言/框架时间戳页(python/javascript/java/sql/…)，每页含 6 个真实坑。

我踩过的坑（举几个）

秒 vs 毫秒：前端 Date.now() 是毫秒，后端常存秒，混用差 1000 倍。
时区不是字符串：存 UTC、展示本地，别把本地时间当 UTC 落库。
2038 问题：32 位系统 time_t 在 2038-01-19 溢出，老系统要提前查。
夏令时：一年有两次重复/缺失的本地时间，跨区调度尤其坑。

我顺手做的东西

转换速查页：https://gotimestamp.com/timestamp/python
相关语言页：https://gotimestamp.com/timestamp/mysql
开源 MCP：https://github.com/caresotin/tsforge-mcp —— 把时间戳转换/校验直接接进 LLM 工作流，不用手算。

小结

时间戳没那么简单，但工具到位就省心。上面都是免费、开源、可直接用的，希望对同样踩坑的人有帮助。