<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Kaviyarasu Viswanathan]]></title><description><![CDATA[Kaviyarasu Viswanathan]]></description><link>https://kavimacho56.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Sat, 24 Oct 2026 07:15:32 GMT</lastBuildDate><atom:link href="https://kavimacho56.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[How to Verify a “Free Forever” AI Tier Before You Rely on It]]></title><description><![CDATA[A practical routine for verifying free AI tiers: separate licence from hosting, read quota language precisely, and test the ceiling yourself.]]></description><link>https://kavimacho56.hashnode.dev/how-to-verify-a-free-forever-ai-tier-before-you-rely-on-it</link><guid isPermaLink="true">https://kavimacho56.hashnode.dev/how-to-verify-a-free-forever-ai-tier-before-you-rely-on-it</guid><category><![CDATA[AI]]></category><category><![CDATA[Productivity]]></category><category><![CDATA[webdev]]></category><category><![CDATA[Programming Tips]]></category><dc:creator><![CDATA[Kaviyarasu Viswanathan]]></dc:creator><pubDate>Sat, 17 Oct 2026 07:57:44 GMT</pubDate><content:encoded><![CDATA[<p>"Free forever" is the most expensive phrase in software procurement — not because it's usually a lie, but because it's almost always true <em>on the day you read it</em>. The tier exists. The ceiling exists too; it's just described somewhere else, in different words, a few clicks away from the button you pressed.</p>
<p>I'm not annoyed about companies charging for their work. I'm annoyed about how much work it takes to find out what you're actually getting. So here's the fifteen-minute routine I run before any free tier becomes load-bearing in my workflow — the tool my notes live in, the model my prototype calls, the API my weekend project is built on.</p>
<h3>1. Separate the licence from the hosting</h3>
<p>Open weights and free hosted access are two different promises that get blended together constantly.</p>
<p>An MIT-licensed model you can download really is free forever — the licence outlives the company. A free hosted endpoint for that same model is free until the pricing page changes, the endpoint gets deprecated, or somebody acquires the vendor.</p>
<p>Ask one question: <em>if this company disappeared on Friday, what still works on Monday?</em> If the answer is "nothing, it was only ever an API," you don't have free forever. You have free until further notice. That can still be fine — just don't build permanence assumptions on it.</p>
<h3>2. Read the quota language like you mean it</h3>
<p>Free-tier pages reuse a small set of phrases, and each one has a translation:</p>
<table>
<thead>
<tr>
<th>What you read</th>
<th>What it usually means</th>
</tr>
</thead>
<tbody><tr>
<td>"Free for individual use"</td>
<td>Teams and commercial use are a paid tier</td>
</tr>
<tr>
<td>"Generous limits"</td>
<td>The limits aren't published — you'll discover them during your busiest hour</td>
</tr>
<tr>
<td>"Rate-limited free access"</td>
<td>A trial with no end date but a ceiling that can move quietly</td>
</tr>
<tr>
<td>"Free during beta"</td>
<td>Priced at launch; the launch date is findable</td>
</tr>
<tr>
<td>"Unlimited*"</td>
<td>Read the asterisk — it's a fair-use clause</td>
</tr>
<tr>
<td>"Free tier" (no numbers)</td>
<td>The number is dynamic</td>
</tr>
</tbody></table>
<p>The trustworthy version reads boringly: specific numbers, a reset period, what happens on overflow — hard stop, throttle, or surprise invoice. Numbers for paid tiers but adjectives for the free one? Treat the free tier as undocumented.</p>
<h3>3. Look at the pricing page's history</h3>
<p>Vendors rarely announce deprecations loudly. They edit pages. Two minutes of archaeology:</p>
<ol>
<li><p>Plug the pricing URL into the <a href="https://web.archive.org">Wayback Machine</a>.</p>
</li>
<li><p>Compare snapshots from six and twelve months ago.</p>
</li>
<li><p>Look for removed free-tier rows, added seat minimums, "free" quietly becoming "trial," and quota numbers that shrank without a changelog entry.</p>
</li>
</ol>
<p>This cuts both ways, by the way. It also shows you which vendors have kept their free tier stable for years — the strongest evidence available that "forever" might mean it.</p>
<p>For open-source projects, swap the Wayback Machine for the repo: is there a commercial entity behind it, and do recent commits touch licensing or cloud terms?</p>
<h3>4. Test the ceiling before the ceiling tests you</h3>
<p>The only honest way to learn a free tier's boundary is to find it deliberately:</p>
<ul>
<li><p><strong>Push it in bulk.</strong> Run a batch job or a deliberately long context and watch where the throttling starts — requests per minute, tokens per day, concurrent sessions.</p>
</li>
<li><p><strong>Let it sit.</strong> Park the account for two weeks, then log back in. Free tiers get pruned, and so do idle keys.</p>
</li>
<li><p><strong>Check the exit.</strong> Confirm you can get your data out — a full export, an API dump, or at least a documented format. A free tier you can't leave is a hostage situation with good UX.</p>
</li>
</ul>
<p>Write down what you find, with dates. Future-you, reading a price-increase email, will want that note.</p>
<h3>The trick behind all four steps</h3>
<p>Every step does the same thing: turns a claim into a record. "Free forever" can't be verified directly — it's marketing language. Specific numbers, licence files, archived snapshots, and your own test logs can be.</p>
<p>Comparison sites are useful exactly to the extent that they do this work for you — quoting the vendor's own limits, dating the record, saying what they didn't check. If a directory lists a tool with no pricing detail and no freshness date, it hasn't verified the claim either. It has just passed it along.</p>
<hr />
<p>That verification work is most of what we do at Oryxen. Our <a href="https://oryxen.in/guides/evaluate-documented-free-ai-access">guide to evaluating documented free AI access</a> walks through eligibility, quota, and limits step by step — and every record in the <a href="https://oryxen.in">tool index</a> carries a source and a re-check date, so you can see how fresh the claim in front of you actually is.</p>
]]></content:encoded></item><item><title><![CDATA[Building Oryxen: How We Re-Test 36,000 Tool Records Every Quarter]]></title><description><![CDATA[I'm Kaviyarasu Viswanathan, founder of Oryxen — a free developer tool index comparing 36,000+ AI, developer, open-source and SaaS tools across 9…]]></description><link>https://kavimacho56.hashnode.dev/building-oryxen-how-we-re-test-36-000-tool-records-every-quarter</link><guid isPermaLink="true">https://kavimacho56.hashnode.dev/building-oryxen-how-we-re-test-36-000-tool-records-every-quarter</guid><category><![CDATA[AI]]></category><category><![CDATA[Developer Tools]]></category><dc:creator><![CDATA[Kaviyarasu Viswanathan]]></dc:creator><pubDate>Sat, 17 Oct 2026 05:50:23 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6ad30c002551575ebc9bdba6/e477e7b1-0eb3-451f-9225-e9b5066a980e.jpg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>I'm Kaviyarasu Viswanathan, founder of <a href="https://oryxen.in/">Oryxen</a> — a free developer tool index comparing 36,000+ AI, developer, open-source and SaaS tools across 9 categories. This post is about the least glamorous part of building it: keeping 36,000 records honest over time.</p>
<h2>Listings rot. That's the whole problem.</h2>
<p>A tool directory is a decaying asset. Pricing changes on a Tuesday with no announcement. A beloved open-source project quietly stops merging PRs. A startup pivots from "AI meeting notes" to "AI SDR agent" and nobody updates the listing. A free tier that said 10,000 requests/month now says 500.</p>
<p>When we started Oryxen, we counted: how many records in a typical tool directory are wrong within six months? Our estimate: most of them, somewhere. Pricing pages are the most-edited pages on the internet. If your directory doesn't re-verify, it's a museum.</p>
<p>So we built freshness into the data model itself. Every listing on Oryxen shows a freshness date — when we last re-tested it. And we re-test all 36,000+ records every quarter.</p>
<h2>What a freshness signal actually means</h2>
<p>A freshness date is a promise and a liability. It says: as of this date, the pricing class, the key features, the pros and cons, and the top alternatives were checked against reality. It does not say "perfect forever." It says "someone looked, here's when."</p>
<p>Quarterly re-testing is a brutal schedule at 36,000 records — roughly 400 records a day, every working day. Some of it is automated checks: does the homepage resolve? Does the pricing page still say what we recorded? Has the GitHub repo gone dark? The judgment calls — pros, cons, alternatives — need human eyes. We've learned to spend automation on the facts and humans on the opinions.</p>
<h2>Deterministic order: same input, same order — no auction</h2>
<p>The second decision we made early: there are zero paid placements on Oryxen, and the ranking is deterministic. Same query, same data, same order. Every time.</p>
<p>This matters more than it sounds. Most "best tools" lists are auctions wearing a trench coat: whoever pays ranks. Once you sell ranking, every editorial choice becomes suspect — including the honest ones. We refuse paid rank entirely, which means we also refuse the revenue that comes with it. That's the trade. The directory has to be funded some other way, and it is.</p>
<p>Deterministic ordering is also an engineering choice. If order is a pure function of the record data, then order is <em>testable</em>. We can write assertions: given this dataset, this query produces this sequence. When someone asks "why is tool X above tool Y," the answer is a data field, not a business relationship.</p>
<h2>Stated unknowns instead of invented ratings</h2>
<p>Here's a rule we hold ourselves to: when we don't know something, we say so. We don't invent a 4.7/5 score.</p>
<p>Fake precision is the original sin of tool directories. A star rating implies measurement, and measurement implies a methodology nobody published. We'd rather print "not yet verified" than a number we made up. Pros and cons are written in sentences, not scored. If a record is thin, it says so — and the freshness date tells you when someone will look again.</p>
<p>This is slower than scraping and scoring. It is also the only version I can defend in public, under my own name.</p>
<h2>What we still get wrong</h2>
<p>I'll be honest about the gaps:</p>
<ul>
<li><strong>Niche open-source tools</strong> sometimes change licenses or maintainers faster than a quarter. We're working on faster triggers for repos with sudden activity changes.</li>
<li><strong>Pricing class boundaries</strong> are fuzzy. "Freemium" covers everything from "generous forever-free" to "trial wearing a costume." We're splitting these classes finer this quarter.</li>
<li><strong>New categories</strong> emerge faster than we add them. Nine categories covered 36,000 tools, but the edges — AI agents, MCP servers, local models — keep spilling over the taxonomy.</li>
</ul>
<p>The roadmap is boring on purpose: more verification, finer pricing classes, faster signals on repo death, and <a href="https://oryxen.in/">the developer tool index I built</a> staying free while we do it.</p>
<p>Building a directory isn't a launch problem. It's a maintenance problem. The moat isn't the data — it's the discipline of re-checking it.</p>
]]></content:encoded></item></channel></rss>