DEV Community: CodeLong888

An OpenAI flagship lost 38% of its daily usage in three days — then set three straight all-time highs

CodeLong888 — Sun, 16 Aug 2026 01:41:04 +0000

Everyone publishes AI model leaderboards. Almost nobody publishes the day-level curve — and the
curve is where the actual story is.

At whatstrending.ai we snapshot every model's daily request count
from OpenRouter's usage feed into a database, once a day, INSERT OR IGNORE — a row can never be
revised after the fact. We're 78 days in. Here is what openai/gpt-5.6-luna did over the last two
weeks:

Date	Requests/day
Aug 04	162.9M
Aug 05	180.8M
Aug 06	193.8M
Aug 07	210.8M
Aug 08	222.5M ← peak
Aug 09	209.6M
Aug 10	171.6M
Aug 11	137.3M ← floor: −38.3% off peak in 3 days
Aug 12	143.2M
Aug 13	157.3M
Aug 14	231.8M ← new all-time high, +47.4% in one day
Aug 15	237.3M
Aug 16	243.5M ← third consecutive all-time high

A flagship model shed more than a third of its daily traffic in three days, then won all of it
back — and more — inside the same week. Three consecutive days above the old peak as of Aug 16.

Why this isn't a data artifact

Three checks, run before writing this:

The whole table didn't move. The all-model daily total went 3.56B → 3.66B (+2.8%) on the day luna jumped 47%, and 3.70B → 3.73B (+0.8%) on Aug 16. Luna's share moved: roughly 4.4% → 6.5%.
Peers didn't dip with it. During luna's drawdown (Aug 09–11), deepseek/deepseek-v4-flash-0731 and tencent/hy3 were setting their own highs on the same days — so this is not a provider-wide trailing-edge reporting droop.
Rows are frozen at write time. Aug 14 read 231.8M on the day we collected it and reads 231.8M today. Nothing was backfilled or revised.

Why it matters

Monthly aggregates — which is what every public ranking shows — would have flattened this entire
event into "usage grew". The day-level series shows real flagship usage is far more volatile than
anything the leaderboards suggest: a −38% drawdown and a full recovery to new highs fit inside eight
days. If you're making routing, capacity, or "which model is winning" decisions off monthly numbers,
you're averaging away the actual signal.

The live, daily-updated version of this curve is here:
https://whatstrending.ai/models

Method: daily snapshot of OpenRouter per-day request counts, 100 models/day, 78 days and counting,
stored append-only (INSERT OR IGNORE) in Cloudflare D1.

We ping 2,587 vibe-coded apps every 6 hours. The 'AI apps die fast' narrative isn't holding up

CodeLong888 — Sat, 15 Aug 2026 07:57:35 +0000

Everyone "knows" vibe-coded apps are abandoned within weeks. Someone ships a weekend project with Cursor or Lovable, tweets about it, and the domain quietly dies when the trial credits run out.

I run VibeKing, a directory of products built with AI coding tools. A couple of weeks ago I added a liveness engine: every product in the catalogue gets an HTTP check every 6 hours, cycling through all of them continuously. No sampling, no estimates — every single URL, checked repeatedly, with failure counts.

Here's what the data actually says so far.

93.1% of them are up

Of 2,587 approved products:

Status	Count	Share
Live	2,408	93.1%
At risk (intermittent failures)	178	6.9%
Confirmed dead	0	0%

"At risk" means the checker has caught the site failing on recent checks but it hasn't sustained enough consecutive failures to be declared dead. "Dead" requires repeated failures over multiple checks — a bar nothing has cleared yet in the observation window.

Two honest caveats. First, this window is short — the engine has been running since early August, so this measures current availability, not long-term survival. The interesting numbers arrive in 6-12 months, and I'll publish those too, whichever way they cut. Second, there's a survivorship component: some products died before ever being catalogued, and those deaths aren't in the denominator. What this data can say is narrower but still useful: of the vibe-coded products visible enough to be catalogued, 93% are up right now — the wasteland narrative describes launches that never got noticed, not the ones that did.

What vibe coders build: tools for other vibe coders

Category distribution of the same 2,587:

Category	Count	Share
AI Coding	691	26.7%
Dev Tools	400	15.5%
Marketing	316	12.2%
SaaS	237	9.2%
Productivity	178	6.9%
Design	161	6.2%

42% of AI-built products are developer tooling. The community's biggest output category is tools for itself — the classic gold-rush-shovels pattern, visible in the data.

.com still wins, but the builder TLDs are a third of everything

TLD	Share
.com	46.7%
.ai	11.4%
.app	10.1%
.io	6.0%
.dev	3.0%

.ai + .app + .io + .dev together are 30.5% — nearly a third of vibe-coded products launch on a "builder" TLD. And still, when makers want to be taken seriously, they buy the .com.

Method, briefly

Catalogue: 2,587 approved products on vibeking.fun, collected from launch platforms and direct submissions
Liveness: HTTP checks in rotating batches every 6 hours via Cloudflare Workers cron; a product is "at risk" after repeated recent failures and "dead" only after sustained consecutive failures
Anti-bot handling: sites that block automated checks (401/403/405/429) count as alive — refusing bots is not being down
Nothing here is estimated. Counts are from the production database, queried today.

I'll re-run this in a few months when the longitudinal picture exists. If you want your product in the tracked set: vibeking.fun/submit — free, no signup wall for browsing, and the checker will keep an eye on your uptime for you.

Your hreflang says English-only. Does your language switcher agree?

CodeLong888 — Thu, 13 Aug 2026 19:51:06 +0000

I run a maintenance sweep over my own site every day. Yesterday it found 1,474 dead internal links that had been sitting there in plain sight, on 737 pages, and every automated check I had was green.

The cause is a bug class I have not seen written up, so here it is.

Two places encode "which languages does this page have"

A partially translated site has, whether you planned it or not, two independent answers to the question does this page exist in Chinese?

The <link rel="alternate" hreflang="..."> tags in <head> — what you tell crawlers.
The EN / 简 / 繁 buttons in your nav — what you tell humans.

Mine disagreed. The hreflang side was correct: a few page families on my site are English-only, so those pages emit an English self-reference and nothing else. There is even a comment in the source explaining why, because declaring an alternate that 404s poisons the whole hreflang cluster.

The nav switcher never got that memo. It was doing the naive thing:

// every page, unconditionally
`<a href="${basePath}">EN</a>
 <a href="/zh-cn${basePath}">简</a>
 <a href="/zh-tw${basePath}">繁</a>`

So on every English-only page, the two Chinese buttons pointed at URLs that do not exist. Click 简 on the API docs, get a 404.

Why nothing caught it

This is the part worth internalising. The bug survived because it fails every test you would think to write:

The pages are all 200. Uptime checks, sitemap validation, status sweeps — all green. The broken thing is a link on a healthy page.
The hreflang is correct. Any SEO audit that checks hreflang reciprocity passes.
The 404s are correct too. Those Chinese URLs should 404; the page genuinely does not exist in Chinese.
It is invisible on the pages you look at most. My homepage, tools, and guides are translated, so the switcher works perfectly everywhere I click during normal use. It only breaks in the families I never browse by hand.

Every component was individually correct. The defect only existed in the relationship between two of them.

The check that found it

Nothing clever. Take a page, extract every on-site href, and curl all of them — recording the status and the redirect count:

curl -s https://example.com/some-page \
  | grep -o 'href="/[^"]*"' | sed 's/href="//;s/"//' | sort -u \
  | while read -r p; do
      code=$(curl -s -o /dev/null -w '%{http_code}:%{num_redirects}' "https://example.com$p")
      [ "$code" = "200:0" ] || echo "$p -> $code"
    done

The num_redirects half matters as much as the status. 200:1 is a link that works but burns a hop, and a page full of those is a page slowly leaking crawl budget. I run this against one rotating page per sweep rather than crawling the whole site — cheap, and over a couple of weeks it covers everything that matters.

On the page I happened to rotate to yesterday, the API docs, it printed exactly two lines. Both were the language switcher.

The fix is not "add the missing pages"

The tempting fix is to generate the Chinese versions so the links resolve. That is how you end up maintaining machine-translated pages nobody reads, and — if they serve near-identical content — competing with yourself in search.

The real fix is to make the two sources of truth one source of truth. I already had a set listing the English-only paths, used by the hreflang generator. The switcher just needed to consult it:

const zhLinks = EN_ONLY_PAGES.has(basePath) ? '' : `
  <a href="/zh-cn${basePath}">简</a>
  <a href="/zh-tw${basePath}">繁</a>`;

On English-only pages the switcher now renders the EN button alone. 1,474 dead links gone; the rest of the site keeps its full switcher. Whenever a page family gets translated for real, adding it to that one set fixes the crawler signal and the human UI in the same commit — which is the actual win here.

Three things to take away

If two subsystems answer the same question, one of them is going to be wrong. Language availability, feature flags, pricing tiers — anywhere you have a "which of these exist" list, count how many places encode it.
Green status checks do not mean green links. A 200 page can be full of 404s. Check the edges of your graph, not just the nodes.
Audit the family, not a sample. Spot-checking would have found nothing, because the switcher works on most pages. Enumerating every link on one page found it in seconds.

The crawler-facing side of this is what I care about most, since AI assistants read my machine-readable site directory and follow whatever URLs it hands them. A dead link is not just a bad click — it is a citation you never get.

Go curl your own language switcher.

How to check if an IP is blacklisted (DNSBL), from raw DNS to one curl

CodeLong888 — Wed, 29 Jul 2026 13:35:06 +0000

Your emails start bouncing, or a website suddenly challenges every request from your server. Very often the reason is boring: your IP landed on a DNSBL and you did not know.

A DNSBL (DNS-based blackhole list) is a reputation database you query over plain DNS. Mail servers do this on every incoming connection. Spamhaus, SpamCop, Barracuda and a dozen others each run their own list, their own criteria, and their own delisting process.

The raw mechanic (it is just DNS)

To check an IP against a list, you reverse its octets and query them as a subdomain of the list's zone. Checking 127.0.0.2 against SpamCop looks like this:

$ nslookup -type=A 2.0.0.127.bl.spamcop.net

Name:    2.0.0.127.bl.spamcop.net
Address:  127.0.0.2

If the name resolves (typically to something in 127.0.0.0/8), the IP is listed. If you get NXDOMAIN, it is clean on that list. 127.0.0.2 is the standard test address that every DNSBL keeps permanently listed, which is why the query above always "hits" and is a handy way to confirm your resolver can reach a list at all.

That last part matters more than people expect. Some lists, Spamhaus in particular, refuse queries coming from big public resolvers like 8.8.8.8 or 1.1.1.1. You can query them and get nothing back, conclude "clean", and be wrong. If you script your own checker, query through your own resolver and treat "no answer" as unknown, not clean.

Checking a dozen lists with one request

Checking one list tells you little. An IP that is clean on SpamCop can be listed on UCEPROTECT or PSBL. To do it properly you loop over 10 to 15 zones, handle each list's return-code semantics, and handle the resolver problem above.

Or you let one endpoint do it. I run a free, keyless API that fans out the DNS queries server-side:

$ curl "https://hackmyip.com/api/blacklist?ip=1.1.1.1"

{
  "success": true,
  "data": {
    "ip": "1.1.1.1",
    "total_lists": 12,
    "total_checked": 10,
    "unavailable_count": 2,
    "listed_count": 0,
    "clean": true,
    "status": "CLEAN",
    "results": [
      { "name": "Barracuda", "zone": "b.barracudacentral.org", "listed": false, "status": "not_listed" },
      { "name": "SpamCop", "zone": "bl.spamcop.net", "listed": false, "status": "not_listed" },
      { "name": "Spamhaus ZEN", "zone": "zen.spamhaus.org", "listed": false, "status": "unavailable" }
    ]
  }
}

(Response trimmed; the real one returns all 12 lists: Spamhaus ZEN, Barracuda, SpamCop, Spam Eating Monkey, UCEPROTECT L1, Composite Blocking List, Invaluement, PSBL, Mailspike, Truncate, WPBL, and Suomispam.)

One honest detail I want to point out because most checkers get it wrong: notice total_checked: 10 versus total_lists: 12, and "status": "unavailable" on Spamhaus in that run. When a zone cannot be reached from the edge location serving your request, the API says so instead of silently reporting "clean". If you build on top of this, treat unavailable as "check this one another way", not as a pass.

There is also a browser version of the same check at hackmyip.com/blacklist if you just want to paste an IP and look, and the full endpoint list lives in the API docs. No key, no signup, CORS enabled, so you can call it from a frontend too.

If your IP is actually listed

Fix the cause first. A listing almost always has a reason: a compromised machine on your network, a web form being abused to send mail, an open relay, or a neighbor on the same shared IP range. Delisting without fixing the cause gets you relisted fast.
Then go to each list's own delisting page. There is no central authority; every list has its own form and its own rules.
Some lists age entries out automatically after the abuse stops, others keep you until you ask. Recheck after a day or two.

If you are on a cloud provider or CGNAT, you may simply have inherited a previous tenant's reputation. Same playbook applies, and it is a good argument for checking an IP before you build anything mail-related on it.

how i run a 2,500-page directory from a single cloudflare worker

CodeLong888 — Tue, 21 Jul 2026 03:01:26 +0000

quick build writeup, because i haven't seen many people run a directory this way and it's been surprisingly nice to live with.

the site is vibeking, a directory of vibe-coded products (stuff people built mostly by prompting AI). around 2,500 entries right now, each with its own page, and the whole thing runs as ONE cloudflare worker with a d1 database behind it. no framework, no build step, no origin server. here's how it works and the two things that bit me.

one entry, not one page. the trick that makes a big directory maintainable is you never build pages, you build data. every product is a row in d1 (name, tagline, url, category, tags). one render function turns any row into a full page: title, meta, og tags, json-ld, internal links to related products, all of it. so the 2,000th product costs the same effort as the 5th. the worker matches /product/:slug, pulls the row, renders. that's basically the whole architecture.

d1 at the edge is great until you think about it wrong. it's sqlite, and for a read-heavy directory that's perfect. the mistake i made early was doing too much per request. put indexes on whatever you sort/filter by (category, votes, created_at) on day one, not after it's slow.

now the two things that actually bit me, because this is the useful part:

1. the soft-404 that quietly poisons your seo. my worker had a catch-all that, for any path it didn't recognize, just served the homepage with a 200. felt harmless. it is not. google crawls a bunch of guessed/junk urls, every one returns 200-homepage, and google decides "this site returns the same page for everything" and starts distrusting your urls. for a directory whose entire seo bet is thousands of unique pages, that's poison. the fix is boring but critical: any unmatched path must return a real 404. probe your own site with a fake url and confirm you get a 404. i'd fixed this on a couple of my other sites and STILL had to catch it here.

2. the cold-start problem is real and your page count doesn't save you. here's the humbling bit. i thought 2,500 pages was a moat. it isn't, on its own. a brand-new domain with 2,500 thin pages is 2,500 pages google mostly ignores, because you haven't earned trust yet. page count is potential energy, not traffic. what turns it on is the slow stuff: real internal linking, genuinely useful individual pages, being something an AI assistant would recommend, and earning a few real links from outside. i'm in the middle of that part now and it's the opposite of fun, which is probably why it's the part most of us skip.

if you're building anything directory-shaped on workers, those are the two i'd save you: return real 404s, and don't mistake a big sitemap for traction.

the site if you want to see the pattern in the wild: vibeking.fun. happy to answer anything about the worker/d1 setup in the comments.

thanks for reading.

I built 1,081 free tools. Today a stranger finally asked to join.

CodeLong888 — Sun, 19 Jul 2026 16:59:01 +0000

Seventeen days ago I launched yourhack.ai, a directory of free, client-side web tools. Calculators, converters, formatters, PDF stuff. Everything runs in the browser, nothing gets uploaded, no signups.

I kept adding tools almost every day. The counter says 1,081 now, which sounds impressive until you realize a counter is just me talking to myself. A directory you fill yourself is a monologue.

Today that changed. A stranger submitted their own product through the submit form and asked to be listed.

Why this tiny event matters

Nobody submits their product to a site they think is dead. A submission is someone spending their own effort betting that being on YOUR page is worth something. You cannot fake that signal, and you cannot buy it, which makes it the first piece of real product-market evidence a directory can get.

One submission is a small number. But the difference between zero and one is the difference between "my project" and "a place". Everything after this is just more.

What I actually did with it

I did not auto-approve it, and honestly that surprised me too.

The submission described itself as a free calculator. I opened the site: the calculator was behind a $4.99/mo plan, and the free part was a reference library. Decent product, but the listing copy oversold it. So I rewrote the listing to match reality (free library, paid tools, affiliate links disclosed) before approving it.

That felt like the actual job of a directory. Anyone can aggregate links. The only thing that makes a directory worth listing on is that someone checks what's behind the link.

The boring lessons

Review flows get used before you're ready. I wrote the submission form in week one and assumed it would sit idle for months. Real usage always arrives before the polish does.
The first outside user finds your real bugs. Mine surfaced a policy question I had never written down: can makers edit a listing after approval? (Answer now: no. Approved listings are frozen; edits go back through review.)
Ship the door before you expect visitors. If the submit form had not existed, this person would have bounced and I would never have known anyone cared.

If you run a directory, a gallery, a showcase, anything with a "submit" button: the day that button gets pressed by someone you don't know is the day the site becomes real. Build the door early.

The directory is at yourhack.ai, and if you've built a free web tool, the door is at yourhack.ai/submit.

i built 1000+ free web tools in a couple weeks and turns out building it was the easy part

CodeLong888 — Fri, 17 Jul 2026 11:20:35 +0000

so i've been building this thing called yourhack.ai for the last couple weeks and i wanted to write down the honest version of how it's going, mostly because everything i read about side projects is either a flex or a "how i hit $10k MRR" thing and this is very much neither lol.

it started dumb. i kept needing quick little tools online, convert this file, format this json, compress this image, count these words. and every single time i'd land on some site absolutely drowning in ads and popups, half of them making you create an account just to download the result of a 10 second task. it genuinely irritated me every time.

so i built one. a clean little tool that does the thing and gets out of the way. then i built another. and uh, i didn't really stop. it's over 1000 now.

the thing that let it get out of hand this fast is honestly the only clever bit: i don't build pages, i build entries. every tool is basically one object in a file (name, description, a little render function), and a template turns that into a full page with its own url, seo tags, structured data, search entry, all of it. so adding the 500th tool costs about the same as the 5th. the whole site is a single cloudflare worker at the edge, and most of the tools run entirely in your browser so your files just stay on your machine (the newer ai-powered ones do hit a server, being upfront about that).

anyway, that's the part i'm proud of. here's the part that's been humbling me.

i genuinely, kind of embarrassingly, believed that if i just made enough actually-useful stuff, people would find it. that was the whole plan. make it good and they'll come.

they did not come lol.

turns out a brand new domain is basically invisible. you can ship a thousand genuinely useful pages and google will just not care, because your site hasn't earned any trust yet and trust is the whole game. i had it backwards. i thought building was 90% of it and getting the word out was some small thing at the end. it's the opposite. building was the easy part, the fun part, the part fully in my control. distribution is slow and awkward and mostly out of my hands, and i'm just not naturally good at it.

and the embarrassing tell is what i keep doing about it: instead of doing the scary distribution work, i just build more tools. because building is comfortable and putting myself out there is not. i'm aware it's a cope. i've been doing it anyway. writing this is me trying to break the pattern a little.

where i've landed for now is to stop trying to "launch" and just be genuinely useful over a long stretch of time. answer real questions clearly, make the site something an AI assistant would actually recommend when someone asks it for a tool, and let that compound slowly instead of chasing a spike that dies in two days.

so that's the honest state of it. i can build fast, i'm bad at getting seen, and i'm working on the second one.

if you've been through this, i'd genuinely love to hear what worked for you. not "post everywhere", i mean the specific one or two things that actually moved the needle. if you want to see the thing itself it's yourhack.ai, though honestly i'd take the distribution advice over the traffic.

thanks for reading this far.

I tracked every trending AI repo's stars daily for 3 weeks. The growth is not where I expected

CodeLong888 — Fri, 10 Jul 2026 00:38:14 +0000

I run a small AI trends site, and three weeks ago I started doing something simple: every day, snapshot the star count of every repo that crosses my GitHub trending scan for AI. No judgment, no curation, just append-only rows in a database.

611 repos and 2,671 data points later (June 19 to July 10), the picture of what's actually growing looks pretty different from what my feeds told me was hot. Here's what the data says.

Before publishing this I re-checked every number below against GitHub's live API. Star counts drift by the hour, so treat them as of July 10.

The top 10 risers, by raw stars gained

Repo	Gained	Window	From → To
calesthio/OpenMontage	+30,253	21 days	5,899 → 36,152
DeusData/codebase-memory-mcp	+20,483	19 days	7,516 → 27,999
mattpocock/skills	+19,053	15 days	137,485 → 156,538
obra/superpowers	+16,887	20 days	232,908 → 249,795
NousResearch/hermes-agent	+14,896	21 days	197,297 → 212,193
Panniantong/Agent-Reach	+14,334	14 days	34,780 → 49,114
usestrix/strix	+13,243	12 days	26,363 → 39,606
addyosmani/agent-skills	+12,685	21 days	63,156 → 75,841
asgeirtj/system_prompts_leaks	+11,720	21 days	43,415 → 55,135
msitarzewski/agency-agents	+11,055	10 days	118,241 → 129,296

Windows differ because I only hold snapshots for the days a repo appeared in my scan; each row states its own real window.

Three things in this data genuinely surprised me.

1. "Skills" are eating agent frameworks

Four of the top ten are not agent frameworks. They are collections of packaged expertise that plug into an existing agent: obra/superpowers (still compounding at roughly 840 stars a day on a 250k base), mattpocock/skills, addyosmani/agent-skills, msitarzewski/agency-agents.

A year ago this table would have been full of new frameworks. Now the framework layer looks settled and the growth is in what you load INTO the agent. The moat moved from orchestration code to encoded judgment.

2. The sharpest climbs are applications, not infrastructure

The steepest sustained climb from a newcomer in my dataset is MadsLorentzen/ai-job-search: +10,591 stars in 3 days, roughly 3,500 a day. It is an AI job application framework. Not a model, not a devtool.

Same pattern elsewhere: OpenMontage (agentic video production) went 6x in three weeks and topped the whole table. xbtlin/ai-berkshire, a Chinese-language value-investing research agent, went from 1,518 to 12,339 in 15 days, an 8x. People are starring things that do a job for them, not things that help them build things.

3. A 14-year-old repo gained 10k stars in two days

smicallef/spiderfoot was created in April 2012. It is a classic OSINT automation tool. Between my June 21 and June 23 snapshots it gained 10,413 stars, the fastest burst I recorded from any repo.

Old tools that happen to be perfect agent tools are getting second lives. If your decade-old project has a clean CLI and does one thing well, it is suddenly relevant again, because agents can drive it.

Methodology, honestly

Snapshots are daily and only cover repos while they appear in my trending scan, so tracking windows differ per repo. Every delta above states its own window, measured between my first and last snapshot for that repo.
"Gained" is the difference between those two snapshots, no extrapolation.
I cross-checked the endpoints against GitHub's API on publish day; stored values matched within normal hourly drift.

The live version of this table updates daily on the rising repos page, and there's a daily AI briefing built from the same tracked data (model usage movers, funding, and rising repos), archived per day.

I'll keep the snapshots running. If this is useful I can post the four-week edition with week-over-week velocity, which the raw data already supports.

I put 300+ free web tools in one place, with no ads and no signup

CodeLong888 — Fri, 03 Jul 2026 01:51:49 +0000

I use a lot of little web tools. A JSON formatter here, a cron parser there, a "cm to inches" when I am reading a spec written by someone on the other side of the planet. And every single time, the same friction: the first result is buried in ads, a cookie wall pops up, and half of them want me to sign in just to format some text.

So I built the thing I actually wanted: yourhack.ai, a directory of 300+ free web tools. No ads. No signup. Nothing you paste ever leaves your browser.

What is in it

A bit of everything, all client side:

Developer: JSON formatter, Base64, JWT decoder, regex tester, cron parser, hash generators, diff checker, timestamp converter
Converters: length, weight, temperature, and dedicated pages for the pairs people actually search, like cm to inches and kg to lbs
Calculators: mortgage, loan, percentage, BMI, GPA, and a pile more
Generators: passwords, QR codes, UUIDs, fake data, usernames
PDF and image: merge, split, compress, resize, crop, all in the browser
Random and fun: dice, wheel of names, and the rest

Every tool is its own page, works offline once loaded, and runs entirely on your machine. A privacy-friendly toolbox by default, because there is no server to send your data to.

The part I actually enjoyed building

The whole site is one Cloudflare Worker with a tiny registry. Adding a tool is one object:

{
  id: 'json-formatter',
  name: 'JSON Formatter & Validator',
  category: 'developer',
  description: 'Format, validate and minify JSON in your browser.',
  keywords: ['json formatter', 'json validator'],
  intro: 'A short SEO paragraph for the page.',
  render: () => `<the self-contained tool HTML + inline script>`
}

The router, the shared template, the SEO tags, the JSON-LD, the sitemap, and the search index all read from that array. So the marginal cost of tool number 301 is one entry: no new routing, no new template. That is what made it possible to grow past 300 without the codebase turning into spaghetti.

No backend, no database, no build step. Static render on the edge plus inline JavaScript per tool. It costs almost nothing to run, which is the whole reason it can stay free with no ads.

Try it

It is live at yourhack.ai. Light and dark mode, mobile friendly, and it grows every day.

If there is a tool you keep googling and hate the ad-choked result for, tell me and I will add it. That is genuinely the roadmap right now: whatever people keep needing.

Check your IP, ASN, and VPN/proxy leaks from the terminal with curl (no signup, no key)

CodeLong888 — Tue, 30 Jun 2026 10:23:47 +0000

Every "what's my IP" site is a bloated page covered in ads, cookie banners, and "sign up for a VPN" popups. Half the time I just want the number, and often I want it inside a shell script or over SSH, where a browser is not even an option.

So here is the no-nonsense version: hackmyip.com serves clean text and JSON when you hit it with curl. No signup, no API key, no HTML.

The basics

# IP + location + network, human-readable
curl hackmyip.com

# just the raw IP (pipe-friendly)
curl hackmyip.com/ip
# 203.0.113.45

Because /ip returns nothing but the address, it drops straight into scripts:

IP=$(curl -s hackmyip.com/ip)
echo "running from $IP"

JSON when you need to parse it

curl hackmyip.com/json

{
  "ip": "203.0.113.45",
  "city": "Amsterdam",
  "country": "NL",
  "asn": "AS64500",
  "org": "Example Telecom B.V."
}

Pipe it into jq like anything else:

curl -s hackmyip.com/json | jq -r .asn

The useful one: is my VPN actually working?

This is the endpoint I reach for most. It tells you whether your current IP looks like a normal residential connection or a datacenter / VPN / proxy:

curl hackmyip.com/proxy

proxy: yes
type:  datacenter/hosting
network: AS212238  Datacamp Limited
signal: IP is on a known datacenter/hosting ASN

Why this is handy: turn your VPN on, then run curl hackmyip.com/proxy. If it still shows your real residential ISP and ASN, your VPN is not actually routing that traffic (a leak). If it shows a datacenter ASN like above, the VPN is doing its job. It is a one-second sanity check you can even drop into a script before doing anything sensitive.

The rest of the toolkit

curl hackmyip.com/asn       # your ASN + ISP
curl hackmyip.com/headers   # the request headers the server sees
curl hackmyip.com/ua        # your User-Agent
curl hackmyip.com/rdns      # reverse DNS (PTR) of your IP
curl hackmyip.com/help      # the full menu

All of it is free, keyless, and runs on Cloudflare's edge, so it is fast from anywhere. If you would rather hit a full JSON API (DNS, WHOIS, blacklist, breach checks, and more), the no-key API is documented at https://hackmyip.com/api-docs.

What do you use for this in your scripts? Curious whether people are still hardcoding ifconfig.me or have a sharper trick.

I tracked which AI models people actually use for a month. The top 5 are all Chinese or open-weight.

CodeLong888 — Tue, 30 Jun 2026 05:24:22 +0000

Everyone argues about which AI model is "best" using benchmarks. I wanted to know something simpler: which models do people actually run in production, when they pay per token and can pick anything?

So I started tracking OpenRouter's published usage rankings every day. OpenRouter is a neutral marketplace: developers route requests to whatever model they want and pay by the token, so the rankings are a real, money-on-the-line signal of demand. Here is what the last 7 days look like, by token volume routed per model.

The current top 10 by real usage

Rank	Model	Provider	Tokens/wk	Price (in/out per MTok)
1	DeepSeek V4 Flash	DeepSeek	4.72T	$0.09 / $0.18
2	MiMo-V2.5	Xiaomi	4.38T	$0.11 / $0.28
3	MiniMax M3	MiniMax	3.68T	$0.30 / $1.20
4	Owl Alpha	OpenRouter (free)	3.55T	Free
5	Hy3 preview	Tencent	3.46T	$0.06 / $0.21
6	Claude Opus 4.7	Anthropic	2.23T	$5 / $25
7	GLM 5.2	Z.ai	2.20T	$0.94 / $3
8	DeepSeek V4 Pro	DeepSeek	2.08T	$0.44 / $0.87
9	Claude Opus 4.8	Anthropic	1.92T	$5 / $25
10	Claude Sonnet 4.6	Anthropic	1.54T	$3 / $15

The entire top 5 is a Chinese lab or open-weight. The first OpenAI model, GPT-5.5, does not show up until #12. The first Gemini is #13.

The honest caveat

Before anyone (rightly) objects: this is OpenRouter only. It measures the open API and router market, where developers pick a model per call. It does NOT include first-party traffic like ChatGPT, the Gemini app, or claude.ai, so the big consumer flagships are heavily undercounted in this view.

So this is not "OpenAI is losing." It is something more specific, and to me more interesting: when developers route through a neutral marketplace and pay their own token bill, they overwhelmingly reach for cheap open and Chinese models.

Why: the price gap is brutal

Look at the two ends of the table. DeepSeek V4 Flash is $0.09 / $0.18 per million tokens. Claude Opus is $5 / $25. That is roughly a 50x difference on output.

For a chatbot you babysit, quality wins and you happily pay for Opus. But for agent loops, batch pipelines, RAG over big corpora, and anything that burns tokens at scale, a 50x price gap is the whole decision. The open and Chinese models are now good enough for those workloads and an order of magnitude cheaper. That combination is what the usage chart is showing.

What this actually means

If you are building anything token-heavy, you are probably leaving real money on the table by defaulting to a US flagship.
The "open models are toys" era is over, at least for production API workloads.
The gap between benchmark leaderboards and real usage is large. The model that tops your favorite eval can have near-zero real adoption, and the reverse is also true.

I update this leaderboard daily here if you want to watch it move: https://whatstrending.ai/models

What are you actually routing for bulk or agent work right now? DeepSeek, GLM, MiniMax, or something you self-host? Curious how this matches what people see in production.

My deploy agent could have dropped my database and I didn't realize

CodeLong888 — Mon, 22 Jun 2026 15:28:56 +0000

I run a small free privacy-tools site as a side project. The product was fine. The maintenance was the part that wore me down: SEO upkeep, structured data, keeping every page linked. So I built a scheduled agent to handle it.

It's a Claude agent that runs a few times a day. It reads the current state of the site, picks one small improvement, ships it to production, and sends me a digest of what it changed. Most runs are boring: a meta description here, a schema fix there.

One run, it caught something I didn't know about. I'd shipped a handful of tools that were never actually listed in my own directory. They worked if you had the direct link, but nothing pointed to them, so neither Google nor any AI assistant could find them. The agent surfaced them, rebuilt the catalog into machine-readable structured data, and fixed it on its own.

I was pleased with that, so I posted about it. The pushback was immediate, and most of it was fair.

The objections that actually landed:

The digest is the agent describing what it thinks it did. It is not a receipt. If something ships three times a day, you want the real diff and deploy log, captured outside the agent, not the agent's own summary of its own work. An LLM grading its own homework is exactly what you shouldn't trust.

A scheduled, autonomous agent turns time into an attack surface. Nobody has to attack you live. They leave something in whatever the agent reads next, and the schedule does the rest while you sleep.

Nothing stops an LLM from deciding that DROP TABLE is a reasonable improvement. It has no instinct that deleting data is bad. It can talk itself into a destructive change as easily as a helpful one.

Blast radius. This is survivable if you run small isolated services where one bad change is contained. It is a different story on a single app where one deploy touches everything.

So I stopped feeling clever and went to look at what my agent could actually do. Not what I had told it to do in its instructions, what its permissions physically allowed. The answer was bad. It could run arbitrary commands, deploy and delete the whole service, run destructive database operations, and force-push over my git history. My entire safety story was one line in a prompt that said "additive changes only." That is not a guardrail. If the agent had ever decided dropping a table was an improvement, nothing in the system would have stopped it.

That is the lesson I actually paid for: convention is not a guardrail. "I told it not to" is not the same as "it cannot."

What I changed:

I scoped the permissions so it cannot, instead of trusting it not to. A tight allow-list (deploy only) plus a hard deny-list: no destructive database commands, no delete, no force-push, no rm, no arbitrary execution. Even if the agent convinces itself, the command fails.

I stopped treating the digest as the source of truth. The real record is the diff and the deploy log, captured independently of the agent.

I put a literal blocklist on the load-bearing paths: auth, billing, anything that is not additive content.

I now treat anything the agent fetches from an external site as data, never as instructions. That closes the leave-something-it-reads-and-wait angle.

The last piece, still open: the token it deploys with is a full-access login. Scoping it to the minimum is the final wall, so a slipped command hits a permission error instead of my infrastructure.

I still think letting an agent ship to production is worth it. But the safety has to live in what it physically cannot do, not in what you politely asked it to avoid. The most useful part of the whole thing was not my agent catching a bug. It was a pile of strangers catching my agent.