DEV Community: Induwara Ashinsana

Best Free AI Video Generators 2026 — Honest Comparison (Watermarks, Limits, Real Quality)

Induwara Ashinsana — Thu, 10 Sep 2026 02:45:23 +0000

Every "best free AI video generator" list on the internet right now misleads you the same way. They list ten tools, call them "free," and never mention that the free tier gives you four watermarked seconds of 480p, signs you up for a 200-person queue, or quietly burns through your monthly credits in three clicks.

This is the honest version. I went through every tool below in the last 72 hours. Here is what "free" actually buys you in mid-2026, where the trade-offs hide, and which tool fits which job.

TL;DR — what "free" actually means

Across every consumer AI video tool, "free" comes in four flavours, and most lists conflate them:

Free tier with credits — Runway, Luma, Pika. You get N credits at signup, a smaller monthly refill, watermarks, and clear length caps. Useful for testing, painful for anything regular.
Free with a daily or weekly cap — Hailuo, Pixverse, Kling. No credit count, but you queue alongside everyone else, and quality drops at peak times.
Open source, self-hosted — Stable Video Diffusion, AnimateDiff. Free if you have a GPU or a Hugging Face Space allowance. Not free if you're on a phone.
"Free" via someone else's API key — the entire premise of the viral Facebook "make a free Sora 2 playground" post. This works for about thirty minutes before the host platform removes the listing for ToS violation. Skip it.

Nothing is free as in "[[[no signup](https://induwara.lk/tools/invoice-generator)](https://induwara.lk/tools/speech-to-text)](https://induwara.lk/tools/text-to-speech), no watermark, no limit, unlimited generations." If a site claims otherwise in 2026, it is either burning VC money to pull you in for an upsell or proxying a stolen API key. Either way it disappears within a week.

The comparison

Tool	Free credits / limit	Max clip	Watermark	Quality	Best for
Luma Dream Machine	~30 generations / month	5 sec	Yes	High	YouTube Shorts, social
Runway	525 credits at signup, then 125 / month	4–10 sec	Yes	Highest (Gen-3)	Pro-quality short clips
Pika 1.0	~80 generations / month	3 sec	Yes	Mid	Quick stylistic clips
Hailuo (MiniMax)	Daily queue, ~10–20 / day	6 sec	Yes	Mid-high	Anime, stylised motion
Kling 1.6	~6 generations / day	5–10 sec	Yes	High	Photoreal motion
Pixverse	~5 / day	4 sec	Yes	Mid	Fast iteration
Stable Video Diffusion (open source)	Unlimited if you bring a GPU	4 sec	None	Mid	Local, full control
Sora (OpenAI)	Requires ChatGPT Plus ($20 / month)	5–20 sec	Yes	Highest	Not actually free

Where I would actually start

For YouTube Shorts and Instagram Reels: Luma Dream Machine. The free monthly credit gives you about thirty attempts, quality sits at the top of the free pack, and a 5-second clip is plenty for short-form. Plan your prompt; don't iterate in panic.

For one-off "wow, look what AI can do" clips: Runway. Save the 525 signup credits for the things you actually want to keep — Gen-3 is noticeably better than anything else in the free pool.

For repeatable workflows (product clips, social ad tests): Hailuo or Pixverse. Daily limits are forgiving, the queues move, and you can run a steady drip rather than burn credits in a sprint.

For control and zero ongoing cost: Stable Video Diffusion via a Hugging Face Space (or local if you have a 12 GB+ GPU). Less convenient than the hosted tools, but you own the workflow and there is no rate limit.

What is NOT actually free — calling out the hype

Three claims circulating right now are misleading, and they're costing people time:

"Free Sora 2 API" — there is no public Sora 2 REST API as of mid-2026. Sora 1 access goes through ChatGPT Plus or Pro. Sites and Facebook posts offering a "free Sora 2 key" are reselling cracked accounts or selling you a fantasy.
"Free Sora playground on Hugging Face Spaces" — the viral self-host trick. The moment you password-gate a Space for commercial use, you violate Hugging Face's free-tier terms and the Space is removed. Lifespan in practice: a few hours, not "free for life."
"Free unlimited AI video" — every consumer tool runs on someone's GPU. Someone is paying for that GPU. If you are not paying with money, you are paying with watermarks, length limits, ads, queues, or your prompts becoming training data. Pick which one is acceptable to you and move on.

The free-tier landscape is workable if you set expectations correctly. The "completely free, unlimited" landscape does not exist.

A workflow that combines the free tools

The way to get the most out of free AI video is to pair it with the rest of the free creator stack:

Script your idea. Keep it tight — every clip is 3–10 seconds. Use a free AI text summarizer to compress a longer concept into a punchy prompt.
Generate the video. Pick a tool from above based on what you are making.
Add narration. Generate a voiceover with our free text-to-speech tool and match the voice tone to your visual style.
Sequence and trim. CapCut Web (free) or DaVinci Resolve (free desktop) handle stitching, captions, and a music bed.
Share privately first. Before publishing to a million strangers, send a draft to collaborators using our self-destructing file share — the only copy floating around is a one-time encrypted link.

Most "AI video for free" guides stop at step 2. Steps 3–5 are where a free workflow quietly becomes a professional one.

FAQ

Is Sora 2 free?
No. Sora 1 is bundled with ChatGPT Plus and Pro ($20 / $200 per month). Sora 2 has no public consumer pricing yet. Anyone offering a "free Sora 2 API key" is misleading you.

What is the best free AI video generator for YouTube Shorts in 2026?
Luma Dream Machine. Roughly thirty free generations per month, 5-second clips at the highest free-tier quality, and the watermark is small enough to crop or cover.

How do I remove the watermark from free AI video?
You cannot, legally. The watermark is the price of the free tier. Paid plans on Runway, Pika, and Luma all remove it; subscription cost runs $10–$95 per month depending on tier.

Can I use AI-generated video commercially?
It depends on the tool's terms, the tier you are on, and the model used. Runway and Luma allow commercial use on paid tiers; many free tiers explicitly prohibit it. Read the specific tool's terms before shipping to a paying client.

What is the longest clip I can generate for free?
Usually 5–10 seconds. Kling tops the free list at 10 seconds; most others cap at 4–6. Longer clips require paid tiers or extensions.

What is the best free open-source AI video model?
Stable Video Diffusion from Stability AI. You can run it locally on a 12 GB+ GPU, or on a Hugging Face Space within free quota. Less polished than Runway or Luma, but no ongoing cost.

Is "free AI video" actually free?
The platforms are free at the point of use within their limits. They are not free for the company hosting them — GPU rental costs $1–$3 per hour even at scale. Free tiers exist as marketing funnels for paid plans. Use them; don't pretend they are a business model.

Bottom line

If your goal is to make and ship video, pick Luma for quality, Hailuo for volume, and pair them with a free TTS and a free editor. If your goal is to build a "free AI video site" on top of someone else's API, the Facebook posts are selling you a fantasy — the unit economics don't work for anyone who isn't selling the course about it.

For the rest of our free tools — calculators, encrypted chat, code playgrounds, and more — see induwara.lk/tools.

Xiaomi 18 Fold: the foldable spec war just moved to silicon

Induwara Ashinsana — Tue, 08 Sep 2026 18:36:31 +0000

The Xiaomi 18 Fold is the clearest sign yet that the foldable phone race has stopped being about hinges and started being about who owns the chip. Xiaomi has shipped a book-style foldable that beats the Samsung Galaxy Z Fold 8 on battery, camera and display brightness, running on a processor Xiaomi designed itself.

Dominic Preston at The Verge got hands-on time with the phone at IFA and wrote it up in Xiaomi's wide foldable promises more power than Samsung's. I'm not going to repeat his impressions. I want to look at why this phone matters even if you never buy one, and what it means if you build Android apps in Sri Lanka.

📊 The spec gap is real, and it favours Xiaomi

Here is what The Verge reported, side by side with the Samsung numbers it quoted for comparison.

Spec	Xiaomi 18 Fold	Samsung Galaxy Z Fold 8 (per The Verge)
Chipset	Xring O3 (Xiaomi in-house)	Not stated in source
GPU	Arm Mali G2-Ultra NX (first phone to use it)	Not stated in source
Battery	6,000mAh silicon-carbon	4,800mAh
Charging	67W wired, 50W wireless	Not stated in source
Inner screen	7.58-inch OLED, ~1.4:1	Not stated in source
Outer screen	5.38-inch OLED, ~1.4:1	Not stated in source
Peak brightness	Up to 4,000 nits	Not stated in source
Rear cameras	200MP main (1/1.56-inch type) + 50MP 3.5x periscope + 50MP ultrawide	Lacks a triple camera
IP rating	None announced	Not stated in source
Weight and thickness	Slightly heavier and thicker than the Z Fold 8	Lighter and thinner
China price	¥10,999 (about $1,600)	Approaching $2,000

I have left the Samsung column blank where The Verge did not give a number. I would rather show a gap than fill it with a guess.

The pattern is obvious. Xiaomi wins on everything you can put on a spec sheet. Samsung keeps the wins that only show up in your hand: build quality, a less visible crease, lower weight, and water resistance, since Xiaomi has announced no rating at all. The Verge notes Oppo's Find N6 is still the only foldable to have all but removed the crease. Those boring advantages are what decide whether you still like a phone in month eighteen, and they are why I would not call Samsung finished.

Key takeaway: A 25% larger battery, a proper triple camera and a claimed flagship-class chip for roughly $400 less than the Samsung. That is not an incremental refresh. That is a pricing challenge.

⚡ The Xring O3 is the story, not the fold

The most important line in the source is easy to skim past: this is the first Xiaomi phone powered by its own Xring O3 chipset, and Xiaomi claims Snapdragon 8 Elite-level performance from it.

Think about who else ships their own phone silicon at flagship scale:

Apple with the A-series.
Google with Tensor.
Samsung with Exynos, in some markets.
Huawei with Kirin.

Xiaomi joining that list changes its cost structure and its roadmap independence. A company that buys Qualcomm chips ships when Qualcomm ships. A company with its own silicon can decide what the GPU does, and this one debuts Arm's Mali G2-Ultra NX with what The Verge describes as DLSS-style graphics acceleration on Android, meaning upscaling done by the GPU rather than brute-force rendering.

Bottom line for developers: Upscaling on mobile is coming to Android the way it came to PC gaming. If you build anything GPU-heavy, whether a game, a 3D viewer or an on-device model, expect a new performance tier where the rendered resolution and the displayed resolution are not the same number.

One caution. "Snapdragon 8 Elite-level" is Xiaomi's claim, quoted by The Verge, not a benchmark result. First-generation in-house silicon tends to be close on paper and warmer in practice. Wait for independent thermals before treating the O3 as proven.

📐 The 1.4:1 screen is a new layout problem for your app

Xiaomi has followed Huawei and Samsung into the short, wide book-foldable shape, and then gone further. Both screens sit at roughly 1.4:1, which The Verge points out is almost exactly the ratio of international paper sizes and IMAX screens.

For an Android developer, the practical consequence is this:

Screen state	Approx. shape	What breaks
Closed, 5.38-inch	Short and wide, ~1.4:1	Apps built for tall 20:9 phones get cramped vertically; fixed-height headers eat the screen
Open, 7.58-inch	Near-square, ~1.4:1	Single-column phone layouts waste half the width; tablet layouts assume wider
Mid-transition	Resize event	State loss if you don't handle configuration changes

The Verge itself expects "some apps running awkwardly on the short screen". If you maintain an Android app, even a small one for a local business, three checks are worth doing now:

Test at ~1.4:1 in the emulator, both a small-phone size and a near-square tablet size. Don't rely on the default device profiles.
Use window size classes rather than the old "is this a tablet" boolean. The open 18 Fold is neither a phone nor a tablet by the old definitions.
Handle configuration changes properly so an open-to-close fold does not restart your activity and drop the user's form input.

None of this is Xiaomi-specific. Samsung and Huawei are already here, and Apple may join them this week.

💰 What it would cost to bring one to Sri Lanka

Here is the catch for anyone in Colombo already pricing this up: Xiaomi has not confirmed an international launch at all. The Verge reports China-only preorders at ¥10,999, with sales starting September 10. That is the whole known availability picture.

So the realistic Sri Lankan path, at least initially, is a grey import. Before you get excited by "about $1,600":

The yuan-to-rupee figure moves daily. Run the ¥10,999 through the LKR exchange rate tool on the day you are actually deciding, not today.
Sri Lanka taxes imported phones on arrival, and the duty structure is not a single flat percentage. The Sri Lanka mobile phone import tax calculator will give you the landed cost from a declared value.
A China-only unit means a China ROM. Expect to deal with Google services, regional app stores and update timing yourself.
No announced IP rating on a device you will use through a Sri Lankan monsoon is a real risk, not a spec-sheet footnote.

Warning: Grey-market foldables have no local warranty and a hinge is the single most repair-prone part of any phone. Price in the cost of a replacement before you price in the savings.

💡 What this means for you

If you are a buyer in Sri Lanka: wait. Nothing about this phone is purchasable here through a normal channel yet, and Apple's expected foldable announcement will reprice the whole category within days. Run the landed-cost numbers, but don't act on them until Xiaomi says the word "international".

If you are an Android developer: the short, wide, near-square foldable is now a three-vendor form factor, with possibly a fourth this week. Test at 1.4:1. Adopt window size classes. Stop treating the fold as a niche.

If you are a student or builder watching the industry: the real headline is not the 6,000mAh battery. It is that another major phone maker now designs its own flagship chip and is using it to undercut the market leader by a few hundred dollars. Hardware margins are moving to whoever owns the silicon. That trend will outlast this phone.

Jensen Huang says AGI has arrived. Watch the GPU count

Induwara Ashinsana — Mon, 07 Sep 2026 22:20:47 +0000

Nvidia CEO Jensen Huang says "AGI has arrived", and the same short post tells you why to read it slowly. Huang also notes that OpenAI's new model was trained on Nvidia chips, and that 400,000 GPUs are coming online next. Business Insider reported the post on 6 September 2026.

I don't think Huang is being dishonest. I think this is a demand forecast wearing a lab coat, and the difference matters a lot if you're shipping software from Sri Lanka on a rupee budget.

🔍 Four people, four definitions, one week

The strongest evidence that "AGI" is not a technical milestone right now is that the people announcing it can't agree on what it means. All four of these statements come from the same news cycle:

Who	What they said	Where
Jensen Huang, Nvidia CEO	"From ChatGPT to o1 to Astra in 4 years. AGI has arrived. Congratulations @OpenAI team."	Post on X, Sunday
Greg Brockman, OpenAI president	"Welcome to the AGI era." And: "For me personally, I do think we're there."	Press call, Thursday
Sam Altman, OpenAI CEO	AGI is "a very poorly defined term… it's like an irrelevant marketing term."	"Sources" podcast
Gary Marcus, AI researcher and critic	Huang "gave no evidence and no definitions, which feels to me like an effort at a takeover of a scientific question by corporate fiat."	Substack, Sunday

Marcus published his own 10-point definition of AGI and counted that Astra meets one or two of them. His summary: "By conventional definitions, Astra still falls short."

You do not have to pick a side in that argument. You only have to notice that the CEO of the company selling the term's most valuable meaning, and the CEO of the company that built the model, are describing the same word in opposite registers.

Key takeaway: When a word means "civilisational milestone" to the supplier and "irrelevant marketing term" to the buyer's own CEO, it is not a spec. Don't plan a roadmap around it.

📊 The number in that post that isn't "AGI"

Strip the adjective out of Huang's post and what's left is a capacity announcement. Here is the money side of the story, using only the figures Business Insider reported:

Metric	Figure
Nvidia quarterly revenue reported in August	$96.2 billion
Change vs. same period a year earlier	More than double
Data centre segment (includes AI chips)	$89 billion
GPUs Huang says are "coming online next"	400,000

And the dependency runs both directions. In a March funding announcement, OpenAI called Nvidia "the foundation of our infrastructure" and said its "training fleet and the majority of our inference stack continue to run on Nvidia GPUs."

So the person certifying that the milestone has been reached is also the supplier being paid for reaching it. That doesn't make him wrong. It does mean his post is not independent verification, and treating it as such is a category error.

🧪 "AGI" is not something you can build against

OpenAI's own published definition is "highly autonomous systems that outperform humans at most economically valuable work." Try turning that into an acceptance test for your project. You can't. It has no threshold, no task list, and no measurement procedure.

What OpenAI said about Astra specifically is more useful, because it's narrower: the company called it the world's "most intelligent and aligned model" and said it can perform "the most demanding professional work with unmatched speed, accuracy, and judgment." Vendor claims, but at least testable ones. Note also that Astra was announced Thursday and described as rolling out to customers this week, so on the day I'm writing this there is no broad independent record of how it behaves on real workloads.

Which brings me to the only benchmark that matters for a small team: yours.

🛠️ Build the 30-task eval instead

If you run a two-person shop in Colombo, or you're a final-year student picking a model for your project, this is the process I'd follow instead of reading launch coverage:

Write down 30 real tasks from your actual product. Not riddles. The Sinhala-English support ticket you had to summarise, the invoice PDF you had to parse, the SQL you had to review.
Write the pass condition first, before you run anything. "Correct total, correct currency, no hallucinated line items." Vague criteria produce vague conclusions.
Run every candidate model on the same 30, including the cheap ones and the open-weight ones you can self-host.
Record cost per solved task, not cost per million tokens. A model that's 3× the price and solves twice as many tasks first-try may still be cheaper once you count your own debugging hours.
Re-run it quarterly. This is the part people skip, and it's the part that catches silent regressions and price changes.

Our AI model comparison tool is a starting point for step 3, and the AI agent cost calculator helps with step 4 once you know your average tokens per task. Both are free and need no signup.

Warning: The most expensive mistake available this week is rewriting a working pipeline around a model that shipped four days ago. Run your eval first. If the new model wins on your 30 tasks, migrate. If it doesn't, you saved a sprint.

💰 What 400,000 GPUs might mean for a rupee budget

Here is where the capacity number is genuinely more interesting to us than the AGI claim.

More supply usually pushes inference prices down over time. That has been the pattern in this market, and it's the pattern that has made frontier models usable on a Sri Lankan freelancer's budget at all.
It is a forecast, not a price cut. Huang said the GPUs are coming online. Nobody announced what they'll cost to rent or what per-token pricing will look like afterwards. Budget on today's published rates.
Capacity gets allocated to the biggest buyers first. If your workload is small and latency-tolerant, batch APIs and off-peak scheduling will do more for your bill this quarter than any datacentre build-out.

💡 What this means for you

The announcement changes the vocabulary, not your stack. Nothing about your rate limits, your budget, or your product's failure modes changed because a chip vendor used a three-letter word on a Sunday.

Three things worth doing this week:

Keep your own eval set. It is the only defence against both hype and FUD, and it costs one afternoon to build.
Read who benefits before you read the claim. Huang sells the compute. Brockman sells the model. Altman calls the term meaningless. Marcus sells the counter-argument. Everyone in that table has a position.
Optimise the thing you control. Prompt size, caching, batch scheduling, and picking the smallest model that passes your tests will move your monthly bill more than any frontier launch will.

If Astra really does clear the bar Brockman thinks it clears, you'll find out from your own 30 tasks within a month, and you'll know exactly which ones it changed. That's a better source than an X post from the person selling the GPUs.

Pigeon: a signed pass for what your sub-agent may do

Induwara Ashinsana — Mon, 07 Sep 2026 01:56:51 +0000

Almost every AI sub-agent permissions bug I have seen starts the same way: the parent agent spawns a child and hands it the same API key. The child now has everything the parent had. Deploy to production. Read the payments table. Merge to main.

Pigeon (pigeonlabsHQ/pigeon on GitHub) is a small Python library that attacks exactly this. Instead of copying the key, you mint the child a Pigeon Pass: a signed credential describing what it may do, and nothing wider.

🔑 The real failure is key copying, not model misbehaviour

Most of the agent-safety conversation is about the model: will it hallucinate, will it get prompt-injected, will it do something silly. That is the wrong layer to fix first. The thing that turns a silly action into an incident is that the silly actor was holding a key with full scope.

Pigeon's framing is blunt and I think it is right:

Identity tells you who the agent is. Authority tells you what it may do.

We have spent years getting identity right for humans and then handed our agents a shared secret with no scope at all. If you have ever stuffed a scope claim into a token and hoped the downstream service checked it, this will feel familiar — you can decode a JWT here and see how little most of them actually constrain.

📋 What is actually on a Pass

A Pass is not a profile of JWT, macaroons, Biscuit, or UCAN. The spec says so explicitly. It is its own format, signed with Ed25519, and every field is mandatory — unknown or missing fields are malformed, not ignored.

The permission model is three-dimensional:

Dimension	Example	Child may
`capabilities`	`["deploy", "open_pr"]`	only subset, exact match, no wildcards
`resources`	`["environment:staging", "repo:acme/api"]`	only narrower patterns; trailing `` allowed, `` alone is root-only
`constraints`	`{"max_deploys_per_hour": 3}`	keep every parent dimension; may add more

The core invariant is one sentence: a child must never carry more effective authority than its parent. Try it anyway and you get a DelegationError with reason_code == "PRIVILEGE_ESCALATION".

from pigeon import delegate, grant, verify

parent = grant(
    subject="agent:orchestrator",
    capabilities=["deploy", "open_pr"],
    resources=["environment:staging", "repo:acme/api"],
)

worker = delegate(parent, subject="agent:pr-bot",
                  capabilities=["open_pr"], resources=["repo:acme/api"])

denied = verify(worker, action="deploy", resource="environment:staging")
assert denied.reason_code == "CAPABILITY_NOT_GRANTED"

The detail I like most: verify never returns a bare boolean. A denial carries a reason code, a message, and the requested vs allowed comparison that failed. That is the difference between a library you can debug at 2am and one you rip out.

⚠️ The security file is the reason I trust it

Most agent-security projects oversell. Pigeon's SECURITY.md does the opposite, and it is the strongest signal in the whole repo.

Pigeon does	Pigeon does not
Fails closed when narrowing cannot be proven	Stop prompt injection
Verifies the whole chain, not just the leaf	Enforce a dimension you did not write
Invalidates the signature on any tampered field	See revocations issued after an offline Pass was minted
Counts `rate` and `count` against every ancestor	Manage, rotate, or recover your keys

Three admissions stand out.

Same-process crypto is nearly theatre. If the issuer and verifier are the same process, the signature adds little over a plain data-structure check. It earns its keep when the Pass crosses a process, machine, or organisation.
v0.1 ships no durable store. In-memory replay, revocation, and usage stores vanish on restart, so rate and count budgets reset. That is more permissive than most people would assume.
The recommended default TTL is one hour, because short expiry is the only revocation an offline verifier really has.

Key takeaway: the enforcement point is the whole product. As the README puts it, "If the runner never calls verify, the Pass is decoration." Signing changes nothing if the tool runs regardless of the answer.

🛠️ Why this matters if you are building on a free tier

Here is the part that makes it relevant for a solo developer or a three-person team in Colombo rather than a security team at a bank.

There is no server. No control plane to host, no per-seat pricing, no vendor. You change two places in code you already wrote: the spawn site and the tool site.
It is MIT-licensed Python 3.12+, installed with git clone and pip install .. Total cost: nothing.
It forces you to write the policy down. Most of us have never actually enumerated what our automation is allowed to touch. Filling in capabilities, resources, and constraints is uncomfortable in a productive way.

That third point is the real value, and it survives even if you never ship Pigeon. The exercise of listing what a sub-agent may do is worth an afternoon on its own. I run an autonomous build pipeline on this site, and the honest answer to "what may the build stage touch?" was, for a long time, "whatever the process could reach."

There is also an MCP middleware helper: the client mints a narrower Pass per tool call, the server verifies before the handler runs. The repo is careful to say this is an enforcement point and not part of the MCP specification. Given how many people are now wiring MCP servers into agents without any per-tool boundary, that is a pattern worth copying by hand even if you skip the library.

🤔 Where I would push back

Two honest reservations.

v0.1 means v0.1. Nine constraint ops, no persistent store, and a protocol the author invites people to find escalation bugs in. I would not put it in front of a payments flow this month.
An omitted dimension is not enforced. If you did not put environment:production out of reach, production is in reach. The protocol will not invent a policy you did not sign. Your Pass is exactly as good as your imagination about what could go wrong, which is a familiar and uncomfortable property of every allowlist ever written.

What this means for you

If you are running agents that spawn other agents, do this today regardless of whether you adopt Pigeon:

Stop passing the parent key down. Keep the real secret on the runner.
Write the allowed action list somewhere machine-readable, even if it starts as a dict.
Put the check where the side effect happens, not where the agent is spawned. That is the only place it counts.
Set an expiry in hours, not weeks, on anything you do mint.
Make denials explain themselves — reason code plus requested-vs-allowed, or you will disable the check the first time it blocks you unfairly.

Pigeon calls itself a small primitive, not a platform. That modesty is the point. The idea it encodes, that authority should narrow every time it is delegated, is older than AI agents and does not need a library to be useful. But having it in twenty lines of Python, MIT-licensed and serverless, removes the last excuse for not doing it.

Oura's IPO shows the smart ring moat isn't the sensors

Induwara Ashinsana — Sun, 06 Sep 2026 01:44:35 +0000

The smart ring market just got its first real financial disclosure, and it says something different from what the product marketing says. Oura filed to go public on September 3, 2026, and the numbers in that filing tell you the company is not primarily a sensor business.

TechCrunch's rundown of the challengers coming for Oura's crown lists six players trying different angles. I read that list and saw three separate moats, only one of which is technical.

📊 The arithmetic in the filing

The disclosed figures are worth sitting with before looking at any competitor spec sheet:

Metric	Figure
Revenue, nine months to June 30	$1.21 billion (nearly doubled)
Rings sold, past year	3.6 million
Paid members	~5 million
Latest product	Oura Ring 5, billed as its slimmest and lightest

Look at the last two rows together. Paid members exceed rings sold in the past year by roughly 1.4 million. That gap is people who bought hardware in an earlier year and are still paying every month. Hardware got them in; the subscription is what compounds.

Key takeaway: A competitor can match Oura's sensors in one hardware cycle. Matching a base of five million people already in the habit of paying a recurring fee takes years, and no spec sheet shortens it.

⚖️ The second moat is a patent docket

The most instructive fact in the whole story has nothing to do with heart rate accuracy. Ultrahuman's US business was disrupted in October 2025 after an ITC ruling went Oura's way in a patent dispute. Not a bad review, not a failed sensor. A trade ruling.

For anyone in Sri Lanka building hardware or a hardware-adjacent product aimed at Western markets, that is the lesson to file away:

Your technical roadmap can be correct and your market access can still be switched off by a body you never presented to.
Freedom-to-operate work is not a legal formality you do after product-market fit. In a crowded sensor category it is part of the design constraint.
The incumbent with revenue can afford to litigate for years. You probably cannot.

Ultrahuman has since raised $70 million with Qualcomm venture backing and is shipping the Ring Pro at $479 in the US from mid-September. Money solves the appeal; it does not give back the year.

🔋 Squeezing a dual-core CPU onto a finger

Here is the part that actually interests me as an engineering problem. The Ultrahuman Ring Pro carries a dual-core processor and redesigned heart-rate sensing, with the stated aim of running on-device software for AI interactions and even games.

A ring is the tightest power and thermal budget in consumer hardware. There is no room for a fan, the battery is a sliver, and the whole thing sits against skin, so waste heat is a comfort problem before it is a reliability problem. Putting general compute in there is not a gimmick decision. It is a margin decision:

Cloud inference costs money per user, per day, forever. A subscription business with millions of members pays that bill every single month.
On-device inference costs money once, in silicon, at manufacture.
Latency and privacy improvements are real, but they are the pleasant side effects. The spreadsheet is the driver.

That trade should feel familiar if you have built anything on a free tier. It is the same reason we run several tools on induwara.lk fully client-side rather than paying for a server round trip per request. When per-user marginal cost is your enemy, you push work to the edge, whether that edge is a browser or a titanium band.

🌐 The field, and what each one is betting on

Company	Price	Availability	The bet
Oura	Not disclosed in filing coverage	Shipping (Ring 5)	Installed base + subscription
Ultrahuman	$479 (Ring Pro)	US from mid-Sept 2026	On-device compute, apps, games
RingConn	From $349 (Gen 3)	Since May 2026	Price, plus vascular health insights
Samsung	$399 (Galaxy Ring, 2024)	Shipping	Bundling into the Galaxy ecosystem
Circular	Not announced (Ring 3)	Early 2027	Medical-grade claims + NFC payments
Dreame	Not announced	Not announced	Haptics and an on-ring touchpad

Two of these are notable for what they lack or promise. Samsung's Galaxy Ring, at $399 since 2024, still does not do sleep apnea or AFib detection, which is a striking gap for the company with the most distribution. Circular is going the other way entirely: the Ring 3 Pro claims FDA-cleared ECG for AFib detection, plus blood pressure and glucose tracking.

If Circular ships glucose tracking from a ring on the stated timeline, that is a bigger story than the IPO. Treat unshipped medical claims with the scepticism you would apply to any pre-launch spec sheet. Early 2027 is not a shipping date, it is a window.

💰 What one of these actually costs in Sri Lanka

The listed price is the smallest part of the bill here. A realistic total cost of ownership has four lines:

The hardware. $349 to $479 for the ones with announced prices.
Import duty and clearance, if it comes in as a personal import or in your baggage. Rates vary by category and consignment value, so check the current schedule with our Sri Lanka customs baggage allowance calculator rather than guessing.
The subscription. Oura's five million paid members are paying for something recurring. Budget for a monthly fee in LKR, converted at whatever the rate is on renewal day, not on purchase day. Our currency converter is the boring but necessary step here.
Sizing and returns. A ring that does not fit is a paperweight, and cross-border returns from Sri Lanka are painful and slow.

Before you spend that, be honest about what you would do with the data. If the goal is better sleep or smarter training, most of the value comes from acting on simple numbers you can get for free. A sleep cycle calculator will tell you when to go to bed tonight, and a heart rate zone calculator will tell you what pace to run at, both for zero rupees. A ring measures adherence. It does not create it.

💡 What this means for you

If you are buying: wait. Ultrahuman ships this month, Circular's medical-claim ring lands early 2027, and RingConn is already at $349. Prices in this category are heading down while the feature floor is heading up.
If you are building hardware: budget for freedom-to-operate research the way you budget for tooling. The ITC ruling took Ultrahuman out of its biggest market without a single technical failure.
If you are building software: the on-device compute shift in a $479 ring is the same economics that should push your own inference to the client. Recurring per-user cost is what kills small-team margins, not the initial build.
If you are studying this space: the filing is the most useful public document in consumer wearables right now. Subscriptions carried it, not sensors.

The rings are converging. The business models are not, and that is where this fight gets decided.

Crusoe's $30B valuation is a bet on power, not AI

Induwara Ashinsana — Sat, 05 Sep 2026 05:05:47 +0000

Crusoe's reported $3 billion raise at a $30 billion valuation is not really an AI story. It is an electricity story wearing an AI jacket. TechCrunch reports that the round came together after Crusoe reportedly signed a roughly $13 billion, five-year cloud contract with Jane Street, the quantitative trading firm.

Eleven months ago the same company was valued at $10 billion. Its software did not get three times better in eleven months. What changed is who has the power contracts, the land, and the delivery slots.

🔌 The valuation tripled because a customer signed, not because the tech improved

Line the two rounds up next to each other and the mechanism is obvious.

	October 2025	September 2026 (reported)
Amount raised	$1.38 billion	$3 billion
Valuation	$10 billion	$30 billion
Named investors	—	Atreides Management, Valor Equity Partners (co-leads), Mubadala Capital
Trigger	—	~$13B, 5-year Jane Street cloud contract

That is a 3× valuation move in under a year, and the reported reason is a single anchor tenant. Crusoe already builds hyperscale campuses for Oracle, OpenAI, Meta and Microsoft, and TechCrunch reports the company has met with Goldman Sachs and Morgan Stanley about a possible near-term IPO.

Key takeaway: In AI infrastructure right now, a signed multi-year offtake contract is worth more than any technical differentiation. The market is pricing contracted revenue, not cleverness.

I want to flag the hedge properly: every one of these numbers is reported, not confirmed by the company. Treat them as directionally useful, not as filings.

💰 Jane Street tells you who is actually paying for AI

Everyone talks about chatbots. The biggest single AI compute contract in this story was signed by a proprietary trading firm.

That is worth sitting with if you are choosing what to build or where to work:

The buyers with real budgets have a measurable loss function. A trading firm knows exactly what a millisecond or a better signal is worth. It does not need to be convinced that AI is the future.
Boring verticals fund the boom. Finance, logistics, insurance, energy. Not consumer apps.
Compute is being pre-sold in five-year blocks. Capacity going to a customer like this is capacity that does not show up on a public cloud spot market at a discount.

For a Sri Lankan engineer, the practical read is that the demand side of AI is enterprise and quantitative, not consumer. If you are building a portfolio to get remote contracts, a project that shows you can cut an inference bill or wire a model into a real workflow beats another chat UI.

🌏 Sri Lanka is not winning the data centre race, and does not need to

Crusoe started in 2018 mining crypto using flared natural gas — energy that was being burned off and wasted. That is the whole trick. Find stranded, near-worthless power, put compute next to it, sell the compute. Then in 2024–2026, point the same physical asset at a customer paying AI prices instead of crypto prices.

That arbitrage does not exist here. We do not have stranded gas fields, our grid is constrained, and industrial power is expensive. Anyone pitching you a "Sri Lanka AI data centre" play should be asked one question first: where is your cheap power coming from, and is it contracted?

The lesson from Crusoe is not "build data centres." It is "look at what asset you actually own, and find the customer who values it most." Crusoe's asset was never the mining rigs. It was proximity to wasted energy.

The asset most of us own is different: low-cost, high-skill engineering time in a timezone that overlaps both Europe and Asia, billed in dollars. That is the arbitrage worth pressing. If you are working out what your rate needs to be after conversion and platform fees, our freelancer USD-LKR earnings calculator does that maths.

🛠️ Build like compute stays expensive, because it will

If the biggest buyers are locking capacity into five-year contracts, do not plan your side project around GPU prices collapsing. Plan around them staying annoying. Here is how I actually structure things:

Strategy	What it buys you	When it fails
Run inference in the browser (WASM / WebGPU)	Zero server cost, zero upload, real privacy	Big models, weak devices
Use the smallest model that passes your eval	Often 5–20× cheaper than the flagship	Genuinely hard reasoning tasks
Cache aggressively on prompt and result	Repeat traffic costs almost nothing	High-variance user input
Batch overnight instead of real-time	Cheaper tiers, no idle capacity	Anything interactive
Speculative decoding on self-hosted models	Same output, fewer wall-clock seconds	Poor draft-model match

Most of the tools on this site are built on the first line of that table. They run in your browser, on your machine, with nothing uploaded, which is why they can be free with no signup. That design choice was originally about privacy. It turns out to also be the only cost structure that survives a compute market where a trading firm can outbid you by nine orders of magnitude.

If you are self-hosting and want to sanity-check whether a draft model is worth the complexity, our speculative decoding speedup calculator will give you the expected speedup before you spend a weekend on it.

💡 What this means for you

Three things I would take from this, if I were you:

Stop competing on layers you cannot fund. Foundation models and data centres are capital games measured in billions. Application and workflow layers are still open, and they are where the margin ends up once infrastructure commoditises.
Follow the money to the boring buyers. A quant firm reportedly committing $13 billion over five years says more about where AI revenue is than any consumer launch this year.
Design for expensive compute. Client-side execution, small models, caching and batching are not compromises. On this side of the world they are the design.

Crusoe spent 2018 to 2026 doing one consistent thing: standing next to cheap energy and selling what came out. Work out what you are standing next to, then find the customer who values it most. That part scales down to a one-person team perfectly well.

Belkin's semi-solid-state power banks: is 3x life worth $70?

Induwara Ashinsana — Fri, 04 Sep 2026 08:48:40 +0000

Belkin's first semi-solid-state power bank was announced at IFA this morning, and the headline spec isn't capacity or wattage. It's lifespan. Writing in The Verge, Andrew Liszewski reports that Belkin claims the new banks are "engineered to last up to 3x longer than other power banks."

That's an unusual thing to sell. Nobody markets a power bank on how long it survives before it becomes a paperweight. For anyone who charges a phone through a full day in 30°C heat, that's the only spec that has ever really mattered.

🔋 What Belkin actually announced

Two products, both using what the company calls BoostSolid Cell: a gel-like layer added alongside the liquid electrolyte you'd find in a normal lithium-ion cell.

Spec	UltraCharge Pro Slim Magnetic 5K Qi2	UltraCharge Pro 10K 60W + Display
Price	$69.99	$89.99
Capacity	5,000mAh	10,000mAh
Wireless output	15W Qi2, magnetic	Not stated
Max wired output	22.5W over USB-C	60W over USB-C, single device
Two devices at once	5W wireless / 12W USB-C	Output drops; figures not given
Ports	USB-C	2× USB-C, 1× USB-A
Display	None	Charge level, power output, internal temperature
Size claim	40% slimmer than other 5,000mAh banks	Slimmer than similar-capacity rivals

Belkin is late to this. The report names BMX, Kuxiu and Zens as having shipped semi-solid-state banks already. What Belkin brings is distribution and a warranty department, which for a battery you'll keep in a laptop bag is not nothing.

🌡️ Heat is the spec that matters in a tropical climate

The three claims Belkin makes for the gel layer are: longer usable life, reduced risk of overheating that leads to swelling or fire, and consistent power delivery across a wider temperature range.

That third one is the quiet winner if you live anywhere warm. Heat and a permanently full charge are the two things that age a lithium-ion cell fastest, and a power bank in Sri Lanka gets both. It sits in a bag on a bus. It sits on a desk beside a window. It gets topped up to 100% and left there for a week.

Key takeaway: The interesting product here isn't the battery, it's the display. A readout showing internal temperature turns a sealed black box into an instrument. You can actually see when it's cooking and stop charging it. No spec sheet gives you that.

The safety angle is real too, but keep it in proportion. Semi-solid-state still contains liquid electrolyte. It's a mitigation, not a removal of the failure mode.

💰 Do the maths on cost per year, not cost per mAh

Here's where I'd push back on the marketing. Take Belkin's 3x claim entirely at face value and it still doesn't obviously win on money.

The figures below use Belkin's real prices and its own 3x multiplier. The comparison bank's price and life are illustrative — pick your own numbers, the method is the point.

	Typical 5,000mAh bank (illustrative)	Belkin 5K BoostSolid
Purchase price	$20	$69.99
Assumed usable life	2 years	6 years (3× the baseline)
Cost per year	$10.00	$11.66

Roughly break-even. At $69.99 against a $20 bank, three times the life buys you convenience and one less dead battery in a landfill, not savings. The premium only pays for itself if the thing you're replacing costs more than about $23, or if the 3x turns out to be conservative.

And those are US dollar prices. By the time either of these reaches a shelf in Colombo you're paying import duty, VAT and a retailer margin on top. Before you compare a local listing to that $69.99, run the actual conversion — our LKR exchange rate page has the current mid-market rate, and the currency converter will do the arithmetic.

🔍 Four things the announcement doesn't answer

I'd want these before paying a 3x premium for a 3x claim:

Three times longer than what? No baseline is named. Against a well-made bank or against the cheapest thing on a shelf? The multiplier is meaningless without the denominator.
What's the cycle rating? Battery life is normally quoted as capacity retention after N cycles. No such figure appears.
Is the warranty as long as the claim? A six-year lifespan claim backed by a two-year warranty is a marketing number, not an engineering one.
What happens to output as it ages? A cell that holds capacity but loses its ability to sustain 60W is still a downgrade in year four.

None of this makes the claim false. It makes it unverified, which is a different thing, and the honest position until someone runs these for a couple of years.

💡 What this means for you

If you're a student or a freelancer buying one power bank to carry every day, this is worth watching but probably not worth being first on.

Don't upgrade a working bank. The greenest and cheapest battery is the one you already own. Belkin's own pitch is about replacement frequency, which is an argument for keeping things longer, not buying sooner.
Buy the display, not the chemistry. If you do spend up, the 10K model's temperature readout is the feature you'll use. The gel layer is a claim; the screen is a fact.
If you're replacing a swollen bank right now, heat tolerance is a genuine reason to pay more here, more so than for a reader in a cold climate. Just don't expect the money back.
Watch the second wave. BMX, Kuxiu and Zens got here first, Belkin makes it mainstream, and mainstream is usually when prices start moving.

The broader signal matters more than either product. Solid-state batteries have been perpetually two years away for a decade. Semi-solid-state is the compromise that actually ships: keep the liquid electrolyte, add a gel, take the safety and longevity gains you can get today. That pattern, shipping the 70% version instead of waiting for the perfect one, is a reasonable way to build most things.

LLM inference tuning: which knobs are free, which cost you

Induwara Ashinsana — Wed, 02 Sep 2026 16:28:10 +0000

LLM inference cost optimization is usually sold to you as a pile of tricks: quantize this, batch that, turn on speculative decoding. Baseten's Philip Kiely published a piece on the efficient frontier of LLM inference (updated 1 September 2026) that does something more useful than adding another trick to the pile.

It sorts the tricks into two buckets. That sorting is the part worth stealing, especially if your entire AI budget is smaller than one engineer's monthly salary.

🔍 Two buckets: trades and gifts

The article's framing is an efficient frontier — "the range of optimal combinations when trading off between two valuable outcomes in a resource-constrained environment." For inference, that's usually latency against throughput.

Some techniques move you along that curve. You buy throughput by selling per-user speed. Others push the whole curve outward, so you get more of both.

Technique	Bucket	What you give up
Batch size	Trade	Bigger batches cut cost per token, worsen per-user latency
Tensor parallelism (TP)	Trade	Fast over NVLink, but all-to-all ops are expensive
Expert parallelism (EP)	Trade	Low EP is lower latency; wide EP across racks is higher throughput
Attention data parallelism (ADP)	Trade	Throughput up, per-request speed down
Quantization	Mostly gift	Latency and throughput improve; quality is the second tradeoff
Kernel optimization	Gift	Nothing, if the kernel is correct
Speculative decoding	Gift	Draft model competes for the same GPU resources
Prefill/decode disaggregation	Gift	Complexity; mainly buys throughput at flat latency

Key takeaway: Before you spend a week on an inference optimization, ask which bucket it's in. A trade needs a decision from you about what you're willing to lose. A gift needs engineering time and nothing else.

📊 Most of those knobs are not yours to turn

Here's the honest bit the article doesn't need to say, because it's a serving company writing for people who run their own serving. If you call an API, you own almost none of this.

How you deploy	Batch size	Quantization	Parallelism	Spec decoding
Closed API (Anthropic, OpenAI, Gemini)	No	No	No	No
Open-weights via a hosted provider	Sometimes	Choose the endpoint	No	Provider's choice
Rented GPU (vLLM / SGLang / TensorRT-LLM)	Yes	Yes	Yes	Yes
Your own box	Yes	Yes	Yes	Yes

When you buy an API, you are buying somebody's chosen point on the frontier. That reframes the shopping question. "Which provider is cheapest per million tokens?" is the wrong question if two providers serve the same open-weights model at wildly different batch sizes — the cheap one may be the one that decided your users can wait.

The question to ask instead: at my request shape, what tokens per second per user do I get, and at what price? Our inference provider comparison is a starting point, but your own workload beats any table.

🌐 The latency you cannot tune away from Colombo

Serving-side tuning fights over milliseconds inside a data centre. If your users are in Sri Lanka and your inference runs in us-east, a chunk of your time-to-first-token is pure network round trip, and no kernel rewrite touches it.

Two practical consequences:

Measure your baseline RTT first. Run a ping or a curl -w '%{time_connect}' against your provider's endpoint from the machine your app actually runs on. If that number is large relative to your TTFT target, latency optimization on the model side is chasing the smaller half.
Move the app next to the model, not the model next to the user. Streaming makes perceived latency mostly about the first token. Putting your Next.js server in the same region as your inference endpoint often beats every sampling parameter you were about to tweak.

If your app server sits in Singapore and your LLM sits in Virginia, you have built a latency problem that quantization cannot solve.

⚡ "Jagged" is the most expensive word in that article

Kiely describes the frontier as very jagged, with cutoff points that are "unintuitive" and get "discovered empirically through sweeps." Quantization is called out as especially jagged: formats like MXFP4 and NVFP4 can deliver real serving gains with minimal quality loss.

Jagged means intuition fails. It also means:

Benchmarks from someone else's workload transfer badly to yours.
The configuration that was optimal for GLM-5.3 is not automatically optimal for Kimi K3.
A sweep of five configurations on one rented GPU-hour is cheaper than a month of guessing wrong.

That last point is the actionable one for a small team. A sweep is a scripted loop, a night of GPU time, and a CSV. Price it with the GPU cloud cost calculator before assuming you can't afford it.

🛠️ Where a two-person team gets the most back

If you are building a product rather than a serving platform, the ranking I'd use:

Batch your own requests. This is the one trade you fully control even on a closed API. Anything not user-facing — classification, tagging, summarising a backlog — goes into a batch endpoint or an overnight queue. You are voluntarily selling latency you don't need.
Cache aggressively. The article assumes KV cache reuse and KV-aware routing as table stakes. On the API side, your equivalent is prompt caching and stable prompt prefixes.
Check whether speculative decoding is on. The piece notes it works especially well for code generation, where token sequences are "relatively predictable" — techniques like EAGLE-3, DSpark and DFlash skip forward passes outright. If you're serving a coding tool, this is the highest-leverage gift on the list. Our speculative decoding speedup calculator will tell you what acceptance rate you'd need before it pays off.
Only then touch parallelism. TP, EP and ADP degrees matter when you own the hardware and have traffic to shape. Below that scale, they're a way to lose a weekend.

💡 What this means for you

The efficient frontier is a filter for your attention. Every inference optimization you read about this year is either a trade you must consciously choose, or a gift you should take. Most engineers get this backwards: they agonise over the gifts, which are free, and accept the trades by accident, usually by leaving a default in place.

For an SL small team, the sequence is short:

Find out where your latency actually goes before optimizing the model.
Take every gift your provider offers: caching, batch endpoints, spec decoding.
Make the trades deliberately, and write down what you sold.
If you're self-hosting, budget one GPU-hour for a sweep. The frontier is jagged, so the answer is empirical, and it's yours to find.

Bottom line: You cannot beat a serving company at kernel engineering. You can absolutely beat them at knowing which requests of yours don't need to be fast.

a16z's $8.5B growth fund: read it as a hardware signal

Induwara Ashinsana — Tue, 01 Sep 2026 06:11:13 +0000

The a16z $8.5 billion growth fund news landed on August 31, and the headline number is the least interesting part of it. TechCrunch reported that Andreessen Horowitz topped up its fifth growth fund by $1.75 billion, three days after announcing a separate $1.1 billion fund aimed at AI hardware.

I care about the smaller fund. It tells you where the bottleneck is, and the bottleneck is what sets your costs.

💰 What actually got announced

Two things, days apart, per TechCrunch:

Fund	Size	Launched	Focus
Growth Fund (fifth)	$8.5B (up from $6.75B)	January 2026, topped up Aug 2026	Enterprise + consumer AI, defense tech, robotics, infrastructure hardware and software, health tech
Machine Age Fund	$1.1B	August 28, 2026	AI hardware: chips, memory, networking, storage

For scale: the growth fund has backed 100+ companies over seven years, and both of these sit on top of the $15 billion a16z announced in January, when it reported $90 billion in assets under management.

David George, the general partner leading the growth investing team, framed it in a blog post as companies "reaching the growth stage faster and gobbling up more cash at higher valuations than ever."

That sentence is worth reading twice. It is not a boast about returns. It is a description of burn.

🔌 The $1.1B is the honest number

A dedicated fund for chips, memory, networking, and storage is an admission about where the constraint sits. Not models. Not apps. The physical layer underneath them.

Three things follow from that, and none of them require you to believe any hype:

Serving capacity, not model quality, is the scarce thing. You don't raise a billion dollars for memory and networking if the hard part is writing better prompts.
Memory bandwidth is the quiet villain. Storage and networking showing up alongside chips means the industry is spending on getting weights and KV cache to the compute, not just on more compute.
This is a multi-year bet. Hardware companies don't return capital in eighteen months. Someone thinks the demand curve holds long enough to justify a fund with a fund's lifetime.

Key takeaway: When the smart money moves from applications to memory and networking, it's telling you that inference economics — not model capability — will decide which AI products survive the next two years.

📊 Why this touches your unit economics

Here's the part that matters for anyone building a small product from Colombo, Kandy, or a bedroom with a decent connection.

The API price you pay today is set in a market where enormous capital is subsidising capacity buildout. That is genuinely good for you right now. It is also not a law of physics.

I don't know which way prices move, and I'd distrust anyone who claims they do. What I know is that my margin should not depend on the answer. So I run every AI feature I ship through one question: what happens at 3× the current token price?

Product shape	Cost per user action	Survives a 3× price move?
One-off tool, short prompt, cached result	Fractions of a cent	Yes, comfortably
Chat feature, full history resent each turn	Grows with every message	Only with truncation or summarisation
"Agent" that loops until confident	Unbounded by design	No, unless you cap the loop
Batch job over a document corpus	Predictable, measurable	Yes, if you priced it upfront

The middle two rows are where small teams quietly bleed. An agent loop with no hard iteration cap is a blank cheque written against a price you don't control.

If you want the actual numbers for your own prompts rather than a feeling, our AI token counter will give you the count, and the AI model comparison page is where I check whether a cheaper model would do the same job.

🛠️ What I'd change in how you build

Concretely, from my own work on this site:

Cap every loop. Maximum iterations, maximum tokens, maximum wall clock. Log when you hit the cap instead of silently retrying.
Measure cost per successful action, not per call. A cheap call that fails twice before working is not cheap.
Cache aggressively at the boundary. Identical inputs should never reach a provider twice. This is the highest-leverage change most small products haven't made.
Keep one working fallback path. A smaller model, a cheaper provider, or a plain deterministic version of the feature. Test it occasionally so it isn't fictional when you need it.
Write the provider layer behind your own interface. Swapping models should be a config change, not a rewrite.

None of this is exotic. It's the same discipline you'd apply to a database you don't own.

🌐 The career angle nobody mentions

There's a second reading of the Machine Age Fund that's more useful than the funding story.

A billion dollars aimed at chips, memory, networking, and storage is a statement about which skills get scarce. The industry has spent two years hiring people who can write prompts. The money is now moving toward people who understand:

Quantisation and what it actually costs you in accuracy
Serving architecture, batching, and KV cache behaviour
Memory bandwidth as a first-class constraint
Networking between accelerators
Plain systems engineering: profiling, measuring, not guessing

If you're a UCSC or Moratuwa undergrad deciding what to go deep on, that list is a better guide than any job board. Systems fundamentals were never obsolete. They just stopped being fashionable for a while.

The good news for a Sri Lankan engineer is that none of that requires capital. It requires a laptop, patience, and the willingness to read papers and profile things. The barrier is attention, not access.

💡 What this means for you

You will not raise from this fund. That's fine, and it isn't the point.

The point is that $9.6 billion across two funds is a very expensive signal about where the constraint sits, and the signal is free to read. Three takeaways:

Build as if inference prices are volatile. Cap loops, cache, keep a fallback. Your margin should survive a price move in either direction.
Don't compete on model access. Everyone has the same models. Your edge is the thing a16z can't fund: specific knowledge of a specific market, and distribution into it. Sri Lanka is full of problems that no global product will ever bother to solve properly.
Go deep on systems, not surfaces. The scarce skill is moving toward the layer the money is buying.

The capital is chasing infrastructure because infrastructure is hard. What sits on top of it — a genuinely useful tool for a specific group of people — is still cheap to build and still mostly unbuilt.

That gap is the opportunity, and it's the one part of this story you can act on tomorrow morning.

Diffusion Language Models: Why Speed Beats Size Now

Induwara Ashinsana — Mon, 31 Aug 2026 10:03:48 +0000

A diffusion language model writes text like an image model paints: it starts from a mostly-masked draft and refines every position at once, rather than one token at a time. The Kuleshov Group has published How to build a diffusion language model, adapted from their ICLR 2026 and MLSS 2026 talks.

I read it as an infrastructure post. The claim that matters isn't better text, it's cheaper text per second of GPU time, and that changes who can afford to ship an AI feature.

🔍 The actual break with how LLMs work today

Every model most of us use in production is autoregressive: predict token, append, repeat. The post names three consequences of that design, and they're all structural rather than fixable with more parameters.

Property	Autoregressive (GPT-style)	Diffusion
Generation order	Strictly left to right	All positions in parallel
Attention over output	Causal (backward only)	Bidirectional
Can it revise a token?	No, once emitted it's final	Yes, via remasking
Cost scaling	Steps = sequence length	Steps = a knob you set

That last row is the one I keep coming back to. In an autoregressive model, a 500-token answer costs 500 sequential forward passes. In a diffusion model, the number of denoising steps is a parameter you choose. Quality and latency stop being fixed by output length.

Key takeaway: Diffusion turns generation cost from a function of how long the answer is into a function of how good you need the answer to be. That is a budget dial, and small teams have never had one.

⚡ Tokens per second is the number that decides your bill

Parameter counts are a vanity metric for anyone self-hosting. Throughput is what you actually pay for. Here's what the post reports, with the caveat that these are the authors' figures and I have not benchmarked any of them:

Model	Scale	Reported claim
Mercury 2 (Inception Labs)	Commercial	~1,200 tokens/second on standard GPUs; 5–10× faster than Claude Haiku or Gemini Flash
Nemotron Diffusion (NVIDIA)	Up to 35B, open weights	2–8× throughput of comparable autoregressive models, retaining up to 99% of quality
LLaDA	8B, open weights	Competitive with LLaMA2-7B and LLaMA3-8B on general, math and code benchmarks
Gemma Diffusion (Google)	Open weights	Uniform-state diffusion with an encoder-decoder design

The Mercury 2 line is the one worth sitting with. The post claims it matches the quality of specialised inference chips like Groq and SambaNova while running on commodity GPUs. If that holds up under independent testing, the moat around fast inference was an architecture choice, not silicon.

For a two-person team in Colombo renting a GPU by the hour, a 5× throughput gain is the difference between an AI feature that pays for itself and one you quietly turn off at the end of the month.

🛠️ The training recipe is less exotic than the name suggests

This is where the post earns its title. The masked diffusion approach (MDLM) is described as, in effect, BERT with a randomised masking rate. You mask a random fraction of tokens, train a bidirectional transformer to reconstruct them, and vary that fraction across training.

The loss function is the part that should make every engineer sit up:

The training objective reduces to standard cross-entropy, averaged across all masking rates.

No new loss to derive. No exotic sampler to debug before you see a learning curve. If you have written a masked-language-model training loop, you have written most of a diffusion language model.

The practical pieces the post lays out:

Block diffusion — diffuse blocks of tokens (256, for example) conditioned on prior context, which gives you variable-length output and KV caching, the same optimisation autoregressive serving depends on.
Encoder-decoder split — a heavy encoder processes the clean context once, a lightweight decoder does the iterative denoising. You pay for context understanding a single time.
Remasking — re-mask a small subset of already-generated tokens so the model can correct itself. This is what makes inference-time scaling possible.
Uniform-state diffusion (UDLM) — replace tokens with random vocabulary items rather than a mask token, which supports multi-step revision more naturally.
RL post-training — Diffu-GRPO uses a mean-field approximation for policy gradients, with newer work deriving exact and approximate likelihood estimators.

Points 1 and 2 are what a small team should care about. They're the difference between a research curiosity and something you can put behind an API endpoint.

💰 What changes for a builder on a learning budget

I run tools that call models constantly, and the cost model here is genuinely different. Three things I'd plan around:

Latency stops scaling with answer length. Long-form generation, the thing that currently makes users stare at a spinner, is where diffusion gains the most.
Quality becomes a runtime decision. You can serve a cheap 8-step sample to free users and a 64-step sample to paying ones, from the same weights. No second model, no second deployment.
Fine-tuning a small diffusion LM is plausible on rented hardware. Cross-entropy on a bidirectional transformer is not an exotic training run. A domain-specific model for Sinhala or Tamil text is not obviously out of reach for a university lab.

If you're modelling what any of this costs before you commit, our AI token counter gives you the input side, and the speculative decoding calculator covers the closest thing the autoregressive world has to parallel generation. Both are free and need no signup.

🧪 Where I'd stay sceptical

The post is an advocacy piece by researchers who work on diffusion. A few numbers deserve a second look before you rewrite your stack.

Claim	The catch
"Up to 99% quality retained" (Nemotron)	"Up to" is doing work. A 1% quality drop is not uniform across tasks.
Remasking improves MAUVE 0.40 → 0.66	Autoregressive still scores 0.76 in that comparison. The gap narrowed, it did not close.
LLaDA competitive with LLaMA2-7B / LLaMA3-8B	Those are the baselines being matched. Matching a 2023–2024 open model is a real result, not frontier parity.

The strongest evidence in the post is arguably from biology, not chat: NT-v3, trained on over a trillion DNA tokens, generated regulatory sequences that outperformed native enhancers in wet-lab validation, and ESM3 reached 100B parameters for protein generation. Those are domains where bidirectional context and iterative revision obviously beat left-to-right, and where the win is measured in a lab rather than on a leaderboard.

💡 What this means for you

Don't rewrite anything this week. Do three things instead:

Track throughput as a first-class metric in whatever you're building. If diffusion serving matures, tokens/second is where the savings land, and you'll want a baseline to compare against.
Pull LLaDA or Nemotron Diffusion weights and run one inference. They're open. An afternoon of hands-on time now beats reading about it for a year.
If you're a student picking a research topic, this area is unusually accessible. The objective is cross-entropy, the architecture is a transformer you already understand, and the field is young enough that a careful paper from a Sri Lankan university would land.

The post frames diffusion as potentially being to inference-time scaling what the transformer was to pre-training scaling. That's a large claim and it's unproven. But the underlying shift is real and it's already shipping: the cost of a generated token is becoming something you tune rather than something you're handed.

For those of us earning in rupees and paying for GPUs in dollars, a knob is worth a lot.

vLLM v0.28.0: the breaking change small GPU users must read

Induwara Ashinsana — Sun, 30 Aug 2026 14:00:41 +0000

vLLM v0.28.0 shipped on 26 August 2026 with 584 commits from 270 contributors (76 new), and almost every headline in the release notes on GitHub is aimed at people running sixteen GPUs at once.

I read it from the opposite end: what happens to someone serving one model on one rented card. The answer is that two lines buried under "Breaking Changes" matter far more to that person than the entire Kimi-K3 section.

🧨 bitsandbytes is no longer in the box

The single most consequential line for a small-GPU setup: bitsandbytes support migrated to an out-of-tree plugin (#43529). bitsandbytes is how a lot of people load 4-bit and 8-bit weights onto a consumer card without pre-quantising anything. If your launch command passes --quantization bitsandbytes, a blind pip install -U vllm will not do what it did last week.

Here is the full breaking list, with who each one actually hits:

Change	PR	Who feels it
bitsandbytes moved out-of-tree	#43529	Anyone loading BnB 4-bit/8-bit weights on a small GPU
Transformers bumped to 5.15.0	#51668	Anyone pinning Transformers for another library in the same venv
`calculate_kv_scales` removed	#49389	FP8 KV cache users doing runtime scale calculation
`override_attention_dtype` removed	#48684	People forcing an attention dtype to dodge a numerics bug
`reasoning_content` output removed	#50624	Clients parsing reasoning traces from the response
KV tiering metrics renamed `block` → `chunk`	#52812	Anyone with a Grafana dashboard on offload metrics
MoE legacy code removed	#51078	Custom MoE kernels built against the old structure

Key takeaway: on a single-GPU box, v0.28.0 is not a "pull and restart" upgrade. Pin your current version, read those seven lines, and only then move.

📊 A doubled default that costs you memory

Under "New defaults", max_num_batched_tokens was raised from 8192 to 16384 (#51726). Prefix caching is now on by default for Mamba models (#50991), and the Blackwell CUDA graph capture default went up to 1024 (#49390).

These are throughput wins on big hardware. On a 16GB or 24GB card they are the opposite: a larger batched-token budget means more activation memory reserved before your KV cache gets a look-in. If you upgrade and hit an out-of-memory error you did not hit before, that default is the first thing I would check.

# Restore the old behaviour while you measure
vllm serve <model> --max-num-batched-tokens 8192

If you are sizing a card before you rent it, our LLM GPU Memory (VRAM) Calculator will tell you how much headroom you actually have to give away.

🖥️ The CPU and low-end story quietly got better

This is the part of the release I did not expect, and it is the part that matters most if your budget is a VPS rather than an H100 hour:

An MLA backend for CPU, so DeepSeek-V2/V3 can run there at all (#49453)
A triton-cpu wheel (#52092) and tcmalloc in the CPU path (#50841)
GPTQ and AWQ enabled on s390x (#51148)
An unquantized MoE backend for Power (VSX) (#51624)
Disk offloading for the CPU offload connector (#49644), plus weight offloading in Model Runner V2 (#51413)
An XPU wheel added to the release pipeline (#52108) for Intel cards

The CPU image is published like any other: docker pull vllm/vllm-openai-cpu:v0.28.0. None of this will be fast. But "slow and running on hardware I already pay for" beats "fast on a card I cannot afford" when you are learning, prototyping, or serving ten requests a day to a class project.

⚡ Speculative decoding is where the real speed went

Three of the release's headline items are speculative decoding: DFlash2 with local convolution and a candidate selector (#52816), DSpark confidence-scheduled verification (#47808), and async scheduling auto-enabled for draft models (#48341).

The eye-catching numbers in the notes belong to frontier setups, and I want to be precise about that rather than let them read as general claims:

Claimed number	What it actually applies to
~60% better TTFT	Adaptive speculative token budget, DSpark, on Kimi-K3 (#51725)
~17 GiB saved per GPU	Optional shared-expert sharding, Kimi-K3 only (#50912)
1.5~3x kernel-level speedup	Combined all-gathers, kernel level, not end-to-end (#51070)

None of those figures transfer to a 7B model on one card. Kernel-level speedup is not request-level speedup, and a Kimi-K3 memory saving means nothing if you were never going to load Kimi-K3.

Speculative decoding itself does transfer, and it is one of the few free speedups available on modest hardware. Before you wire up a draft model, run the numbers on our Speculative Decoding Speedup Calculator — the payoff depends almost entirely on the draft acceptance rate, and a bad draft model makes things slower, not faster.

🔐 The security note everyone exposing a port should read

Buried in the Security section is a documentation change worth more than most of the features:

vLLM's docs now warn that --api-key does not gate all endpoints (#51999).

If you are running vLLM on a cheap cloud box with a public IP and assuming that flag is your authentication layer, it is not. Put it behind a reverse proxy, or bind it to localhost and tunnel in. The same section also fixed a denial-of-service via sample-rate forgery that bypassed the audio decode duration guard (#49948), which is exactly the class of bug that bites a publicly reachable multimodal endpoint.

Two smaller hardening changes are the kind that break scripts quietly: cache_salt must now be non-empty (#50816), and non-object JSON bodies return 400 instead of 500 (#51654, #52528).

💡 What this means for you

If you are a student, freelancer, or small team in Sri Lanka running open models on rented or borrowed hardware, my read is:

Do not upgrade in place. Check the seven breaking changes against your launch command first. bitsandbytes is the likely one to catch you.
If you upgrade, pass --max-num-batched-tokens 8192 on the first run so you are comparing like with like, then raise it deliberately.
Ignore the Kimi-K3 and DeepSeek-V4 headlines. They are genuinely impressive engineering for clusters, and irrelevant to a single card.
Take the CPU and offload work seriously. Disk offloading and a CPU MLA backend widen what runs on hardware you can actually rent for a few dollars a month.
Fix your auth before your throughput. A public endpoint with no real gate is a bigger problem than 20% fewer tokens per second.

The wider pattern is worth naming. vLLM's release notes now read like infrastructure documentation for labs, but the project keeps shipping the unglamorous portability work in the same release. That second half is the part that decides whether people outside a handful of well-funded labs can serve open models at all. Before you commit to renting anything, price the options with our GPU Cloud Cost Calculator and check your expected throughput with the Inference Speed Calculator.

TurboKV: what a Rust key-value store's benchmarks really say

Induwara Ashinsana — Sat, 29 Aug 2026 17:47:12 +0000

TurboKV, a new embedded Rust key-value store, showed up on Hacker News this week with the kind of headline that usually makes me close the tab: "insanely fast." I opened the repository expecting a benchmark chart with no axis labels. I found the opposite.

The speed claims are real enough. But the genuinely instructive part of this project is the paragraph underneath the numbers, and that is what I want to talk about.

🔍 What TurboKV actually is

Strip the adjectives and it is a small, specific thing:

Embedded, not networked. It runs inside your process as a library. There is no server, no port, no connection pool.
Async, built on Tokio. insert, get and remove are all awaited.
LSM-tree shaped: memtables, SSTables, a write-ahead log, background compaction.
Apache 2.0, requires Rust 1.85+, currently at version 0.6.0.

The API is about as small as this class of database gets:

let db = Db::open_with_options("./my-database", DbOptions::durable()).await?;
db.insert(b"user:1", b"Ada").await?;
assert_eq!(db.get(b"user:1").await?, Some(b"Ada".to_vec()));
db.close().await?;

Three durability presets ship in the box, and the README is blunt about what each one actually promises:

Preset	When your write is acknowledged	Honest reading
`fast()`	In-memory visibility, no WAL	A cache. Crash means data loss.
`durable()` (default)	Appended to the WAL, no per-write sync	Survives a process crash, not a power cut
`paranoid()`	WAL group finished `sync_all`	Strongest, still bounded by your disk's honesty

📊 Read the benchmark table, not the headline

Here is the published comparison against fjall 2.11.2 and redb 2.6.3, measured on an Apple M4 with 32 GiB of RAM on 2026-08-28. Throughput is acknowledged keys per second, higher is better.

Workload	TurboKV Recoverable	fjall Buffer	redb Eventual	TurboKV / fjall
Sequential fill (1 key/txn)	1,407,678	485,252	1,397	2.901×
Random fill (1 key/txn)	834,137	456,924	1,549	1.826×
Overwrite (1 key/txn)	853,083	446,733	1,516	1.910×
Batch (100 keys/txn)	2,272,259	511,600	80,197	4.441×
Batch (1,000 keys/txn)	2,333,582	572,671	134,636	4.075×

Now look at what the author does with that redb column. Instead of banking the thousand-fold win, the README states that redb's Durability::Eventual performs a macOS F_BARRIERFSYNC on every transaction, while TurboKV and fjall stop at their process-crash-recoverable OS-cache boundaries. It then calls its own single-key rows "architectural context rather than a like-for-like durability claim."

Key takeaway: a benchmark that tells you which of its own rows are unfair is worth more than a benchmark that is 4× faster. The second one you have to re-run yourself; the first one you can reason about.

The project also renames its own default. The preset is called durable() in code, but in the benchmark table it appears as "Recoverable", because it survives a crashed process and not a lost power supply. I have reviewed vendor benchmarks that would never make that distinction in public.

💰 Why "embedded" is the interesting word for a small team

Most of us here are not sizing a fleet. We are running one box, and the monthly bill is in dollars against an LKR income. That changes which database property matters.

A networked store like Redis or Postgres costs you a second process, its own memory floor, a socket, a supervisor entry and a backup story. An embedded store costs you a directory.

Concern	Networked store	Embedded store like TurboKV
Extra process to run	Yes	No
Baseline RAM	Its own allocation	Yours, inside your app
Network round trip per read	Yes	No
Shared across services	Yes	No, single owner
Ops surface	Config, auth, ports	A folder on disk

That last row is the trade, and it is a real one. TurboKV states plainly that one open Db handle exclusively owns its data directory. If two of your services need the same data, this is the wrong tool and no benchmark number changes that.

Watch the memory defaults if you are on a 1 GB or 2 GB VPS. Every preset starts with a 64 MiB memtable and a 64 MiB block cache, so roughly 128 MiB is spoken for before your application allocates anything. Both are public fields you can lower before opening. If your keys are actually embeddings rather than short strings, the arithmetic gets steeper fast, and our AI vector storage calculator will size that for you before you provision the box.

🛠️ Four things I would check before shipping it

It is 0.6.0. That is a pre-1.0 version number on a storage engine. Storage bugs are the expensive kind, because they are discovered later than they happen.
The build flags are not optional. The persisted Bloom-filter format uses hardware AES. You are told to build with RUSTFLAGS="-C target-feature=+aes,+sse2" on x86_64 and +aes,+neon on ARM. Miss this in your CI image and you find out at runtime.
Dropping the handle is not a clean shutdown. Call close() or close_with_status(). This has to survive your panic paths and your container's stop signal, not just the happy path.
The benchmark hardware is not your hardware. Those numbers come from an Apple M4 with 32 GiB of RAM on APFS. Your $6 VPS has shared vCPUs and network-backed storage. Expect a different shape, not just a smaller multiple.

Bottom line: treat the published throughput as evidence that the design is sound, not as a number you will reproduce.

💡 What this means for you

If you are building a Rust service that needs local ordered storage, a queue, a cache with range scans, or an index that must survive a restart, TurboKV is worth an afternoon. The API surface is small enough to learn in one sitting and the scan and batch semantics are documented in unusual detail.

If you are not writing Rust, take the other thing instead. The habit worth stealing from this repo is the discipline of publishing what your numbers do not prove: the hardware, the durability boundary, the row that is not a fair fight, and the raw artifact so someone can check you. That applies to your own benchmarks, your client-facing performance claims, and your final year project.

Fast is a claim anyone can make. Legible is the harder one, and it is the one that survives review.