Alcazar · Technical Blog

GPT Image 2 vs Nano Banana 2: what to use now

Wed, 22 Apr 2026 00:00:00 GMT

If you want one answer, use GPT Image 2. It is now the best image tool for most people.

That does not make Nano Banana 2 a bad choice. It is probably the best fast image model on the market, and if you already live inside Gemini, Search, or Google Ads, it may fit your workflow better. Midjourney V7 still has the strongest artistic taste. FLUX.2 still matters if you want open or self-hosted workflows. Ideogram 3.0 and Recraft V4 are better picks for some design jobs. Adobe Firefly Image Model 4 is still the safe choice for larger brands that care a lot about licensing and provenance.

But if you are a normal user who wants one tool that listens well, edits well, handles text inside images, and is easy to access, the default has changed.

The short buying guide

Use GPT Image 2 if you want the best general-purpose image tool.
Use Nano Banana 2 if speed and Google integration matter more than absolute control.
Use Midjourney if you care most about aesthetic taste.
Use FLUX.2 if you want open weights, self-hosting, or deeper infrastructure control.
Use Ideogram 3.0 or Recraft V4 if the job is posters, logos, layouts, or vector-style design.
Use Firefly if your company is unusually conservative about commercial safety.

Why GPT Image 2 is the new default

The biggest shift in image models over the last year is that the best systems are no longer just “good at making pretty pictures.” They are becoming practical tools.

OpenAI’s ChatGPT release notes say ChatGPT Images 2.0 is available on all ChatGPT plans and can also use images with thinking on paid plans. OpenAI’s image docs describe gpt-image-2 as its latest image model, with built-in editing, high-fidelity handling of input images, and broad resolution support. That combination matters more than people think. The winning model in 2026 is the one that most often gives you the image you meant to ask for.

On the Arena text-to-image leaderboard, GPT Image 2 jumped to first place on April 19 with a preliminary score of 1512, well ahead of Nano Banana 2 at 1270. That is only one benchmark, and leaderboards are never the whole story, but it matches the practical case for the model. OpenAI has been unusually strong at prompt adherence, text rendering, and editing workflows for a while now. GPT Image 2 looks like the point where those strengths became hard to ignore.

If you make social graphics, mockups, diagrams, blog art, ads, UI concepts, or images with real text in them, GPT Image 2 is the most sensible first tool to reach for.

Where Nano Banana 2 still wins

Nano Banana 2 is not losing because it is weak. It is losing because the market got brutal.

Google’s own launch post says Nano Banana 2 combines the quality and world knowledge of Nano Banana Pro with Flash speed. Its Gemini API docs describe it even more plainly: it is the high-efficiency counterpart to Nano Banana Pro, built for speed and high-volume developer use cases.

Nano Banana 2 is fast, good, and deeply wired into Google’s ecosystem. Google says it is rolling out across the Gemini app, Search, Lens, Flow, Ads, AI Studio, and the Gemini API. If you want quick iterations, grounded image generation that can use Google search, and a model that already sits inside products you use every day, Nano Banana 2 is still one of the best tools on the market.

It is also a good reminder that “second best” can be a misleading label. For many teams, the fastest very-good model is more useful than the slowest best model.

Still, Google’s own product lineup tells you something important. When Google describes its image stack, it keeps Nano Banana Pro around for “high-fidelity tasks requiring maximum factual accuracy,” while Nano Banana 2 is framed as the fast, efficient default. That is a great reason to use Nano Banana 2. It is also a reason not to confuse it with Google’s absolute best image model.

API pricing, in plain English

Pricing via API is not as simple as “which model is cheaper?”

For GPT Image 2, OpenAI uses token-based pricing. In the official docs, the rough examples are about $0.006 for a 1024x1024 image at low quality, $0.053 at medium, and $0.211 at high. At 1024x1536 or 1536x1024, the examples are about $0.005, $0.041, and $0.165. That is surprisingly cheap at the low end and less cheap once you push quality up.

For Nano Banana 2, Google’s pricing is easier to budget. The official rate card translates to about $0.045 for 0.5K, $0.067 for 1K, $0.101 for 2K, and $0.151 for 4K. Batch pricing roughly cuts that in half.

So the practical answer is:

GPT Image 2 is often cheaper at low quality and still competitive in the middle.
Nano Banana 2 is easier to forecast at scale, especially if you use Batch.
GPT Image 2 can get expensive faster in edit-heavy workflows, because reference images are processed at high fidelity.

The state of image models now

The market is easier to understand if you stop looking for one universal winner.

There are now a few clear camps.

1. General-purpose multimodal image models

This is where GPT Image 2 and Nano Banana 2 live.

These are the models most people will actually use. They live inside large assistants, can handle editing as well as generation, and are trying to be useful for normal work, not just art prompts. This category is becoming the center of gravity.

Right now, OpenAI looks ahead on quality and control. Google looks strongest on speed, distribution, and ecosystem reach.

2. Taste-first creative tools

Midjourney is still the best example.

Its official V7 update says the model has better prompt understanding, stronger coherence, improved personalization, and a Draft Mode that is 10x faster than normal generation. That sounds like a pure quality upgrade, but the real Midjourney advantage is still taste. Midjourney often picks a more pleasing composition or a more interesting mood than the literal prompt alone would suggest.

That makes it valuable. It also makes it a weaker default for people who want strict control. Midjourney is a creative partner. GPT Image 2 is closer to a careful assistant.

3. Open and self-hosted models

This is where FLUX.2 matters.

Black Forest Labs built FLUX.2 around real workflows: multi-reference support, editing, high resolution output, and open-weight options you can run yourself. If you are a developer, want to keep costs under your own control, or need infrastructure freedom, FLUX is still the most important non-closed family in the market. For a normal reader, that probably does not matter. For builders, it matters a lot.

4. Design-specific tools

This is where many “best model” debates quietly break down.

If your job is not “make an image,” but “make a poster,” “make a logo,” “make an ad layout,” or “make an editable vector,” then general image leaders are not always the right answer.

Ideogram 3.0 is still unusually strong at typography and layout. Recraft V4 is even more specialized. Recraft says V4 was trained around design taste and production-ready outputs, and its vector models generate editable SVG files directly from a prompt. If your output needs to move into a real design workflow, Recraft can beat more famous models simply by being built for the job.

5. Enterprise-safe creative stacks

Adobe Firefly is here for a reason.

Adobe keeps pushing Firefly as the commercially safe option, with tight links to the rest of Creative Cloud. That usually does not make it the most exciting model on the internet. It does make it easier to justify inside companies that care about licensing, provenance, and asset handoff.

So what is the best image tool for most people?

GPT Image 2.

That is the answer I would give a friend who does not want a spreadsheet. Use ChatGPT if you want the best odds of getting a usable result on the first or second try. Use Nano Banana 2 if you want faster iteration and already spend your day inside Google’s world. Use Midjourney if you care more about taste than obedience. Use FLUX if you want control over the stack. Use Ideogram or Recraft if your real problem is design, not image generation in the abstract.

Image generation is no longer one market. It has split into everyday assistant models, taste-first creative tools, open infrastructure tools, and design-specific tools. That is a healthy sign. The category is maturing.

But if you force me to pick one recommendation for most readers in April 2026, I would not hedge.

Use GPT Image 2 first.

When will quantum computing break cryptography?

Tue, 21 Apr 2026 00:00:00 GMT

If you mean RSA, Diffie-Hellman, and elliptic-curve cryptography, the honest short answer is: probably not in 2026, probably not all at once, but very plausibly in the 2030s.

That is the part most people care about because those systems protect TLS handshakes, VPNs, SSH, certificates, passkeys, and blockchain signatures.

The other important part is this: you do not need to wait for a quantum computer to exist before the problem becomes real. If an attacker can copy encrypted traffic today and store it, they may be able to decrypt it later once a cryptographically relevant quantum computer exists. CISA, NSA, and NIST explicitly warn about this “harvest now, decrypt later” model.

So the practical answer is simple:

if your data only needs to stay secret briefly, the risk is later
if it needs to stay secret for 5 to 15 years, the risk is already here
if you still depend heavily on RSA or ECC, your migration clock has started

TL;DR

Shor's algorithm breaks the public-key systems the internet relies on most: RSA, DH, ECDH, ECDSA, and similar schemes.
AES and hash functions are in better shape. Grover's algorithm weakens them in theory, but it does not create the same practical emergency, and it does not mean everyone now needs bigger symmetric keys.
The scary part is not that a giant quantum computer exists today. It is that the resource estimates for breaking RSA-2048 and ECC-256 have been falling fast.
In 2019, a widely cited estimate put RSA-2048 at about 20 million noisy physical qubits. In 2025, Craig Gidney cut that to less than 1 million noisy qubits under similar surface-code assumptions.
In 2026, Google researchers estimated that breaking secp256k1-style ECC-256 could take about 1200 to 1450 logical qubits and fewer than 500,000 physical qubits on a fast superconducting architecture.
NIST already finalized the first core post-quantum standards in 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
NIST’s draft transition plan says common quantum-vulnerable public-key schemes should be deprecated after 2030 and disallowed after 2035.
The best plain-English answer is: treat the 2030s as the danger window for public-key cryptography, and plan as if long-lived secrets are already exposed.

Which crypto breaks first

Quantum computing does not threaten every cryptosystem equally.

Crypto	What quantum does	Practical result
`RSA`, `DH`, `ECDH`	`Shor's algorithm` solves the math directly	Broken once a large enough fault-tolerant machine exists
`ECDSA`, `EdDSA`, `ECC`	`Shor's algorithm` solves discrete logs too	Also broken, and often with fewer resources than RSA
`AES-128`	`Grover's algorithm` gives limited practical help	Still broadly considered safe
`AES-256`	Grover gives even more margin	Also safe, but not required as a PQ migration step
`SHA-256`	Grover helps with preimage search in theory	Still broadly considered safe

This distinction matters because a lot of headlines say “quantum breaks encryption” as if every lock on the internet fails on the same day. The main break is in public-key cryptography: the part used to agree on keys, prove identity, sign software, and authenticate transactions. Once that layer falls, a lot of higher-level systems fall with it.

Symmetric crypto is a different story. Quantum attacks help, but they do not give the same kind of clean knockout. That is why agencies like the NSA’s CNSA 2.0 guidance still keep strong symmetric primitives while replacing RSA and ECC.

Why the timeline feels closer now

For years, the easy answer was “don’t worry, we would need millions of qubits.” That was never the whole story, and it has aged badly. What changed is not just hardware. The attack cost estimates got better much faster. Researchers found better arithmetic, better circuit layouts, and better ways to pay the error-correction overhead.

A short version of the trend:

In 2019, Gidney and Ekerå estimated RSA-2048 could be factored in about 8 hours with roughly 20 million noisy physical qubits.
In 2025, Gidney updated that estimate to less than a week with less than 1 million noisy physical qubits under similar assumptions.
In 2026, Google researchers estimated ECC-256 over secp256k1 at 1200 to 1450 logical qubits, under 500,000 physical qubits, and roughly 9 to 12 minutes on a fast-clock superconducting machine.

Those are not minor edits. They are order-of-magnitude moves.

They also reinforce an awkward point: ECC may fall before RSA in many real systems. The reason is simple. Shor cares a lot about key size, and elliptic-curve systems use much smaller keys than RSA for the same classical security.

That means modern systems that moved from RSA to ECDH or ECDSA for efficiency did the right thing for the classical internet, but may have moved into an easier quantum target.

Why this does not mean “the internet breaks next year”

Because these papers are not attacks you can run on today’s hardware.

They assume a machine with:

many error-corrected logical qubits
low enough physical error rates
stable control systems
enough scale to run large fault-tolerant circuits end to end

Current systems are making real progress in quantum error correction, which is the hard part. For example, Quantinuum reported experiments with 48 to 94 logical qubits in 2026. That is a real milestone, but it is still far from the thousands of logical qubits, deep circuits, and industrial-scale reliability needed for practical cryptanalysis.

So there are two facts to hold at once:

A quantum computer that can break mainstream cryptography does not exist today.
The distance to one looks shorter than it did a few years ago.

That is why the serious debate is no longer “if,” but “how wide the remaining window is.”

The most honest timeline

No one can give you a real date, and anybody who says ”2033” or ”2041” with confidence is pretending. But we can still say useful things.

NIST’s migration FAQ says estimates for a cryptographically relevant quantum computer range from around 2030 on the aggressive end, to 15 to 20 years, to 30+ years on the slow end.

The Global Risk Institute’s 2024 expert survey found a significant chance within 10 years and a majority view that it becomes likely within 15 years.

Germany’s BSI, taking a conservative mainstream view, says a cryptographically relevant quantum computer is likely within 15 years and reasonably expected by about 2040, with faster progress possible if newer qLDPC error-correction methods work well.

I also think Filippo Valsorda’s timeline piece adds a useful way to think about the uncertainty. He puts it like this:

The bet is not ‘are you 100% sure a CRQC will exist in 2030?’, the bet is ‘are you 100% sure a CRQC will NOT exist in 2030?’

That is a better framing than arguing over one magic year. Security teams do not need certainty. They need to decide whether the downside of being late is acceptable.

Put that together and the practical forecast looks like this:

Before 2030: possible but still an aggressive case
2030 to 2035: a serious planning window, not a sci-fi one
Late 2030s: plausible even under more conservative assumptions
After 2040: still possible, but not a safe excuse to delay

That is why NIST IR 8547 proposes deprecating common quantum-vulnerable public-key schemes after 2030 and disallowing them after 2035.

Those dates are not proof that Q-Day is 2035. They are what a responsible migration schedule looks like when the risk window is uncertain and the replacement takes years.

Symmetric crypto is not the urgent problem

The common shortcut is: Grover gives a square-root speedup, so AES-128 becomes “really” 64 bits, therefore everybody should move to AES-256.

That is too simple. Grover attacks do not parallelize the way normal brute force does, which makes the practical cost much worse than the slogan suggests.

Filippo Valsorda’s note on 128-bit keys says it plainly:

“AES-128 is safe against quantum computers. SHA-256 is safe against quantum computers. No symmetric key sizes have to change as part of the post-quantum transition.”

That matches NIST’s PQC FAQ, which says it is quite likely Grover will provide little or no practical advantage against AES, and that current applications can continue using AES-128, AES-192, or AES-256.

Do not let arguments about symmetric key sizes slow down the migration away from RSA, ECDH, and ECDSA. The urgent work is on the public-key side.

What “break” really means in practice

For most companies, there are three separate questions hiding inside the headline.

1. When can attackers decrypt traffic they recorded earlier?

This is the earliest real risk for sensitive long-lived data. If your TLS sessions today use quantum-vulnerable key exchange, an attacker who records the traffic now may be able to read it later. That matters for diplomatic traffic, health records, corporate secrets, long-lived credentials, and anything with a long confidentiality shelf life. That is why key exchange is the first migration priority.

2. When can attackers forge signatures?

This comes later, but it is worse in some ways.

Once a machine can break ECDSA, RSA, or similar signature schemes quickly enough, it can forge software updates, fake identities, impersonate certificate holders, or steal from systems that expose public keys on-chain or in protocols.

That is a direct integrity problem, not just a privacy problem.

3. When does the average website need to care?

Honestly, not every site needs to panic today.

If you run a small site with short-lived sessions and no high-value archived data, quantum risk is not your top fire.

But if you operate infrastructure, VPNs, SSH fleets, PKI, code signing, hardware lifecycles, regulated data, or long-lived secrets, you should already be planning.

What to do now

The hard part is not choosing a year. The hard part is reducing dependence on RSA and ECC before the date matters.

A sane short checklist:

Inventory where you use public-key cryptography: TLS, VPN, SSH, certificates, code signing, hardware roots of trust, document signing, blockchain keys.
Separate key exchange from signatures in your plan. They migrate on different timelines.
Move long-lived confidentiality use cases to the front of the queue.
Prefer AES-256 and strong hashes for symmetric components.
Start testing the NIST standards: ML-KEM, ML-DSA, and SLH-DSA.
Expect hybrid deployments first. In many systems, the first practical step is hybrid TLS key exchange, not a full overnight switch of every certificate and signature stack.
Build for crypto agility. The teams that suffer most will be the ones that hard-coded one algorithm family into everything.

My bottom line

If you want the shortest honest answer to the title question, here it is:

Quantum computing probably breaks the big public-key cryptosystems in the 2030s, with enough uncertainty that anyone protecting long-lived secrets should act now, not when the first machine shows up.

RSA and ECC are living on borrowed time. AES-256 is not the main problem. The migration has already started. The only thing still uncertain is whether the industry finishes in an orderly way or gets forced into it late.

How to learn programming in 2026

Thu, 16 Apr 2026 00:00:00 GMT

If you want to learn programming in 2026, do not start by asking which degree to get.

Start by asking which small problem you can solve this month.

That is the big change. The old default path was: study for years, then maybe build. The new default path is: pick a real problem, use AI tools to get unstuck, ship something small, and learn the theory that the work forces you to learn.

For most people, I would not recommend a computer science degree as the default route into programming anymore.

Not because fundamentals stopped mattering. They did not. The U.S. Bureau of Labor Statistics still projects strong demand for software developers, with 15% growth from 2024 to 2034 and about 129,200 openings per year across software developers, QA analysts, and testers. But the way you become useful changed. A lot of the beginner pain that used to justify years of slow, formal ramp-up is now reduced by tools that can explain code, generate scaffolding, debug errors, and help you ship faster.

At the same time, the credential story is getting weaker, even if it has not disappeared. A 2024 report from the Burning Glass Institute and Harvard Business School found that the annual number of roles dropping degree requirements increased almost fourfold from 2014 to 2023. Hiring has not fully caught up, which is exactly why beginners need proof of work instead of empty optimism. The market is in between worlds. Degrees matter less than they used to, but the people who win without them still need to show that they can actually build.

So here is the path I would give a beginner today.

The starter setup

If I were starting from zero and wanted the fastest route to useful work, I would use this:

JavaScript first, then TypeScript
Replit if I wanted zero setup and the fastest first win
an AI editor like Cursor, Windsurf, or VS Code with GitHub Copilot once I was ready to work locally
Claude Code, ChatGPT, or Claude in the browser as a tutor, debugger, and reviewer
GitHub from day one
simple deployment, either Replit publishing or a static/frontend host like Vercel
Postgres or Supabase later, not on day one

That stack is not sacred. The point is to keep the number of moving parts small.

I would choose JavaScript first because it gives beginners the shortest path from idea to visible result. You can make buttons, forms, calculators, dashboards, landing pages, and small web apps without switching languages. Later, the same family of tools can cover frontend, backend, APIs, and light automation.

If you want the easiest possible start, Replit Agent is hard to ignore. Their docs are very direct about the value proposition: describe what you want in plain language, let the agent build it, preview it, then publish it. That matters for beginners because local setup is a real tax. A lot of people do not quit programming because functions are too hard. They quit because the first weekend disappears into Node version problems, terminals, PATH issues, and random config.

Once you are serious enough to work locally, use one AI-native editor and stick with it for a few months. GitHub Copilot now covers inline suggestions, multi-file edits, and agent mode. Claude Code can read your codebase, edit files, run commands, and work across multiple files and tools. Pick one main editing setup and one main explainer model. Do not spend your first three months comparing nine assistants like a sports bettor.

What to learn first

The beginner mistake is trying to “cover the field” before building anything.

Do this instead:

Learn enough HTML, CSS, and JavaScript to make a small page interactive.
Learn Git and GitHub early.
Learn how to read error messages.
Learn how to deploy.
Learn backend and databases only when your project needs them.
Learn deeper CS topics as support, not as your main loop.

That order is not academically pure. It is productive.

If you want structure, use courses as scaffolding around projects:

The Odin Project is still one of the best practical web paths because it is built around curated resources and real projects, not endless passive watching.
Its Foundations course is a good example of the right shape: HTML, CSS, Git, JavaScript basics, DOM work, and small projects.
CS50x is excellent when you want stronger problem-solving habits. Harvard describes it as an introduction to computer science for students with or without prior experience, with an emphasis on correctness, design, and style.
freeCodeCamp is still useful for drills, repetition, and free structure.

My recommendation is simple: use project-first resources like Odin as the spine, and use CS50x as your theory gym when you want to get sharper.

The new skill is not typing faster

The highest-leverage beginner skill in 2026 is not memorizing syntax. It is steering the tools well.

Can you describe a problem clearly? Can you break it into steps? Can you tell when the AI is wrong? Can you test the result? Can you ask a better follow-up question instead of pasting the same broken prompt again?

AI does not remove the need for skill. It changes the shape of the skill. A beginner who can guide the tools well, read the output critically, and keep shipping will outlearn the person who is still trying to become a human autocomplete engine.

How to use AI without fooling yourself

This is where a lot of beginners go wrong.

Do not use AI as a magic code vending machine. Use it like this:

ask it to explain the code it wrote in plain English
ask it what assumptions it made
ask it for the smallest next step, not the entire app
ask it to write tests or give you manual test cases
paste the exact error message and ask what it means
ask it for two approaches and the tradeoffs
ask it to review your code after you change it yourself

A good prompt for a beginner looks more like:

I'm new to JavaScript. I want to build a simple invoice tracker for one freelancer. Give me the smallest working version first. Explain each file. Do not add auth, payments, or a database unless I ask for them.

That gets you much better results than:

Build me a SaaS.

The other hard rule is this: never accept code you cannot roughly explain.

You do not need to understand every character. But you should understand what the file is for, what data is flowing through it, and how you would debug it if it broke.

Do not confuse school with progress

This is the part that annoys people, but I think it is true.

For most aspiring programmers who want to become productive and make money, a computer science degree is now the slow path, not the default path.

There are exceptions:

you want to do ML research
you want to work on compilers, operating systems, or deeply technical infrastructure
you need a formal credential for immigration, recruiting filters, or personal reasons
you genuinely want the college experience and can afford the time and cost

But if your actual goal is “I want to build useful software, get good fast, and maybe freelance, join a startup, or build a small product,” then spending four years outside the market is often a bad trade.

A better plan is:

start building now
use AI to compress the boring parts
fill in your weak spots as they appear
get paid for increasingly valuable problems

You can still learn algorithms, networking, and databases. You should. Just do not wait for official permission to become useful.

What to build if you want to make money

The fastest money in programming is usually not in clever projects.

It is in boring projects that solve a clear problem.

Good beginner targets:

a simple website for a local business
a lead capture page tied to email
a small internal dashboard
a form that turns messy input into a clean PDF or CSV
an automation that saves someone an hour a week
a niche directory or calculator site that can rank in search
a tiny CRUD app for one real workflow

Bad beginner targets:

the next social network
an AI wrapper with no distribution
a giant multi-tenant SaaS on week one
a startup idea so broad that you cannot finish the first screen

Money shows up faster when you solve expensive annoyances.

A restaurant owner does not care whether you understand red-black trees. They care whether online bookings stop disappearing. A small agency does not care whether you aced discrete math. They care whether their reporting workflow still burns six hours every Friday.

A realistic 90-day path

If I had to compress this into one simple plan, it would look like this.

Month 1

Learn basic HTML, CSS, and JavaScript.

Build:

a calculator
a to-do app
a small business landing page

Use AI constantly, but make it explain everything.

Month 2

Pick one project that resembles real work.

Examples:

invoice tracker
appointment booking site
basic CRM for one person
content planner
stock or price tracker

Deploy it. Put it on GitHub. Ask three real people to use it. Fix what breaks.

Month 3

Add one backend and one database.

Learn:

simple APIs
CRUD
auth only if the project really needs it
basic SQL

Then build one project that could plausibly make money or help someone make money.

By the end of those 90 days, you will still have gaps. That is normal. You will also know more than the person who spent the same three months shopping for the perfect curriculum.

The shape of a modern beginner

The beginner who wins in 2026 is not the one who refuses AI to prove purity.

It is also not the one who lets AI do everything and learns nothing.

It is the one in the middle:

practical enough to use every good tool
skeptical enough to check the output
focused enough to finish small projects
humble enough to keep learning fundamentals
market-aware enough to solve problems people will pay for

Learn enough to build. Build enough to learn more. Use the tools. Keep the loop tight. Get paid for useful work as early as you can.

For most beginners now, that is a better bet than waiting years to feel officially ready.

Claude Mythos is the first model Anthropic didn't really release

Thu, 09 Apr 2026 00:00:00 GMT

Claude Mythos matters for one reason above all: Anthropic seems to think it trained a model good enough at finding and exploiting bugs that the normal release playbook no longer made sense.

That is more interesting than another few points on GPQA.

Instead of putting Mythos into broad general availability, Anthropic put it behind Project Glasswing, limited access to a small set of defenders and infrastructure companies, published a long cybersecurity writeup on its Frontier Red Team blog, and paired it with a public alignment risk report. That does not prove every claim is right. It does tell us Anthropic thinks Mythos is different in a way that matters operationally, not just in marketing. The story became public in stages; Fortune reported a leak and Anthropic’s confirmation before the full April launch, and SecurityWeek summarized the dual-use framing others picked up.

My read is simple:

Claude Mythos looks like a real step up over Claude Opus 4.6
the biggest jump appears in agentic coding and cybersecurity, not in casual chat
on AGI timelines, it looks more like acceleration inside the current curve than a clean break from it
the most important missing number is still the one many people care about most: we do not have a public METR time-horizon score for Mythos

What Anthropic has actually said

The basic facts are now public.

Anthropic says Claude Mythos Preview is a general-purpose frontier model, stronger than its prior public models, but unusually strong at cybersecurity tasks. It says the model found thousands of high-severity vulnerabilities, including bugs in every major operating system and every major browser, and that it can autonomously turn some of those bugs into working exploits. Anthropic also says it does not plan to make Mythos Preview generally available for now. Instead, it is giving access to a narrow group of defenders through Project Glasswing, including organizations like AWS, Google, Microsoft, Cisco, CrowdStrike, Palo Alto Networks, JPMorganChase, and the Linux Foundation.

That is already unusual.

Labs often say a new model is powerful. They do not often say, in effect, “we are going to keep this one mostly off the public shelf because the cyber capabilities look too spicy.”

Anthropic’s own risk report also says Mythos is the most capable model it has trained, that it is used internally for coding and agentic work, and that overall alignment risk remains “very low, but higher than for previous models.” In other words, Anthropic is not claiming Mythos is rogue. It is claiming the capability jump is large enough that the old comfort level no longer applies automatically.

The company has been telegraphing a cyber inflection for a while. In building AI for cyber defenders it argued models had crossed from theory to practice on security tasks and that defenders needed to adopt AI or cede advantage. Glasswing is the operational version of that argument.

The benchmark picture

On public numbers, Mythos looks strongest in the places that matter for real software work.

Compared with Opus 4.6, Anthropic reports (figures from the Glasswing announcement):

SWE-bench Verified: 93.9% vs 80.8% (the benchmark is a human-filtered subset of real GitHub issues; see the SWE-bench paper and OpenAI’s Verified writeup)
SWE-bench Pro: 77.8% vs 53.4%
Terminal-Bench 2.0: 82.0% vs 65.4% (paper)
SWE-bench Multilingual: 87.3% vs 77.8%
GPQA Diamond: 94.6% vs 91.3%
Humanity’s Last Exam: 56.8% vs 40.0% without tools, 64.7% vs 53.1% with tools (paper)
BrowseComp: 86.9% vs 83.7% (paper)
OSWorld-Verified: 79.6% vs 72.7% (benchmark paper, verified refresh)
CyberGym: 83.1% vs 66.6% (paper)

Some of those gains are moderate. Some are not.

The biggest story here is not GPQA. Going from 91.3% to 94.6% on a hard science benchmark is real, but it is not the part that should reset your mental model.

The bigger story is the cluster:

big jump on harder software engineering benchmarks
big jump on terminal work
big jump on cybersecurity reproduction
decent jump on computer use

That cluster fits the release decision. Anthropic is not behaving like it trained a nicer chatbot. It is behaving like it trained a stronger software operator.

There are two caveats worth keeping in your head the whole time:

First, these are mostly vendor-reported numbers.

Second, Anthropic itself notes possible memorization concerns on Humanity’s Last Exam, and says it ran memorization screens on the SWE-bench family. So these results are informative, but they are not sacred tablets.

The cyber claims are the real headline

The most striking claims are not the benchmark tables. They are in Anthropic’s cyber writeup.

Anthropic says Mythos can identify and exploit zero-day vulnerabilities across major operating systems and browsers. More concretely, it gives several examples:

a 27-year-old OpenBSD bug (Anthropic links a now-patched advisory path)
a 16-year-old FFmpeg vulnerability (fixes landed in FFmpeg 8.1 among others)
a 17-year-old FreeBSD remote code execution bug triaged as CVE-2026-4747
multiple exploit chains in the Linux kernel (one commit Anthropic cites is e2f78c7ec165)

The numbers in the writeup are even more eye-catching than the examples.

Anthropic says that when it re-ran a Firefox 147 exploit-development benchmark, Opus 4.6 produced working exploits only 2 times out of several hundred tries, while Mythos produced working exploits 181 times and got register control 29 more times.

It also says that on roughly 7000 entry points from the OSS-Fuzz corpus, earlier models mostly topped out at low-severity crashes, while Mythos got 595 crashes at tiers 1 and 2, a handful at tiers 3 and 4, and 10 full control-flow hijacks at tier 5.

If those numbers are broadly right, then the right frame is not “AI is helping with security now.” The right frame is “the cost of searching for serious bugs may be dropping fast enough to change who finds them first.”

That is the scary part and the exciting part at the same time.

Anthropic’s argument is that defenders should still win in the long run, because the same models that find bugs can also patch them, review code, and harden systems at scale. I think that is probably right over a long enough time horizon. But the transition could still be ugly. If model capability improves faster than patching pipelines, testing infrastructure, and boring institutional response, attackers get a window. Anthropic follows coordinated vulnerability disclosure for what it finds; the question is whether the rest of the ecosystem can absorb the pace.

That seems to be exactly what Anthropic is worried about.

So where does Mythos fit on AGI timelines?

This is where people start overclaiming.

Dario Amodei has been publicly arguing that we are near “the end of the exponential” and that something like a “country of geniuses in a data center” could show up on a 1-3 year horizon, with very high confidence on a 10-year view. You can hear it in the Dwarkesh Patel interview and the YouTube recording. If you read those comments in 2024, they sounded to many people like frontier-lab chest beating. In 2026, Mythos makes them sound more grounded, though still not settled.

The strongest evidence for near-term AGI has never been “the model got a little better at trivia.” It is the idea that models keep getting better at economically real, verifiable, tool-using work. Software is the cleanest example because code lives in text, terminals, test suites, logs, diffs, and reproducible environments. It is exactly the kind of world language models can inhabit.

On that front, Mythos is a bullish datapoint.

But it is not a complete one.

The cleanest outside metric we have for long-horizon autonomy is still METR’s task-completion time horizon. They explain the methodology in Measuring AI ability to complete long tasks and the underlying paper. METR currently has public numbers for Opus 4.6, which lands around 14.5 hours at the 50% success level on its updated benchmark. That is already a big deal. It is well above where frontier models were not long ago.

The problem is that we do not have a public METR score for Mythos.

So if someone tells you Mythos proves week-long autonomous software work is here, they are getting ahead of the evidence. The honest answer is narrower:

Mythos strongly suggests the current curve is still moving
Mythos strengthens the case that software and cyber will keep going first
Mythos does not yet close the loop on broad autonomous work the way a fresh METR score would

For a different slice of “autonomy,” RE-Bench looks at ML research engineering tasks; it is a reminder that “long horizon” means different things in different domains. METR’s review of Anthropic’s Opus 4.6 sabotage risk report is also worth reading if you care how third parties stress-test lab risk narratives.

Are we accelerating, or just staying on pace?

My answer is: both, depending on the slice.

On broad reasoning, Mythos looks like strong continued progress. GPQA, HLE, BrowseComp, and OSWorld all improve, but they do not scream “new paradigm.”

On agentic coding and cyber, Mythos looks more like acceleration.

That distinction matters. A lot of the public AGI argument gets confused because people average together very different capability domains. If you average everything into one vibe, you miss what is actually changing first.

The sharpest thing to say is this:

Mythos looks ahead of the previous pace where the real world is easiest to score and easiest to monetize: coding, terminals, exploit generation, bug finding, and computer-use loops.

That does not mean the whole AGI debate is over. It does mean the “maybe models are kind of plateauing” story is getting harder to tell with a straight face, at least for software-adjacent work.

Still, I would not call Mythos a clean discontinuity yet. It looks more like a steepening continuation of the same story we have been watching since agentic coding started to feel real.

Anthropic’s Economic Index shows coding and API automation still dominating real usage; the January primitives report ties task success to estimated human time in ways that rhyme with METR’s story. None of that is Mythos-specific, but it is context for why software-shaped benchmarks keep biting first.

A few things you might care about

The first is benchmark saturation.

Anthropic says Mythos now saturates enough older cyber evaluations that it has shifted toward real-world zero-day discovery. Cybench (paper) is the kind of CTF-style suite labs have used to track this; when models stop separating on familiar suites, the action moves to messier targets. That is a bigger deal than another leaderboard shuffle.

The second is friction-based defense.

Anthropic explicitly argues that some defenses work mainly by making exploitation tedious, not impossible. That matters because tedious work is exactly what you can throw cheap, parallel model runs at. If a mitigation’s main virtue is “this would take a human exploit developer a long weekend,” that mitigation may age badly.

The third is memory-safe triumphalism.

Mythos reportedly found bugs not only in classic C and C++ targets but also in “memory-safe” systems where unsafe boundaries still existed. Anthropic points to a critical Botan TLS issue as one cryptography-library example. That is not an argument against memory-safe languages. It is an argument against thinking language choice makes security easy. The interesting security question is moving from “does this code use Rust?” to “where are the unsafe seams, protocol assumptions, and logic gaps?”

The fourth is the bottleneck shift.

If models get much better at bug discovery than organizations get at patch validation, rollout, and incident response, the limiting factor stops being finding problems. It becomes operations. Software teams may soon drown less in unknown bugs than in known bugs they cannot fix fast enough.

My take

Claude Mythos does not prove AGI.

It does not prove ASI.

It does not even prove Anthropic’s strongest cyber claims in the sense a fully independent public evaluation would.

But it does look like the first recent model where the vendor’s own behavior changed in a way that is more informative than the benchmark gains. Anthropic is telling us, through its release choices, that it thinks the cyber jump is real enough to warrant a different deployment regime.

That is the part I would take seriously.

If you only look at Mythos as “Opus plus some benchmark uplift,” you miss the main story. The main story is that software security may be entering the phase where scaled model search beats a lot of human intuition, human patience, and older defensive habits.

And if that is true, then Mythos is less a product launch than a warning shot.

How time-lock puzzles work

Mon, 30 Mar 2026 00:00:00 GMT

The core idea behind a time-lock puzzle is simple: hide a secret behind a computation that has to be done in order, one step after another.

That sounds easy until you ask the real question: what kind of computation stays slow even if the attacker has a lot of hardware?

The best practical answer so far is to use a mathematical setting where the obvious shortcut is hidden. The classic version uses RSA-style repeated squaring. The main alternative uses class groups.

The short version is that time-lock puzzles are about forced waiting by computation. You publish something now, but nobody should be able to open it until they have done a long chain of sequential work.

Explain it like I’m five

Imagine I lock a note in a box.

But this is a strange box.

It does not open with a key. It opens only after you turn a crank 10 million times.

The catch is that the box only counts turns if you do them one after another. You cannot hire 1,000 people to each do 10,000 turns at the same time. The box ignores that trick.

A time-lock puzzle is the math version of that box.

You take a secret, lock it behind a long chain of steps, and publish the locked version. Anyone can open it eventually, but only after doing the steps in order.

That is the whole idea.

The rest of the article is about the hard part: how to build a mathematical box that really behaves like that.

What a time-lock puzzle is trying to do

Suppose Alice wants to publish an encrypted message now that should only become readable after roughly one week of computation.

She does not want to trust a server to release a key next week.

She wants the delay to come from math itself.

So the puzzle needs two properties:

It should be fast to create.
It should be slow to solve, even for someone with parallel hardware.

That second point is the hard part. A lot of cryptographic work is expensive, but still parallelizable. If I can split the work across 1,000 machines, it is not a good time-lock puzzle.

The ideal puzzle forces a long chain of steps where step i+1 depends on the output of step i. No shortcuts. No broad parallel speedup.

That is why time-lock puzzles are closely related to later ideas like verifiable delay functions, or VDFs. A VDF is basically a delay function with a cheap proof that the output is correct. Time-lock puzzles came first. VDFs cleaned up the idea and made it easier to use in protocols.

What people use them for

The original 1996 paper already gave some practical examples:

sealed-bid auctions, where bids should stay secret until bidding closes
voting and contract-signing style protocols, where early disclosure would be unfair
timed release of private material, like a diary, archive, or message meant for the future
delayed access in escrow-like systems

Modern papers add a few more:

timed commitments
public randomness systems
blockchain protocols that need a source of delay nobody can cheaply skip

Some of these are more common in research papers than in mainstream products. That is worth saying plainly. Time-lock puzzles are influential, but they are still more common as a cryptographic building block than as a feature ordinary users interact with every day.

The classic RSA construction

The original practical construction comes from Rivest, Shamir, and Wagner’s 1996 paper on time-lock puzzles and timed-release crypto.

The basic trick is elegant.

Start with an RSA modulus N = p * q. The puzzle creator knows p and q, so they know phi(N). Everyone else only sees N.

Now pick some base a, and define the hard part of the puzzle as:

a^(2^T) mod N

Here T is the delay parameter. If T is huge, the obvious way to compute this is to square a mod N, then square the result, then square again, for T rounds.

That is the sequential chain:

a -> a^2 -> a^4 -> a^8 -> ... -> a^(2^T) mod N

The puzzle setter can cheat, in the good sense, because they know phi(N). They can reduce the exponent modulo phi(N) and compute the final answer quickly. A solver who does not know the factorization of N is believed to be stuck doing the long chain of squarings.

So the sender does this:

Generate a symmetric key k.
Encrypt the message with k.
Hide k using the value a^(2^T) mod N.
Publish the puzzle.

Anybody can eventually recover k, but only after doing about T sequential squarings.

This is the original time-lock puzzle in one sentence: hide the key behind repeated squaring in an RSA group, where the setter knows a shortcut and the solver is not supposed to have one.

Why this works at all

RSA is usually introduced as a public-key system. Time-lock puzzles use a different feature.

They use the fact that the multiplicative group modulo N has hidden order if you do not know the factorization of N.

That hidden order is the key idea.

If the solver knew the group order, they could often reduce huge exponents modulo that order and skip the long sequence. The delay would collapse. The reason the RSA puzzle has a chance is that phi(N) is hidden.

This “hidden-order group” view is more useful than thinking “time-lock puzzles use RSA.” RSA is just one concrete way to get a hidden-order group.

Once you see that, a lot of the literature makes more sense:

RSA groups are the classic hidden-order choice.
Class groups are the main non-RSA hidden-order choice.
Known-order groups are usually bad news for generic delay constructions.

The main alternative: class groups

If hidden order is what you want, RSA is not the only option.

The main alternative is the class group of an imaginary quadratic field. That phrase sounds much scarier than the high-level idea.

You can think of class groups here as another algebraic setting where:

the group order is hidden
repeated operations can still be computed
there is no need to generate an RSA modulus with secret factors

That last point is the big selling point.

RSA-based delay systems usually need a trusted setup story. Someone has to generate N = p * q, and if they keep p and q, they keep the shortcut forever. Class groups avoid that particular trust problem. That is a big reason they became attractive in the VDF literature, and surveys like this one from CWI treat them as one of the main practical hidden-order candidates.

The tradeoff is that class-group arithmetic is less familiar and usually less mature in engineering terms than plain modular arithmetic modulo an RSA integer.

So the practical picture today is roughly:

RSA groups are simple and well understood, but setup is touchy.
Class groups avoid trusted RSA setup, but they are more specialized.

A quick note on elliptic curves

Since this is a common question: standard elliptic-curve groups are usually not where classic time-lock puzzles come from.

The short reason is that their group order is known, which tends to destroy the kind of “no shortcut” behavior these puzzles need. There is theory behind that, including Rotem, Segev, and Shahaf’s 2020 result on hidden-order groups.

There are still curve-related delay constructions in the literature, especially around isogenies and hyperelliptic curves. For example, there is a line of work on VDFs and delay encryption where the slow step is walking through a long chain of isogenies rather than doing repeated squaring in a hidden-order group, including this hyperelliptic-curve paper.

But that is a different world from ordinary ECC. It is better to think of those as alternative delay constructions, not as a simple drop-in replacement for the original RSA-style puzzle.

Other directions in the literature

Once the original RSA puzzle existed, researchers pushed in a few directions.

One line asked whether time-lock puzzles can be built from broader assumptions, such as randomized encodings or random oracles. Some of that work is mostly theoretical. It helps explain what is possible in principle, but it has not displaced hidden-order groups in practice.

Another line focused on security models. Katz, Loss, and Xu’s 2020 paper studies the security of time-lock puzzles and timed commitments more carefully, including the classic sequential-squaring assumption.

Another line focused on verifiability. A plain time-lock puzzle tells you “wait and solve.” A VDF adds an efficient way to verify that the solver’s output is right. That is why VDFs became popular in decentralized systems, randomness beacons, and blockchain protocol design.

And very recent work keeps adding features, like verifiable time-lock puzzles, where the solver can know in advance that the thing they will eventually reveal is actually useful.

The basic architecture, though, has not changed that much:

get a sequential process
avoid shortcut structure
preferably make verification cheap

Hidden-order groups still sit near the center of that story.

The annoying part: “time” is only approximate

Time-lock puzzles do not measure wall-clock time directly. They measure how long a particular sequential computation takes on available hardware.

That means the “unlocks in 7 days” story is always approximate.

A faster machine will solve earlier. A slower machine will solve later. Hardware progress changes the estimate. Specialized implementations can change it too.

This is one reason trusted-release systems still exist. If you need a message to open at exactly 09:00 UTC next Tuesday, pure time-lock puzzles are awkward. If you want “this should take a lot of sequential work and no one should be able to shortcut it cheaply,” then they are much more natural.

My take

The cleanest way to understand time-lock puzzles is this:

They are a search for sequentiality without trust.

The original RSA puzzle works because hidden order blocks the obvious exponent shortcut. Class groups matter because they give you hidden order without RSA setup. That is the conceptual center of the field.

For classic time-lock puzzles, the real dividing line is not old crypto versus new crypto. It is hidden order versus known order.

Hermes vs OpenClaw: what should you actually start with?

Mon, 23 Mar 2026 00:00:00 GMT

If you want the short answer first, here it is:

Most people should start with OpenClaw. Pick Hermes instead if you care more about learning over time, stronger safety rails, and running the agent in a cleaner sandboxed environment.

That is the honest answer after looking at the official OpenClaw docs, the official Hermes docs, the public discussion, and the benchmark material.

OpenClaw is easier to recommend as the default because it has a much larger community, much more visible real-world usage, and a more mature “message your agent from anywhere” product shape. Hermes is the more interesting design if you want an agent that builds memory and reusable skills as it works, and if you want a security model that feels more deliberate out of the box.

The mistake is thinking one of them simply crushes the other.

They are close enough that your starting point should depend less on hype and more on the kind of agent you want to live with.

What they are, in plain English

OpenClaw is a self-hosted AI assistant gateway. You run it on your own machine or server, connect it to chat apps like WhatsApp, Telegram, Discord, Slack, or iMessage, and it becomes an always-available assistant you can message like a person. Its docs frame it as your own personal AI assistant, and that is the right mental model.

Hermes Agent, from Nous Research, is also a self-hosted AI agent you can talk to through chat and other interfaces. The big difference is what it emphasizes. Hermes is built around a learning loop. It tries to remember useful things, turn repeated work into reusable skills, and get better over time instead of just executing the next prompt well.

So the simplest framing is this:

OpenClaw is more gateway-first and product-first.
Hermes is more agent-first and learning-first.

That difference shows up everywhere else.

What OpenClaw is better for

OpenClaw is the better starting point if you want an assistant that feels real quickly.

Its strengths are pretty straightforward:

huge community and momentum
lots of examples, tutorials, and public discussion
strong support for messaging-first workflows
a simple mental model: one self-hosted assistant you can reach from your normal chat apps
a public benchmark, PinchBench, that tests models inside an OpenClaw-style runtime instead of only in abstract evals

That last point matters more than it sounds. Most AI benchmarks measure the model in isolation. PinchBench measures how models behave while doing actual OpenClaw tasks such as file work, data tasks, web research, memory use, and tool calls. That does not prove OpenClaw is “better” than Hermes, but it does mean OpenClaw has a more visible performance culture around real usage.

There is also a social proof effect here. Public conversations around OpenClaw are no longer just demos. People are describing real team workflows with it in shared chats, daily digests, standups, monitoring, and lightweight operations work on Hacker News. That is usually a sign a tool has crossed from novelty into habit.

If your goal is:

“I want a personal or team AI assistant I can message from anywhere”
“I want the bigger ecosystem”
“I want the most obvious place to start this weekend”

then OpenClaw is the better fit.

Where OpenClaw is weaker

The biggest issue is security posture.

OpenClaw’s own security docs are clear that it is designed around a personal-assistant trust model, not a hostile multi-tenant environment. In plain English, it assumes the people and systems around one gateway mostly trust each other. That is reasonable for a personal assistant. It is a much shakier fit if you want strong separation between unrelated users, risky credentials, or loosely controlled team access.

There is also a pattern in public discussion that is worth taking seriously: people love what OpenClaw makes possible, but some are tired of rough edges, bugs, and the sheer amount of authority these agents can get if you are not careful.

So the cons are not subtle:

its power can outrun its safety if you expose it carelessly
it is easier to treat like a shared bot than it really should be
some users still see it as rough around the edges
the benchmark story is stronger than the safety story

If you are the kind of user who always asks “what is the blast radius if this goes wrong?”, OpenClaw should make you pause before it makes you excited.

What Hermes is better for

Hermes is better when you want the agent itself to improve, not just answer.

According to the official docs, Hermes has a built-in learning loop, persistent memory across sessions, autonomous skill creation, skill self-improvement, and a deeper user model. That is the core bet. Instead of giving you one smart assistant that stays roughly the same, Hermes tries to become more useful the longer it runs.

That can be a big deal if your use case looks like this:

repeated research tasks
recurring ops work
long-running personal workflows
workflows where remembering your preferences actually matters

Hermes also looks better on security design.

Its security docs describe a defense-in-depth model with several layers: user authorization, approval for dangerous commands, container isolation, MCP credential filtering, and context-file scanning for prompt injection. It also supports more clearly isolated execution backends such as Docker, Modal, Daytona, Singularity, SSH, and local execution.

That does not make Hermes magically safe. No agent with tools is magically safe. But the design is more obviously trying to narrow the damage when things go wrong.

If your goal is:

“I want the agent to build up memory and reusable skills”
“I care a lot about sandboxing and operational control”
“I am comfortable with a smaller ecosystem in exchange for a stronger architecture”

then Hermes becomes very compelling.

Where Hermes is weaker

The clearest drawback is ecosystem maturity.

Hermes looks promising, but it is still much smaller in public adoption than OpenClaw. The GitHub gap alone is large. OpenClaw is sitting above 330k stars. Hermes is a little above 10k. Star counts are not truth, but they do tell you where the docs, examples, integrations, community habits, and troubleshooting gravity are likely to be.

The second drawback is that Hermes is easier to admire than to verify.

Its learning loop is a strong idea. Its environment and benchmark tooling are serious, as shown in the benchmark framework docs. But there is much less public evidence showing a clear, widely accepted leaderboard or a large body of third-party production stories proving that Hermes consistently beats the alternatives in day-to-day use.

That means the Hermes case is partly conceptual right now. You are buying into the design, not just the size of the installed base.

The tradeoff is simple:

Hermes looks more thoughtful
OpenClaw looks more proven

For many buyers, that single contrast is the whole decision.

What people seem to be recommending

The public recommendation pattern is surprisingly consistent.

People reach for OpenClaw when they want an assistant that lives in chat, works across channels, and feels immediately usable. The most enthusiastic OpenClaw users are not talking about abstract agent theory. They are talking about having an AI teammate in a group chat, letting it run daily standups, summarize work, watch competitors, or help with internal tasks.

People who lean toward Hermes tend to want something a bit more disciplined. The appeal is less “look what I can wire into WhatsApp tonight” and more “I want an agent that remembers, improves, and runs inside a setup I can reason about.” Even the small Hacker News thread on Hermes leans in that direction.

That is a useful clue.

OpenClaw is what people recommend when they want momentum and usability.

Hermes is what people recommend when they are a little more skeptical, a little more security-conscious, or a little more interested in the long-term shape of the system.

What the benchmarks are actually saying

This is where a lot of comparisons get muddy.

There is no clean, universal public benchmark that says ”Hermes scored 82 and OpenClaw scored 78, case closed.”

That is not how this market works yet.

Here is the honest version:

OpenClaw has the more visible product-native benchmark story today because of PinchBench. That benchmark tests models inside real OpenClaw-style tasks, and the current leaderboard shows strong frontier models such as NVIDIA Nemotron-3-Super-120B, Claude Opus 4.6, and GPT-5.4 performing well in that environment.

Hermes has something different. Its docs show a serious benchmark and training framework with support for evaluations like TerminalBench2, TBLite, and YC-Bench. That tells you Hermes is built by people who care about agent evaluation. But it is more an evaluation harness than a single public scoreboard that settles the product comparison for you.

So the benchmark takeaway is:

OpenClaw has better public evidence for “which model works well inside this runtime?”
Hermes has better public evidence for “this project takes agent training and evaluation seriously”
neither benchmark story cleanly proves one product is the universal winner

That may sound unsatisfying, but it is actually useful. It keeps you from asking a benchmark to answer a product question it cannot really answer.

So what should you start with?

If you want one recommendation, here it is:

Start with OpenClaw unless you already know you want Hermes’ learning loop and security posture.

That is the best default for most technical users.

Because the first thing most people need is not the most elegant agent architecture. They need an agent they can get running, understand, and use. OpenClaw wins there. It has more momentum, more examples, more discussion, and a clearer path from installation to “this is actually useful.”

But the exception matters.

If you are the sort of person who immediately worries about command approval, container boundaries, prompt injection through context files, or whether the system gets better after a month of real work, then skip the default and start with Hermes.

That is not a niche concern. It is a real one.

The simplest decision rule

Use this and move on:

Start with OpenClaw if you want the fastest path to a useful self-hosted assistant in chat apps.
Start with Hermes if you want a more opinionated, learning-oriented, safety-conscious agent stack.

If you still cannot decide, that usually means you should start with OpenClaw.

It is the lower-friction bet.

And if you outgrow it, you will know exactly why you are moving.

What is the best agentic AI today?

Fri, 20 Mar 2026 00:00:00 GMT

Agentic AI is getting crowded fast.

One week everyone is talking about OpenClaw. The next week it is NVIDIA NemoClaw. Then someone insists the real answer is LangGraph, or OpenHands, or just “pick the best model and build the rest yourself.”

The useful answer is simpler than that noise makes it sound:

There are real leaders right now. You just have to be clear about which layer you mean.

If you want a self-hosted personal assistant you can text from your phone, OpenClaw is the strongest product in that category today. If you want the same basic idea with tighter security controls, NVIDIA NemoClaw is the most interesting next step, but it is still early and NVIDIA says not to use it in production yet. If you are building a production system, the best default is still a strong model inside a more controlled orchestration layer such as LangGraph.

That is not a cop-out. It is the market taking shape.

The first thing to understand

When people talk about the “best agent,” they often mix together three different layers:

The product or runtime you install and use, such as OpenClaw, NVIDIA NemoClaw, OpenHands, or OpenCode.
The orchestration framework used to build agent systems, such as LangGraph, AutoGen, or CrewAI.
The model doing the reasoning, such as GPT-5.4, Gemini 3.1 Pro, or Claude 4.6.

Those are not the same thing.

It is also worth separating two NVIDIA names that people keep blending together. NemoClaw is NVIDIA’s sandboxed agent stack. Nemotron is NVIDIA’s model family. One is the runtime. The other is the brain.

OpenClaw is not trying to solve the exact same problem as LangGraph. GPT-5.4 is not an agent product by itself. And a lot of bad comparisons come from throwing all three layers into one bucket.

Once you separate them, the space becomes much easier to read.

The short answer

If you want the practical version, here it is:

OpenClaw is the best self-hosted personal agent platform right now.
Pi, the compact agent core inside OpenClaw, is a big reason it works as well as it does.
NVIDIA NemoClaw is the most interesting security-focused evolution of that idea, but it is still alpha software.
LangGraph is the best default framework for teams building serious production agent systems.
GPT-5.4 currently looks like the strongest all-around model for agent-style tasks on several current benchmarks.
Gemini 3.1 Pro is extremely close and often looks especially strong on coding-heavy tasks.
NVIDIA Nemotron-3-Super-120B deserves to be in the top-tier model conversation because it is currently leading OpenClaw’s own real-world benchmark.
The strongest systems on some agent benchmarks are already hybrid systems that route across multiple models rather than relying on one model for everything.

That is the state of play.

Why OpenClaw matters

OpenClaw matters because it made the personal-agent pitch feel real.

Its core pitch is simple: connect AI agents to messaging apps like WhatsApp, Telegram, Discord, and iMessage so you can talk to your agent the same way you talk to a person. The official OpenClaw docs describe it as a self-hosted gateway for always-available assistants across chat apps, mobile nodes, and a web control UI.

It also helps that OpenClaw is not built around a giant mystery box. Its agent core is Pi, a deliberately compact runtime documented in the Pi integration docs. You can feel that design choice. A lot of agent products get worse as they pile on tools, prompts, and layers of abstraction. Pi goes the other way: keep the core small, make tool use explicit, and let the model do the work. That is a big reason OpenClaw feels more usable than a lot of “look what my agent did” demos.

That product shape is a big part of why it exploded. Based on the current GitHub page and docs footprint, it has already reached roughly 328k stars and 63k+ forks. For a category this young, that is a huge signal.

The appeal is obvious:

it is self-hosted
it works through familiar chat apps
it feels like a personal assistant, not just another chatbot tab
it supports tools, sessions, routing, and multi-agent setups

For a lot of people, OpenClaw is the first agent system that feels like software they might actually leave running instead of a demo they try once.

Why people are still nervous about OpenClaw

The excitement is real. So are the concerns.

OpenClaw’s own security overview is unusually direct about its trust model. It says OpenClaw is built around a one-user trusted-operator model, not a shared multi-tenant boundary. It also notes that host-side execution is the default unless sandboxing is enabled.

This is not a footnote. It means OpenClaw makes the most sense when one trusted person is running it for themselves, or when a team has very clear trust boundaries. It is a much worse fit for “let’s expose this casually and let lots of unrelated people use it.”

That matches what people are saying in public discussions. Recent Hacker News discussion around OpenClaw’s growth shows a mix of admiration and skepticism. Some people see it as the first real app layer for personal AI. Others keep asking whether many of these workflows could still be handled with scripts, automations, or simpler tools.

There is also a serious conversation around exposed instances, risky skills, and over-broad permissions. That is not anti-innovation. It is what happens when a product becomes powerful enough to matter.

What NVIDIA NemoClaw is trying to fix

If OpenClaw made self-hosted personal agents feel exciting, NVIDIA NemoClaw is trying to make them feel less reckless.

NVIDIA announced NemoClaw in March 2026 as an open-source stack that runs OpenClaw inside OpenShell, NVIDIA’s runtime for policy-based isolation and controlled inference routing. The official NVIDIA announcement and developer docs make the idea clear: keep the OpenClaw experience, but add tighter guardrails around what the agent can touch.

The most important technical detail is in NemoClaw’s network policy docs. The sandbox is strict-by-default. If the agent tries to reach an endpoint that is not explicitly allowed, the request gets blocked and the operator has to approve it.

That is a real improvement over the more permissive self-hosted setups people have been using.

NemoClaw also narrows filesystem access and makes the operator approval flow much more visible. In plain English, it is trying to put a real safety layer between “the agent wants to do something” and “the host lets it happen.”

Still, the project is early. NVIDIA’s own docs label it alpha software and say not to use it in production yet.

People gloss over that point all the time in AI infrastructure. NemoClaw is promising, but it is still firmly in watch-this-space territory.

So is it OpenClaw or NemoClaw?

Right now, the practical answer is:

pick OpenClaw if you want the best self-hosted personal assistant experience today
watch NemoClaw if you care deeply about security posture and want to see where the category is going next

OpenClaw is more usable today. NemoClaw has the better long-term shape if NVIDIA executes.

There is a deeper point here. Sandboxing helps, but it does not solve the hardest problem in agentic AI. If you hand an agent access to your email, browser, GitHub, files, calendar, and internal systems, the hard question is no longer just “is it sandboxed?” It is “what authority did I just hand over?”

That is why the best discussions around agents are no longer about clever demos. They are about permissions, scope, trust boundaries, and failure modes.

The real “something else” answer

For many technical teams, the best agentic solution right now is not OpenClaw or NemoClaw at all.

It is a good model inside a well-controlled orchestration layer.

That is where tools like LangGraph, AutoGen, and CrewAI come in.

LangGraph stands out because it is explicit about the boring but crucial parts of agent systems: state, long-running execution, human review, memory, and observability. Those are the things that start to matter once an agent has to do real work over and over instead of just looking impressive in a short video.

AutoGen is still strong for conversational and event-driven multi-agent applications, especially for teams that want a programmable framework with a lot of flexibility.

CrewAI is still appealing when people want role-based multi-agent collaboration or a more approachable way to prototype “a crew” of specialized agents.

Then there are tools like OpenHands and OpenCode, which are more focused on coding workflows. If your real use case is software development rather than general personal assistance, those may matter more than either OpenClaw or NemoClaw.

If you are building an agent product that has to run reliably, stay debuggable, and survive contact with real users, LangGraph is the best default choice today.

What the benchmarks say about the best model

The model question is separate from the platform question, and current benchmarks make that obvious.

According to the current Artificial Analysis Intelligence Index, Gemini 3.1 Pro Preview and GPT-5.4 (xhigh) are tied at the top with a score of 57.

On Terminal-Bench Hard, which is one of the more useful public benchmarks for agent-like terminal behavior, GPT-5.4 (xhigh) leads with 57.6%, followed by Gemini 3.1 Pro Preview at 53.8%, then GPT-5.3 Codex (xhigh) at 53.0%.

On GDPval-AA, which evaluates real-world work tasks with shell and browser access, GPT-5.4 (xhigh) leads with an ELO of 1667, followed by Claude Sonnet 4.6 at 1633, then Claude Opus 4.6 at 1606.

On LiveCodeBench, Gemini 3 Pro Preview leads with 91.7%, followed by Gemini 3 Flash Preview (Reasoning) at 90.8%, then DeepSeek V3.2 Speciale at 89.6%.

If you care specifically about how models behave inside OpenClaw, a different benchmark matters even more. On PinchBench, which evaluates real OpenClaw tasks with tools and grading logic exposed, NVIDIA Nemotron-3-Super-120B currently leads the average leaderboard at 84.7%, ahead of Claude Opus 4.6 at 80.8%, GPT-5.4 at 80.5%, and Kimi K2.5 at 80.1%.

The practical read is pretty clear:

GPT-5.4 currently looks like the strongest all-around agent brain
Gemini 3.1 Pro is right there with it and often looks especially strong for coding
Claude 4.6 remains one of the safest strong choices for careful tool use and developer work
NVIDIA Nemotron is no longer a side note. If your agent actually lives inside an OpenClaw-style runtime, it looks like one of the strongest options on the board

If you want one model and do not want to overthink it, GPT-5.4 is still the safest default. If you care most about OpenClaw-specific benchmarking, Nemotron-3-Super-120B deserves serious attention.

The strongest agents are already hybrid

One benchmark result matters more than many readers realize.

On the GAIA leaderboard, some of the top-performing systems are not simple one-model agents. The top score shown right now is 92.36%, achieved by systems like Manus_v0.0.112221 and OPS-Agentic-Search, and both use a mix of frontier models rather than a single model for every step.

It hints at where the state of the art is going.

The best agent may not be one brilliant model with tools. It may be a system that knows when to route coding work, search work, planning work, or summarization work to different models.

That is harder to build. It is also where the serious end of the market is headed.

What it costs to run OpenClaw for a month

There are two costs here: the machine that keeps the agent online, and the model tokens the agent burns through.

For hosting, the runtime itself is cheap:

an existing Mac mini usually costs only about $3 to $10 a month in electricity
if you want to count hardware too, a Mac mini amortized over two years is more like $30 to $50 a month all-in
a small Hetzner VPS is usually about $5 to $20 a month

The model bill is what actually moves.

For a single-user agent that chats with you throughout the day, does a bit of web work, and sends one daily digest, a reasonable monthly assumption is roughly 3M input tokens and 600k output tokens for light use, or 15M input and 3M output for moderate use.

Using current public pricing, that comes out to roughly this:

MiniMax 2.5: about $2 light or $8 moderate
Kimi K2.5: about $4 light or $18 moderate
GLM-5: about $5 light or $25 moderate
Gemini 3.1 Pro: about $13 light or $66 moderate
GPT-5.4: about $17 light or $83 moderate
Claude Sonnet 4.6: about $18 light or $90 moderate

So the budgeting rule is pretty simple:

budget setup: MiniMax 2.5, Kimi K2.5, or GLM-5 on a small VPS, usually lands around $10 to $40 a month all-in
quality-first setup: GPT-5.4, Gemini 3.1 Pro, or Claude 4.6, usually lands around $25 to $110 a month all-in
if you already own the Mac mini, the hosting cost is almost irrelevant and the model choice dominates the bill

Mac mini or Hetzner VPS?

This is not the main story, but it matters if you actually want to run one of these systems.

A Mac mini is a strong choice if you want:

local privacy
low power use
easy access to your own apps and files
a machine that feels personal rather than server-like

A Hetzner VPS makes more sense if you want:

24/7 uptime
remote availability from anywhere
a clean host dedicated to the agent
easier separation from your personal daily machine

The simple rule:

use a Mac mini if the agent is mainly for you
use a VPS if the gateway needs to stay online all the time and you are comfortable administering it

OpenClaw’s own trust model pushes in the same direction. One trusted user per machine or VPS is a much cleaner setup than trying to share a powerful agent runtime loosely across mixed-trust users.

A simple Hacker News digest workflow

One nice thing about modern agent platforms is that useful workflows do not have to be complicated.

For example, Top HN Daily Digest is exactly the kind of source an always-on personal agent should handle for you.

The right way to handle this is to give the agent a standing instruction like this:

Every day at 8:00 AM local time, fetch https://hn.alcazarsec.com/daily and send me a short briefing. Focus on stories relevant to my work in AI, developer tools, startups, and security. Include the 5 most relevant stories, one sentence on why each matters, one repeated theme across the day, and one link I should definitely read in full. Ignore off-topic stories unless they are unusually important. If the page is unavailable, retry in 30 minutes.

That is much closer to the real value of an agent. You set the rule once, and it keeps doing the job.

This is not just a US trend

One thing casual readers miss is how global this shift already is.

In China, several of the strongest public benchmark submissions on GAIA come from teams connected to companies like Alibaba Cloud, JD Enterprise Intelligence, Lenovo, and CMCC. That points to a serious push at the enterprise and systems level, not just consumer curiosity.

In Japan, the conversation already looks implementation-focused. A reported summary of AI Agent Day 2026 says the event drew 3,710 registrations, with 38% of attendees coming from large enterprises and 36% being decision-makers. The same report says the biggest themes were business efficiency and security or privacy.

In Europe, the frame is different again. The European Commission’s AI Act overview is not a direct agent benchmark, but the broader regulatory context is pushing teams to think more seriously about governance, risk, and documentation when they deploy AI systems. Self-hosting is attractive there, but it does not remove compliance obligations by itself.

In the US, the debate is louder and more polarized. You can see that in Hacker News discussions about OpenClaw, where some people see agentic software as the start of a new application layer, while others see a lot of hype wrapped around workflows that could still be handled with scripts or ordinary automation.

That tension is real. It is also healthy.

The honest conclusion

If the question is “what is the best agentic AI solution right now?”, here is the cleanest answer:

For personal self-hosted use, OpenClaw is the leader. For a more security-focused self-hosted direction, watch NemoClaw. For production systems, use a strong model inside a controlled orchestration stack and default to LangGraph unless you have a reason not to. For models, start with GPT-5.4, keep Gemini 3.1 Pro close behind it, and take Nemotron seriously for OpenClaw-native workloads.

That is where the evidence points today.

The category is being shaped by four things at once:

better models
better tools and runtimes
better security discipline
better understanding of where agents are actually useful

Benchmark scores will not decide this by themselves.

The winners will be the systems that combine strong models, useful interfaces, safe defaults, and enough product discipline to earn trust in the real world.

Wide logging: Stripe's canonical log line pattern

Mon, 16 Mar 2026 00:00:00 GMT

Most logging is too narrow.

One line has the route. Another has the user. Another has the timeout. Another has the feature flag. Another has the deploy SHA.

Then an incident happens and you end up doing joins by hand.

Stripe’s answer is canonical log lines. The modern name is usually wide events. The pattern is simple: emit one structured record per unit of work with all the important fields already attached.

For a web service, that usually means one log event at the end of every request.

The Pattern

A canonical log line is the summary row for a request.

It should include the fields you always wish you had in one place:

route
method
status
duration
user or account ID
request ID and trace ID
build or deploy ID
feature flags
downstream timings
error code

In raw form it might look like this:

ts=2026-03-16T12:03:41Z service=api env=prod route=/v1/charges method=POST status=500 request_id=req_123
account_id=acct_456 build_id=9f2c1d7 feature_flag.payments_v2=true duration_ms=843 db_ms=792
db_queries=18 cache_hit=false error_slug=charge_db_timeout

This is useful because the log line is already pre-joined. You are not reconstructing a request from fragments. You are querying complete rows.

That sounds minor, but it changes what production debugging feels like.

Why It Works

Stripe did two important things.

First, they treated the canonical line as critical infrastructure. It is emitted after the request finishes, and their implementation is hardened so the line still appears when exceptions happen.

Second, they did not stop at debugging. Stripe pushed these records into warehousing systems and used them for longer-term analysis and product surfaces like the Developer Dashboard.

That is the part many teams miss.

A canonical log line is more than a nicer log. It is a request-shaped data model.

If the schema is stable, the same event can support:

incident response
release analysis
customer support investigations
product analytics

Amazon describes a similar idea in the Builders Library: emit one structured request log entry per unit of work, then derive metrics later. Log first. Aggregate later.

What To Log

Most teams stop too early.

They log route, status, and latency. That is enough for a dashboard, but not enough for diagnosis.

The highest-value fields tend to be:

Route template: /teams/{team_id}/members/{user_id} is better than raw paths with IDs embedded in them.
Identity: user_id, account_id, API key ID, auth method.
Release metadata: Git SHA, build ID, deploy ring, region.
Execution cost: duration, DB time, query count, cache hit or miss, retry count.
Decision inputs: feature flags, experiment variant, plan tier, client version.
Outcome: status code, throttled yes or no, fallback path used, error slug.

Two fields are especially underrated.

The first is build_id. Metrics tell you that latency went up. build_id tells you which deploy owns the regression.

The second is an error_slug. Not just an exception class. A stable identifier for the exact failure site or failure reason.

That is the difference between “timeouts increased” and “the timeout came from the new write path behind feature_flag.double_write.”

The Real Benefit

The real power of wide logging is not observability. It is correlation.

Once every request carries business context and execution context in the same row, you can ask much better questions:

Did the new build hurt only enterprise accounts?
Did the regression appear only on iOS 7.4.1?
Did variant B increase errors only in eu-west-1?
Did the slow requests all miss cache and hit the same downstream service?

Metrics are bad at this because they throw context away early.

Traditional logs are bad at this because the context is scattered.

Canonical log lines keep the context intact long enough to query it.

That is why the pattern keeps coming back under different names.

High Cardinality

This is where people get nervous.

user_id, request_id, build_id, and feature flags are high-cardinality fields. In many systems that is a warning sign.

The important distinction is where the cardinality lives.

High-cardinality values are often fine inside a wide event. They become expensive when you force them into the wrong indexing model.

That is why this pattern works best with systems designed for filtering and grouping over many dimensions. Stripe used Splunk and Redshift. Modern teams might use ClickHouse-backed tools, Honeycomb, BigQuery, or their own warehouse.

The storage choice is less important than the query shape. You want to slice rich rows, not pre-aggregate away the useful parts.

Common Mistakes

Only logging the happy path

The canonical event should be emitted in finally, ensure, or equivalent teardown logic. If it disappears on exceptions, it fails when you need it most.

Logging raw paths instead of route templates

/users/123/orders/456 is terrible for grouping. /users/{user_id}/orders/{order_id} is what you want.

Logging exception classes but not error reasons

TimeoutError is often too broad. An error slug gives you a stable grouping key tied to a real code path.

Dumping raw input into the event

Amazon recommends sanitizing and truncating request details before logging. That is important here. A rich event becomes dangerous fast if you start packing it with tokens, secrets, or arbitrary payloads.

Letting the schema drift

Field names become muscle memory. If one service logs user_id, another logs uid, and a third logs account_user, cross-service queries get messy fast.

Implementation

The usual implementation is middleware.

Create a request-scoped object at the start of the request. Let middleware and business logic add fields as work happens. Emit one structured line at the end.

If you use OpenTelemetry, the root span can play this role. If not, JSON or logfmt is fine.

A good starting schema is:

service.name
env
request_id
trace_id
route
method
status
duration_ms
user_id or account_id
build_id
error_slug
sample_rate

Then add fields whenever a real production question is hard to answer.

Summary

Canonical logging is a simple idea that pays for itself quickly.

Emit one rich, trustworthy event per request. Make it stable. Make it complete. Make sure it still appears on failures.

Once you do that, logs stop being breadcrumbs and start being records.

Whisper is no longer the whole answer: how to transcribe audio and video in 2026

Sun, 15 Mar 2026 00:00:00 GMT

If you asked this a year or two ago, the answer was simple: use Whisper.

That was the right default for a long time. Whisper was open, accurate, multilingual, and strong enough to reshape the category.

It is no longer the whole answer.

In 2026, the best way to transcribe audio or video depends on what “best” means to you:

raw accuracy on messy long-form audio
a local, private setup
real-time latency for voice agents
jargon, diarization, subtitles, or compliance
price at scale

Speech-to-text is a tradeoff market again. No single model wins every category.

The Best Default Strategy

Here is the shortest honest answer:

Start with a local Whisper-family setup if privacy or cost is the priority. On Apple Silicon, also test Parakeet. Use a premium API when transcript quality is critical.

For local, offline, or self-hosted work, use faster-whisper or whisper.cpp.
If you are on a Mac, test parakeet-mlx. It makes NVIDIA’s Parakeet models practical on Apple Silicon, and the uvx parakeet-mlx workflow is refreshingly simple.
For production-grade batch transcription where quality is the priority, look hard at ElevenLabs Scribe v2.
For real-time products, voice agents, and live captioning, look at Deepgram Nova-3, AssemblyAI Universal-3 Pro, or OpenAI’s newer gpt-4o-transcribe.

If that sounds less satisfying than “just use X,” that is because the category matured.

Which Benchmarks Matter Now

Vendor benchmark charts are useful, but they are also self-serving.

The public benchmark I would watch first is Artificial Analysis’ AA-WER v2.0. It is not perfect, but it is one of the better attempts to compare modern transcription quality across different conditions.

Its dataset mix is why it is worth watching:

AA-AgentTalk for speech aimed at voice agents
VoxPopuli-Cleaned-AA for parliamentary speech
Earnings22-Cleaned-AA for long, technical earnings calls

That last set is especially useful. A model can look great on clean speech and still struggle with bad mics, accents, names, finance jargon, cross-talk, or long recordings.

On the current AA-WER v2.0 leaderboard, the top models are:

ElevenLabs Scribe v2 at 2.3%
Google Gemini 3 Pro at 2.9%
Mistral Voxtral Small at 3.0%
Google Gemini 2.5 Pro at 3.1%
Google Gemini 3 Flash at 3.1%

AssemblyAI Universal-3 Pro is also very strong at 3.3%. OpenAI’s gpt-4o-transcribe shows up at 4.1% on that benchmark, and Whisper-derived options are still competitive, but no longer obviously leading.

Two caveats are important.

First, a benchmark is only as good as its audio mix. If you transcribe podcasts, hearings, sales calls, lectures, or YouTube voiceovers, your failure modes will differ from a call-center agent.

Second, open models count for more than leaderboard placement suggests. Whisper still stands out because of the whole package: open weights, mature tooling, local deployment, and an ecosystem that has been heavily optimized.

That is why MLPerf chose Whisper Large v3 as its ASR benchmark. Not because Whisper is best at everything in 2026, but because it is still the shared baseline.

FLEURS Still Counts

FLEURS is also worth watching. It is a multilingual benchmark, and it is useful because many models that look strong in English get worse once you add other languages, code-switching, or regional accents.

OpenAI says its newer audio models beat older Whisper variants on FLEURS and handle accents, noise, and variable speaking speed better. That is plausible, and it matches the broader direction of the market.

But “better than Whisper” is not the same as “best for you.” If you need local transcription on your own machine, gpt-4o-transcribe does not replace the reason most people adopted Whisper.

What Practitioners Are Actually Saying

Benchmarks tell you what models do in a lab. Practitioner discussions tell you what breaks in real use.

The pattern is consistent. In a recent Hacker News thread about transcription tools, people complained that raw Whisper can feel slow. The usual fix was not “stop using Whisper.” It was “use faster-whisper, whisper.cpp, or a better local wrapper.”

That matches real-world use. Many complaints about Whisper are really complaints about the default implementation, not the model family.

The same thread surfaced another pattern: more people now add a cleanup pass after transcription. They transcribe first, then use a cheaper LLM to fix punctuation, domain terms, or code-related oddities. That is a practical modern workflow. The transcription model gets the words down. A text model makes the result readable.

The open-source crowd is also testing alternatives. In another Hacker News discussion, some people said NVIDIA Parakeet beat Whisper for English and speed, while others said Whisper still handled accented meeting audio better. Both can be true. ASR quality depends heavily on the audio you actually have.

Parakeet is especially interesting on Macs because of parakeet-mlx, an Apple Silicon implementation built on MLX. It supports CLI and Python usage, chunking, timestamps, and streaming transcription with a simple entry point. Good local tools win because people actually use them.

This is probably the single most important point in the whole article:

The best transcription model is the one that fails least often on your audio, not the one with the prettiest average score.

So What Should You Actually Use?

Here is the short version I would give a technical friend.

1. If you want privacy, local processing, or no vendor lock-in

Use faster-whisper, whisper.cpp, or on Apple Silicon, parakeet-mlx.

This is still the safest default for:

journalists
researchers
lawyers
internal team recordings
people transcribing sensitive interviews
developers who want a self-hosted pipeline

It is also the best answer if you want predictable cost. You pay for compute, not per minute.

If you are on macOS and want something polished instead of building your own workflow, MacWhisper remains a common recommendation in technical circles.

If you want a local Mac setup that feels modern rather than DIY, add these to the shortlist:

parakeet-mlx if you are happy in the terminal and want uvx parakeet-mlx simplicity.
Hex if you want a practical press-to-talk desktop app. It uses Parakeet TDT v3 by default and is a good example of what “daily-driver local transcription” looks like on Apple Silicon.

2. If you care most about batch accuracy on real media

Use ElevenLabs Scribe v2.

Right now it has the best public accuracy case, and it is clearly built for long-form recordings, subtitles, captioning, diarization, timestamps, and multilingual media pipelines. If I were transcribing podcasts, interviews, webinars, lectures, or a large video archive, this would be one of the first tools I tested.

3. If you are building a live product

Use Deepgram Nova-3 or AssemblyAI Universal-3 Pro.

Here, latency, streaming behavior, diarization, redaction, and structured output count as much as raw WER.

Deepgram has a solid reputation in real-time speech products, and its whole story is built around speed plus production readiness. AssemblyAI is especially attractive when you want transcription plus extras like diarization, entity extraction, PII handling, and downstream speech intelligence.

4. If you want open weights, but something newer than Whisper

Test Mistral Voxtral Small.

It is the open-weight model I would watch most closely right now. On the current Artificial Analysis leaderboard, it is the highest-ranked open-weight option. I would still call it less battle-tested than Whisper, but Whisper finally has a serious open competitor.

If your world is mostly Mac laptops and command-line tooling, Parakeet belongs near this section too. The family has posted strong public numbers and is building a reputation for speed and English performance. The catch is that it is not the same all-purpose multilingual default that made Whisper famous.

5. If you already live in the OpenAI ecosystem

Test gpt-4o-transcribe.

I would not pick it because it is the runaway benchmark leader. I would pick it if I were already building around OpenAI, wanted a simpler vendor stack, and cared about noisy audio, accents, and solid out-of-the-box quality without running my own local infrastructure.

The Real Shift

Whisper did not get bad. It just stopped being the automatic answer to every transcription problem.

Today, the best setup is usually a two-level strategy:

Use a strong local or low-cost model for drafts, privacy, and bulk throughput.
Route important or revenue-critical audio through a premium API tuned for your use case.

That is what mature infrastructure looks like. You do not need one sacred model. You need a sensible policy.

For most technical users, my shortlist would be:

Local and private: faster-whisper
Best Mac terminal setup: parakeet-mlx
Best Mac desktop app: Hex
Best batch media transcription: ElevenLabs Scribe v2
Best real-time product bet: Deepgram Nova-3
Best feature-rich API: AssemblyAI Universal-3 Pro
Most interesting open-weight challenger: Mistral Voxtral Small

If you only remember one thing, remember this:

Whisper is still the baseline. It just is not the whole market anymore.

The best time to post on Hacker News

Sat, 14 Mar 2026 00:00:00 GMT

People ask this question because Hacker News can feel mysterious.

One post gets 600 points. Another disappears in 20 minutes. The natural reaction is to look for the perfect hour, the perfect day, or the perfect headline formula.

There is some truth to that. Timing helps. But not in the clean, deterministic way people want.

The honest answer is:

good posts can die
average posts can catch a wave
timing helps at the margin
the rules and etiquette count for more than most growth advice admits

If you want the short version, here it is.

The Short Answer

For a normal technical post, I would start with Tuesday through Thursday, roughly 14:00 to 17:00 UTC.

That is 7am to 10am Pacific and 10am to 1pm Eastern. It lines up with when the US technical audience is awake and active, and it lines up with a lot of the practical launch advice that keeps getting repeated in decent HN guides.

But that is not the whole story.

If your goal is maximum raw audience, posting during busy US daytime hours is a reasonable default.

If your goal is lower competition, some analyses argue for Sunday night Pacific, especially around midnight to 1am Pacific, because fewer people submit then even though enough readers are still around to give a strong post an early push.

Those are two different goals:

more readers online
fewer competing submissions

People often treat them as the same thing. They are not.

What The Data Actually Says

The official Hacker News FAQ says ranking is not just votes plus time. It also includes flags, anti-abuse software, overheating penalties, account or site weighting, and moderator action. In other words, even if you knew the best time, you still would not have a guaranteed recipe for the front page. See the HN FAQ.

That is why timing advice is all over the place.

Older large-scale analysis from Max Woolf found that overall activity peaks around 12pm Eastern / 9am Pacific, but also concluded that submission time alone did not strongly determine which posts went viral. See A Statistical Analysis of All Hacker News Submissions.

Recent practical launch guides mostly converge on Tuesday to Thursday morning Pacific. See Smol Launch’s Hacker News launch guide and Calmops’ guide. These are useful, but they are also launch guides written by people who want to help you launch things, so read them as practical heuristics, not revealed truth.

Then you get a more contrarian result. A June 2025 analysis of 23,000 posts argued that the best odds came from Sunday, midnight to 1am Pacific, because competition was lower while engagement stayed decent. See When to Post on HN: Analyzed 23k posts (June 2025).

That sounds contradictory until you separate best chance per post from biggest total audience.

Those are different questions, and different articles answer different ones.

Our Take

If you want one simple recommendation, use this:

Post during US morning for broad technical posts. Try lower-competition windows for niche posts.

Concretely:

Start with Tue-Thu, 14:00-17:00 UTC for technical essays, product writeups, and serious link posts.
Test Sunday night Pacific if your post is niche, weird, or likely to benefit from less crowding.
Treat weekends as viable for side projects, longer reads, and more curiosity-driven posts.

That recommendation is also broadly consistent with our own Top HN stats page, which is useful because it shows when top stories were actually created over the last 365 days.

One important caveat: our page is a top-stories heatmap, not a magical conversion model for all submissions. It tells you when high-scoring stories tend to appear, not your personal odds of success. Over the last year, it points strongly at weekday US morning to early afternoon, especially around 14:00-17:00 UTC. That is a useful factual anchor, even if it is not the whole answer.

Use The Right Submission Type

Before worrying about time, make sure you are using the right kind of post.

Regular link post

Use a normal submission when you are sharing:

a blog post
a research writeup
a news article
a technical tutorial

Show HN

Use Show HN when you made something and people can actually try it.

The official Show HN guidelines are clear about this:

it should be something you worked on personally
users should be able to try it
blog posts, newsletters, sign-up pages, and landing pages do not count
you should be around to discuss it

This is where a lot of self-promotion goes wrong. People post a glossy homepage with no product behind it, call it Show HN, and then wonder why the thread goes badly.

HN is not confused about the difference between “I built this” and “I would like traffic to this.”

Ask HN

Use Ask HN when you genuinely want answers, recommendations, feedback, or discussion.

Do not use Ask HN as a disguised launch.

The Rules That Count

If you only read one primary source, read the official Hacker News Guidelines.

The main rules in practice are:

submit the original source when possible
do not hype the title with ALL CAPS, exclamation points, or marketing language
do not change the title unless the original is misleading or linkbait
do not use HN primarily for promotion
do not solicit upvotes, comments, or submissions
if it is a video or PDF, label it [video] or [pdf]

That last one is more important than people think. A lot of bad HN advice starts from “how do I make my post stand out?” The official answer is almost the opposite: do not decorate it.

HN generally rewards clear, plain, descriptive framing.

Etiquette Counts More Than Timing

This is the part many guides underplay.

The social rules on Hacker News are not cosmetic. They shape whether people give you the benefit of the doubt.

The official guidelines ask people to:

be kind
be curious
avoid snark
reply to the strongest version of what someone said
avoid shallow dismissals
avoid political or ideological flamewars
assume good faith
not post AI-generated or AI-edited comments

That last one is now explicit in the official guidelines: HN is for conversation between humans.

If you post your own work, the etiquette is simple:

be present
answer real questions
admit limitations
do not act like you are above criticism
do not vanish after dropping the link

One small HN thread about how to submit your product put it well: expect unrequested feedback, and read the thread from time to time so people can see the author is around. See How to Submit.

What Usually Does Well

One of the more interesting writeups on this is What gets to the front page of Hacker News?. It is imperfect and the HN comments correctly point out some methodology issues, but the broad conclusion feels directionally right:

personal technical writing does well
useful tutorials do well
thoughtful engineering blog posts do well
naked corporate promotion usually does not

That matches the official rules and it matches lived experience on the site.

If your post teaches something, explains a tradeoff clearly, shares a real build story, or gives technical readers something concrete to react to, it has a chance.

If it reads like demand generation content, it probably does not.

Practical Advice Before You Hit Submit

Here is the checklist I would actually use.

Before posting

make sure the page loads fast
put the real subject in the title
remove hype, slogans, and vague claims
make sure the article itself is worth reading without a sales agenda
decide whether this should be a link post, Show HN, or Ask HN

Right after posting

be around for the first hour
answer early questions clearly
fix obvious bugs or broken links fast
do not argue with every critic
do not ask friends to upvote

If it dies

do not panic
do not immediately repost
do not conclude the article was bad

Sometimes the window is short. Sometimes the timing was wrong. Sometimes the topic just did not match the audience that day. Sometimes HN is random.

The FAQ explicitly says ranking has other hidden factors. That is a polite way of saying you should stay humble about any theory of the system.

The Real Answer

The best time to post on Hacker News is the time when all of these are true:

the relevant readers are awake
you can stick around to answer comments
the post is on-topic for HN
the title is plain and accurate
the thing you are sharing is genuinely interesting

If you force me to give a schedule, I would say:

default window: Tue-Thu, 14:00-17:00 UTC
experimental low-competition window: Sunday night Pacific
best format for your own real product: Show HN, if people can actually try it

But the deeper advice is simpler:

Write something smart. Say plainly what it is. Follow the rules. Show up like a human.

That still beats timing tricks.

Portable Secret is now open source

Thu, 26 Feb 2026 00:00:00 GMT

Sharing passwords or sensitive files with people outside your team is painful.

Secure portals require accounts. Zip files confuse people. Chat apps retain history you don’t want kept.

We built Portable Secret to solve this. It generates a single HTML file containing your encrypted data and the code to decrypt it. You send the file, share the password via another channel, and the recipient opens it in their browser. No accounts, no servers, no dependencies.

Today, we are releasing the project as open source on GitHub. You can audit the code, fork it, or host it yourself.

The Tool is Now Portable Too

The generated secret files have always been self-contained. But until now, the tool to create them was a standard web application hosted on a server.

For the open source release, we changed how we build the application. We switched the SvelteKit adapter to “inline” mode.

This means the creator tool itself compiles into a single HTML file. You can go to the live tool, save the page as HTML, and keep it on a USB drive. You can generate secrets completely offline, on an air-gapped machine, without ever hitting our servers.

How It Works

The security model is simple and browser-native.

Local Encryption: When you add files or text, the browser encrypts them using AES-256-GCM.
Key Derivation: We use Argon2id (or PBKDF2 as a fallback) to derive the encryption key from your password. This makes brute-force attacks significantly harder.
The Payload: The encrypted data is bundled with a lightweight decryption template into a single .ps.html file.

When the recipient opens the file, the browser derives the key again and decrypts the content in memory. The unencrypted data never touches a disk or a network.

Why Open Source?

Trust is the most important feature of a security tool. You shouldn’t have to take our word that we aren’t uploading your secrets.

By opening the code, we allow anyone to verify that:

No network requests are made during encryption or decryption.
The cryptography implementation follows standards.
Your data stays on your device.

Check out the repository or try the live tool. It is a simple solution for a complex problem.

Portable Secret: encrypted files in one HTML

Mon, 23 Feb 2026 00:00:00 GMT

Sharing secrets with people outside your organization is surprisingly hard.

Password-protected zip files confuse non-technical users. Secure portals require accounts and maintenance. Messaging apps often violate compliance rules.

We wanted a solution that was boringly simple: one file, no accounts, no server dependency.

Portable Secret is a self-contained HTML file. It holds both the encrypted data and the code to decrypt it.

Update (2026-02-26): Portable Secret is now open source, and the creator tool is portable too. Read the announcement: Portable Secret: Now Open Source and Fully Local.

The Constraint

We set one hard rule: The recipient must be able to decrypt the file with only a browser and a password.

This drove every design decision. The key derivation must happen in the browser. The UI must work on slow devices. The format must be forward-compatible.

Inside the File

The generated HTML contains two HTML comments: a metadata block and a base64-encoded payload.

When you open the file, the embedded script:

Reads the metadata.
Asks for a password.
Derives the encryption key.
Decrypts the payload using AES-256-GCM.
Renders the files for download.

No network calls occur. You can disconnect your internet and it still works.

Cryptography Choices

We support two key derivation functions (KDFs):

Argon2id: Hard against GPU attacks. Preferred for modern devices.
PBKDF2: The compatibility fallback.

We default to Argon2id but fall back to PBKDF2 if the device or browser is limited. This balances security with usability.

The UX of Encryption

Browser cryptography can be slow. If key derivation takes 10 seconds, the page looks frozen.

We solve this with calibration. Before we start, we run a quick test to estimate the device’s speed. We use this to show a realistic progress bar and a time estimate. Users will wait 30 seconds if they know it is working; they will close the tab if it looks dead.

Responsive Performance

Argon2id is heavy. Running it on the main thread freezes the UI.

We offload the derivation to a Web Worker whenever possible. This keeps the interface responsive while the heavy lifting happens in the background.

The Build System

We split the architecture.

Create: A full Svelte application builds the file.
Open: A lightweight, framework-free template handles decryption.

This keeps the resulting file small and robust. The recipient doesn’t need to download a framework to read a text message.

Summary

Portable Secret is a tactical tool. It doesn’t replace a secure collaboration platform, but it solves the immediate problem of sending a file securely to someone who doesn’t have an account.

It turns a security headache into a simple file transfer.

Building a Hacker News digest around discussion, not headlines

Wed, 04 Feb 2026 00:00:00 GMT

Top HN is our daily Hacker News digest. It pulls the top stories for the day, writes a short summary of the link, then summarizes the comment thread with citations back to the original comments.

We built it for a very Hacker News problem. The title gets you curious, but the real value is often buried in a 200-comment thread, a correction from someone who built the thing in 2009, or a reply that is smarter than the article itself.

We did not want a list of links with generic AI blurbs attached. We wanted a short daily brief that captured what people were actually arguing about.

Pick Stories People Argued About

We fetch stories from the Algolia Hacker News API in a strict UTC day window. Then we sort by points and trim the list.

That still is not enough. Hacker News regularly has stories that get a wave of upvotes but very little real discussion. Those are bad digest material.

We filter for threads that look alive. If a story has very high points but too few comments, we drop it. The goal is not to mirror the front page. The goal is to find stories that produced useful conversation.

Summarize The Link And The Thread

For each selected story, we do two separate fetches.

First, we fetch the Hacker News item page and pull out the top comments. We rank comments by replies, skip flagged comments, and keep the ones most likely to contain the real debate.

Second, we fetch the story itself. Jina Reader is the happy path. If that fails, we fall back to parsing the raw HTML. If both fail, we still keep going with a thinner summary.

Then we generate two pieces of text:

A one-sentence summary of the article.
A short summary of the comment thread with citations like [1] and [2].

Those citations are not cosmetic. We turn them into links to the actual Hacker News comments, so readers can jump straight to the source of a claim or anecdote.

That makes the digest feel less like AI commentary and more like a guided map of the discussion.

Store Markdown Once, Render It Everywhere

The backend stores each story digest as markdown, with escaped text and safe links baked in.

That gives us one canonical format for the web page and the RSS feed. The frontend turns the markdown into HTML for the daily page. The RSS endpoint renders the same content and escapes it for XML.

We are not maintaining separate presentation pipelines for every surface. We store one durable artifact and render it where needed.

Summary

The interesting part of Hacker News is rarely the headline alone. It is the mix of the article, the rebuttals, the war stories, and the comment that explains the whole thing better than the link did.

Our digest is built around that idea.

Pick stories with real discussion. Summarize comments with citations. Reuse the same artifact everywhere.

If you want to see the result, it is live at HN daily digest.

Realtime updates without WebSockets

Sun, 25 Jan 2026 00:00:00 GMT

Realtime features often tempt teams into complex architecture. You start by wanting a status indicator to update automatically. You end up maintaining a fleet of WebSocket servers and a Redis PubSub cluster.

We wanted snappy updates without the operational headache. We chose HTTP long polling combined with snapshot semantics.

The Problem With WebSockets

WebSockets introduce state. You have to manage persistent connections, handle backpressure, and debug a separate transport stack. Load balancers become more difficult to configure. Autoscaling gets tricky.

For most applications, this is overkill.

Long Polling Done Right

Long polling differs from standard polling. The client requests an update, and the server holds the request open until data changes or a timeout occurs.

This approach feels instant because the server responds immediately when an event happens. It works over standard HTTP, requires no special infrastructure, and is naturally stateless.

Snapshots, Not Streams

We do not stream individual events. When a change occurs, the backend returns a minimal snapshot: “The Approval object with ID 123 changed.”

This payload tells the frontend what is stale. The frontend then decides how to handle it—usually by re-fetching the relevant data.

This simplifies the logic. You do not need to replay a sequence of events to rebuild state. You just mark the cache as dirty.

Precision Cursors

To track state, we use high-precision timestamps. Every response includes the timestamp of the latest event. The client sends this timestamp back in the next request.

This ensures we never miss an update. If the client disconnects, it reconnects with its last known cursor, and the server sends everything that happened in the meantime.

Invalidation as a Primitive

The frontend does not apply patches. It invalidates queries.

If an “Account” event arrives, the frontend invalidates all account-related queries. If a “Comment” event arrives, it invalidates the comment list.

This keeps the UI consistent. We add a new model, define its invalidation rules, and the realtime system just works.

Handling Edge Cases

Realtime systems are full of sharp edges. We handle them explicitly:

Timeouts: If the request times out (usually after 30 seconds), the client immediately sends a new one.
Disconnects: If the server shuts down, it closes the connection cleanly. The client reconnects.
Empty State: The first request returns a cursor so the polling loop can start.

Summary

You can build excellent realtime experiences without WebSockets.

Long polling with precise cursors and cache invalidation provides 90% of the benefit with 10% of the complexity. The UI feels alive, and the operations team sleeps at night.

Designing better database IDs with UUIDv7 and typed public IDs

Wed, 14 Jan 2026 00:00:00 GMT

Engineers fight about primary keys constantly. Auto-incrementing integers leak business metrics. UUIDv4 fragments database indexes. Snowflake IDs require dedicated infrastructure.

We found a middle ground. We use a split-ID strategy: UUIDv7 for the database, and a prefixed, checksummed, Base32-encoded UUIDv4 for the API.

Our public IDs look like this: u_14wrt1xnprkj3nj7wtndz74037rkw

The Database Layer (UUIDv7)

Random UUIDs (v4) are terrible primary keys for PostgreSQL. They scatter inserts across the index, which forces the database to load random disk pages for every write. This kills throughput.

UUIDv7 solves this. It embeds a timestamp in the first 48 bits, so new IDs are appended to the end of the index. You get the performance of integers with the global uniqueness of UUIDs.

We use UUIDv7 for all primary and foreign keys. It is a free performance optimization.

The Public Layer (Stripe-style Prefixes)

We do not expose UUIDv7 to users because it leaks creation time. Instead, we generate a separate random UUIDv4 for public use and format it for humans.

We use prefixes like u_ for users or p_ for projects. This idea comes from Stripe.

Prefixes solve three problems:

Readability: You know what the ID represents immediately.
Debugging: You cannot accidentally pass a User ID to a function expecting a Project ID.
Polymorphism: A single API endpoint can handle different object types by checking the prefix.

The Formatting (Crockford Base32)

Hexadecimal UUIDs are hard to read. Base64 contains special characters that break URLs. We chose Crockford’s Base32.

This encoding is designed for humans:

No ambiguity: It excludes I, L, O, and U. You never have to guess if a character is a one or an l.
Case insensitive: u_14WRT... works the same as u_14wrt....
Selection friendly: Double-clicking the ID selects the whole string, unlike standard UUIDs which break at hyphens.

The Checksum

We append a 3-character checksum to the end of the ID. This adds a small amount of length but catches 99.99% of typos.

If a user swaps a character, our API rejects the request before it even hits the database. This prevents valid-but-wrong lookups and wasted database cycles.

Implementation

Our table structure is simple:

CREATE TABLE users (
    -- Internal PK: UUIDv7. Fast indexing.
    id secret_uuid PRIMARY KEY DEFAULT uuid_generate_v7(),

    -- Public ID: UUIDv4. Random and opaque.
    uuid uuid UNIQUE NOT NULL DEFAULT gen_random_uuid(),

    email varchar(255) NOT NULL,
    created_at timestamptz DEFAULT now()
);

When the API receives an ID, we strip the prefix, verify the checksum, decode the payload, and query the uuid column. When we return data, we encode the uuid back into our custom format.

Summary

IDs are part of the user interface.

By separating the physical ID (database performance) from the logical ID (developer experience), we get fast queries and usable handles. It takes a little more setup than a standard serial ID, but it pays off in every support ticket and log entry.