DEV Community: Playful Programming

Closed vs Open Source AI: Who Really Owns Your Data? 🔓

Domenico Tenace — Mon, 12 Oct 2026 08:18:12 +0000

Overview

Hey everyone 👋

When we pick an AI model, we usually look at benchmarks, speed and price. Fair enough. But there's a question most teams skip until it's too late: who owns the data, and who holds the controls?

Right now the AI world is split in two. On one side, proprietary models, the classic "black boxes". On the other, open weights models you can download and run yourself. Let me walk you through why this choice matters more than it looks. Let's dive in! 🤙

Closed vs Open: The Quick Version

Closed models live behind an API. You send text, you get text back, and what happens in between is not your business. They're easy to start with, and that's why so many companies pick them.

Open weights models (think Llama, Mistral, Qwen, DeepSeek) are different. You get the model itself, so you can run it on your own server, in a private cloud, or even on a beefy laptop. One note: "open weights" is not always the same as "open source" in the strict sense, so always read the license before building a product on top of one.

Why Open Source Is Worth a Look

Your Data Stays at Home 🔒

With a self-hosted model, nothing leaves your infrastructure. No customer data, no internal documents, no proprietary code sent to someone else's servers. If you work in healthcare, finance, or you just have a nervous legal team, this alone can settle the discussion.

No Vendor Lock-in 🔓

Prices change. APIs get deprecated. Terms of service get rewritten on a random Tuesday. If your whole product depends on one provider, every one of those changes is your problem, and you get no vote.

With open models you control the infrastructure, so you can move, switch or fork whenever you want.

You Can Look Inside and Make It Yours 🛠️

No black box means you can inspect what you're running. You can also fine-tune a model for your own domain and keep full ownership of the result. Try doing that with a closed API, and you'll quickly find where the rules stop.

The Catch

I'm not here to sell you a dream, so let's be honest about the downsides.

Running models costs real money, in GPUs or cloud instances.
Someone has to maintain it: updates, scaling, monitoring, security. That someone is you.
The very top closed models still tend to lead on the hardest tasks, even if the gap keeps shrinking.
Licenses vary a lot, and some come with restrictions you won't like.

If you're a small team with no infra experience, a managed API might be the smarter call, at least at the start.

So What Should You Do? 🎯

For most teams, the answer isn't "pick a side", it's "keep the exit open".

Start with a closed API if you need to move fast.
Put a thin abstraction layer between your code and the model, so swapping providers is a config change, not a rewrite.
Use open models for the sensitive stuff, or for tasks where a smaller model is good enough and much cheaper.
Test open alternatives regularly. The landscape moves every few weeks.

Open source fits best when privacy is non negotiable, when you have enough volume to justify your own infra, or when you need deep customization. Closed fits best when you want zero ops and the strongest raw performance.

Final Thoughts 🌟

This isn't a philosophical debate, it's a practical one. The more AI becomes the core of your product, the more it matters who controls it. Open source is also what keeps a handful of companies from owning the entire cognitive infrastructure we all rely on.

You don't have to go all in. Just make sure that if the rules change tomorrow, you have somewhere to go.

Happy coding! ✨

Hi 👋🏻
My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.
Don't forget to visit my social links to discover my links, check out Domenico Tenace Open Labs for my open source projects and subscribe to my newsletter! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Seasoned Developer Advice after 25 years in IT

Emanuele Bartolesi — Fri, 09 Oct 2026 10:09:24 +0000

I've now been working in IT for exactly 25 years.

My impostor syndrome is still very much present. Writing an article called "seasoned developer advice" makes me hesitate a little. There is always something I don't know, a technology I haven't used, or someone who understands a subject much better than I do.

But after 25 years, I think I can start sharing a few thoughts.

These are opinions about how to work, build software, and stay in this profession. Take what helps, question the rest, and adapt it to the team and situation you have in front of you.

Ask the question you are embarrassed to ask

If a requirement is unclear, ask about it before you turn it into code.

What does "active customer" mean? Who can approve this operation? What should happen when the external service is unavailable? These questions can feel basic, especially when everyone else in the meeting appears to understand everything.

I would rather admit that I don't understand a business rule than build an entire feature around my interpretation of it. The same applies to an unfamiliar piece of code. Ask someone to walk you through it, then explain it back in your own words.
This step is even easier with AI nowdays, but asking a colleague still an easier thing to understand maybe something that AI doesn't know behind a business choice or something like that.

Experience should make it easier to say "I don't know yet." I still have to remind myself of that.

Give coordination an owner

Developers need time to develop. If the lead developer also has to chase every dependency, negotiate the scope, update stakeholders, and organize the release, account for that work in the plan.

On a larger project, I would want someone explicitly responsible for coordination. That might be a project manager, a delivery lead, or another role that fits the organization. On a small team, it may be a shared responsibility, but the decisions still need an owner.

A date written in a ticket does not resolve a blocked dependency. Someone has to talk to the other team, agree on what happens next, and adjust the plan when the answer changes.

When estimating a feature, include that work. A week full of meetings leaves less time for implementation than a week with clear decisions and uninterrupted time.
Actually we are still doing this mistake to "overmeetings" but I hope it will change soon or later.

Make meetings earn their place

I don't think every team needs the same meeting schedule.

A short conversation with the person who understands the business process can be useful while a feature is taking shape. Showing a working screen may reveal that the approval flow is wrong before you spend another week building it.

A daily meeting where everyone reads out tickets already visible on the board is harder to justify.

For me, a useful meeting resolves a question, exposes a dependency, or produces a decision. If an update can be written down and read when people have time, try that. If a disagreement needs a conversation, have the conversation.

Record the outcome where the work lives. A decision made on a call is easy to miss if the developer implementing it was somewhere else.

Write code for the person who has to change it

Readable code matters most when someone needs to fix it under pressure.

I prefer a method with a clear name and an obvious flow over an abstraction that takes three files to understand. There are good reasons for abstraction, but I want to know which problem it solves before adding another layer.

The same caution applies to shared code. Two methods that look similar may represent business rules that will evolve independently. Putting them in one common library creates a relationship you will have to maintain.

Extract code when the shared behavior is understood. If several applications depend on it, think about compatibility, ownership, and how updates will reach them. Publishing a package creates a responsibility beyond the original project.
Still a valid advice also for we use a lot of AI for writing code.
We need anywayt to review what is written to understand if we can read and understand the code anyway.

Leave the explanation you would want to find later

Code can show what happens without explaining why it must happen that way.

A comment explaining that a file format is required by an external system is useful. A comment saying that the next line increments a counter usually adds little.

I want documentation that helps someone do the work: how to run the application, which configuration is needed, how to execute the tests, and what to check when a deployment fails. Keep those instructions close to the repository and update them when the workflow changes.

There is also value in a short decision note. If the team rejected a queue because the current workload did not justify operating one, record that reasoning and the condition that would make you reconsider.

AI can help draft these explanations. Check them against the code and the actual setup before treating them as documentation. A plausible installation guide that cannot be followed is another problem for the next developer to debug.

Think about the application after it leaves your machine

A feature needs more than a successful local run.

Before shipping, I want to know how we will recognize a failure and what we can do about it. A useful log entry should give enough context to trace an operation without exposing credentials or customer data. An exception with no context can leave you searching through several unrelated requests.

Be deliberate about tests, too. If a feature moves data between customers, test that boundary. If it sends notifications, consider what happens when an operation is repeated. The failure case should influence the test, rather than becoming an afterthought once the happy path passes.

And discuss recovery. Reverting code will not undo every effect of that code. A database change or an email already sent needs its own consideration.

These questions belong in development, while you can still change the design without an incident forcing the decision.

Review the code without making it personal

Having someone question your implementation can be uncomfortable. With impostor syndrome already in the room, a review comment can feel larger than it is.

Try to keep the conversation specific. Explain which behavior concerns you, point to the assumption, and suggest a way to verify it. "What happens if this request is retried?" is a useful opening for a discussion.

As the author, explain your reasoning and be willing to change it. As the reviewer, distinguish a defect from a preference. A naming choice does not deserve the same treatment as a missing authorization check.

I also like reviews small enough that a colleague can understand the change properly. If a bug fix includes a folder reorganization and a new framework, consider separating those decisions.

The goal is a change the team understands well enough to maintain. Being the person who wins the argument contributes very little to that.

Make maintenance part of the plan

Framework upgrades, dependency updates, and refactoring need time on the calendar.

It is easy to postpone them because the application still works. When you do, be explicit about what you are accepting and when you will revisit it. Otherwise, postponement becomes the plan by default.

A refactoring ticket should name the problem it will address. Perhaps adding a validation rule currently requires changing five different places. That gives the team a concrete improvement to assess and a way to tell whether the work helped.

I would apply the same discipline to modernization. Explain what the upgrade enables, which risk it addresses, and how you will validate the change. The age of a framework alone is a weak explanation for rewriting a working application.

Keep learning through things you can use

You cannot study every language, framework, cloud service, and AI tool that appears.

Choose something relevant and spend enough time with it to understand where it helps. Build a small application, add a feature to a side project, or investigate a part of your production system that you usually avoid.

A course can give you structure. Applying the lesson gives you questions the course may never have covered.

I would also leave room to learn from colleagues. Someone with less experience may know a tool or technique you have never used. Twenty-five years in IT should not make that conversation awkward.

Your main language is useful expertise. Stay curious about the parts around it: the database query, the deployment pipeline, or the interface the user has to navigate. A problem does not stop at the boundary of your preferred stack.

Choose tools you can trust and understand

Use an editor that lets you work comfortably. Learn its debugger, navigation, and refactoring tools before assuming a different editor will solve your frustration.

I would take the same approach to AI. Start with work where you can judge the result: exploring unfamiliar code, preparing a first test draft, or checking an implementation for missed cases.

Read the output and run the checks. When the tool proposes a design, ask what assumptions it made. You remain responsible for the change you submit.

Trying another tool or model can be useful when it answers a specific question about your workflow. You don't need a collection of subscriptions just to feel current.

Build a way of working you can keep doing

After 25 years, I want my advice to include what happens away from the keyboard.

Take breaks. Get up, walk around, do sports, and give yourself permission to stop staring at the same problem. If you are stuck, ask for help rather than making another exhausted hour the price of proving that you can solve it alone.

Talk to teammates sometimes without a ticket as the agenda. It is easier to ask someone a difficult question when your only interaction with them has not been a review disagreement.

And keep something outside work. There will always be another release, article, framework, or project. Closing the laptop does not mean you stopped caring about your profession.

I still don't feel that 25 years gives me an answer to everything. It does give me enough reason to share these thoughts, even while the impostor syndrome tells me to wait a little longer.

If you enjoyed this blog post and want to learn more about C# development, you might be interested in subscribing to my bi-weekly newsletter called Dev Dispatch. By subscribing, you will get access to exclusive content, tips, and tricks, as well as updates on the latest news and trends in the development world. You will also be able to interact with me, and share your feedback and suggestions. To subscribe, simply navigate to https://buttondown.email/kasuken?tag=devto, enter your email address and click on the Subscribe button. You can unsubscribe at any time. Thank you for your support!

My Windows 11 Laptop Was Struggling with Claude and Codex. Defender Exclusions Helped.

Emanuele Bartolesi — Tue, 06 Oct 2026 15:01:47 +0000

My Windows 11 laptop sometimes struggled while I was working with Claude and Codex or GitHub Copilot. CPU usage was high, and the fans were running like crazy.
It means also that my battery runs out in 1 hour and 30 minutes 😀

When I checked Task Manager, Antimalware Service Executable stood out. Disk usage was around 90%, with heavy CPU activity as well, while the two tools were running.

That process belongs to Microsoft Defender Antivirus. You can find it as Antimalware Service Executable in Task Manager's Processes tab, or MsMpEng.exe in the Details tab. Microsoft documents both names here.

I suspected Defender's scanning of the tools' local folders was contributing to the slowdown. Adding folder exclusions solved the problem I was seeing on my laptop. This is my experience with one machine, rather than proof that Claude or Codex always causes this behavior.

The folders I excluded

These are the four entries in my Windows Security exclusion list:

C:\Users\barto\.claude
C:\Users\barto\.codex
C:\Users\barto\.copilot
C:\Users\barto\.github-copilot-cli

The last two entries are for my Copilot tooling. Their presence in this list does not establish that they contributed to the Claude and Codex slowdown.

There is a security tradeoff: a folder exclusion removes Defender antivirus scanning coverage for that folder and its contents. Files placed there later are also covered by the exclusion. Trusting the tool does not guarantee that every file it writes or downloads is safe. Microsoft explains the exclusion options and risks.

Treat this list as a record of my setup. For your machine, identify the affected folder first and keep any exclusion as narrow as possible.

How to add a folder exclusion in Windows 11

Open Start, search for Windows Security, and open it.
Select Virus & threat protection.
Under Virus & threat protection settings, select Manage settings.
Scroll to Exclusions and select Add or remove exclusions. Approve the administrator prompt if it appears.
Select Add an exclusion, then Folder.
Browse to the folder you want to exclude, for example C:\Users\YOUR_USERNAME\.claude, and select Select Folder. Replace YOUR_USERNAME with your Windows user folder name.
Confirm that the folder appears in the exclusion list. Repeat for other folders only where needed.

These steps follow Microsoft's Windows Security guidance. On a company-managed laptop, your IT team may control these settings.

Moving to European Digital Services, One Decision at a Time

Emanuele Bartolesi — Thu, 24 Sep 2026 16:13:19 +0000

My move to European digital services includes Proton, Qwant, and DeepL. When it came to Notion, I went further and replaced it with Brainy, the product I built for my own notes, projects, and tasks.

That sounds like a migration, but the word creates the wrong expectation. I did not spend a weekend exporting every account, cancelling every subscription, and declaring myself independent from American technology on Monday morning.

I am changing one decision at a time.

I do not want a US provider to be the automatic answer for every digital need simply because it is the most visible option. Europe has credible products. Some are good enough to compete directly, and some fit my needs better. That does not mean I will replace a working service because a company has the wrong flag beside its logo.

Proton made the change visible

Proton is where the migration became a system rather than a few unrelated experiments.

Proton Mail replaced my previous email setup. Proton VPN replaced NordVPN. Proton Pass replaced NordPass. I also use Lumo for selected private AI conversations rather than treating every chat as suitable for any general-purpose assistant.

The immediate benefit was consolidation. One privacy-focused Swiss ecosystem replaced several separate accounts and subscriptions. I did not need to find a different European company for email, another for passwords, and another for the VPN before making progress.

There is an obvious trade-off: consolidation reduces vendor sprawl while increasing dependence on Proton. Moving three services into one company is not diversification. I still prefer the current setup, but it would be dishonest to describe concentration as independence.

Lumo has a similar boundary. Proton says stored conversations use zero-access encryption, which is why it has a place in my private workflow. I do not pretend that it replaces every AI service or every model. The choice depends on the conversation and the job I need to complete.
For the moment I am using Lumo only for questions related my health and other sensitive information.

The corporate map is more complicated than the logos

Once I started checking where services were based, the simple Europe-versus-USA story stopped working.

NordVPN is not an American service. NordVPN says it is based in and operates under Panama's jurisdiction, while its parent company, Nord Security, is based in the Netherlands. Moving to Proton VPN is a Panama-to-Switzerland change at the service-jurisdiction level, with a European parent company also involved in the old setup.

WeTransfer is European too. WeTransfer B.V. is based in Amsterdam, so my switch to SwissTransfer was not about escaping an American company. It was about the product.

For my file-sharing needs, SwissTransfer has a privacy model I prefer and a much more useful free allowance for large files. Infomaniak says SwissTransfer accepts transfers up to 50 GB, stores the files in Switzerland, supports password protection, and deletes the files after the transfer period. WeTransfer's current free-account documentation describes an allowance of up to ten transfers or 3 GB in total over a rolling 30-day period.

That is a concrete difference. I am not using SwissTransfer because the landing page has a Swiss flag. I am using it because privacy and larger transfers matter in this workflow.

This distinction changed how I evaluate alternatives. I now look separately at the service jurisdiction, parent company, data location, underlying infrastructure, business model, portability, and actual product quality. Those facts do not always point to the same country.

Some changes need almost no migration

Qwant and DeepL were easier decisions.

I use Qwant for search. Qwant is a French company, and its current privacy policy says it does not use targeted advertising or retain search history by default. Search is also easy to test: use it, compare the results, and keep another engine available when it does not find what you need.

I use DeepL for translation. It was founded in Cologne, Germany, and it is a good example of why the word "alternative" can be misleading. I do not need to treat a European translation service as a political compromise. I can use it because it does the work.

Neither choice required a dramatic data migration. There was no archive to restructure and no DNS record that could break a production system. They simply became part of the workflow.

New domains are another low-risk entry point. I now use Infomaniak Domains instead of GoDaddy for new registrations. I am not forcing every existing domain through an immediate transfer. When I need a new domain, the new default is a Swiss, ICANN-accredited registrar. That is progress without creating unnecessary operational risk.

DNS is an even quieter change. I use Quad9 as my resolver. Quad9 is a Swiss nonprofit, and its documentation says the recommended 9.9.9.9 service blocks lookups for malicious domains without logging end-user IP addresses. It also supports encrypted DNS protocols. This is closer to changing an infrastructure setting than migrating an account, but it moves a foundational part of normal browsing away from whichever resolver happened to be the default.

Replacing Notion meant building the alternative

Notion was different because a knowledge system accumulates structure as well as data. Notes connect to projects, tasks carry context, and the way information is captured affects whether it becomes useful work or remains another page in an archive.

I replaced Notion with Brainy, my own product.

Brainy is a practical second brain organized around the PARA method. It captures notes and ideas, connects them to projects and tasks, and focuses on turning stored knowledge into action. The goal was not to reproduce every Notion feature. It was to build a workflow that matches how I move from an idea to a project, from a project to the next task, and from planning to today's work.

Owning the product gives me control over that workflow, the data model, portability, and the roadmap, but it also gives me the maintenance work. I own the deployments, bugs, database changes, security decisions, and migration logic.

This is the clearest reason the entire transition cannot happen in two hours. Replacing a service can mean changing a setting or moving years of habits and information. In this case, it also meant building and operating a product.

For the moment, Brainy is free and you can create your own account here: www.brainy-me.com.

Sometimes the correct migration is no migration

I still use Spotify.

The reason is simple: Spotify is already European and it works for me. Its consumer terms identify Spotify AB in Stockholm, Sweden. Replacing it with another service only to increase the number of changed logos would add work without moving me closer to the actual goal.

A useful migration should leave some rows unchanged. Otherwise the process is driven by ideology rather than requirements.

Here is the current map:

Workflow	Current choice	Decision
Email	Proton Mail	Moved into the Proton ecosystem
VPN	Proton VPN	Replaced NordVPN
Passwords	Proton Pass	Replaced NordPass
Private AI chats	Lumo	Used selectively for private conversations
Large file transfers	SwissTransfer	Chosen for privacy and transfers up to 50 GB
New domain registrations	Infomaniak	Replaced GoDaddy as the default for new domains
DNS	Quad9	Uses a Swiss nonprofit resolver focused on privacy and security
Search	Qwant	In active use
Translation	DeepL	In active use
Knowledge and planning	Brainy	Replaced Notion with my own product
Music	Spotify	Kept because the European service already fits

The process I use before changing a service

The European Alternatives directory is useful for discovery, but inclusion in a directory is the beginning of the evaluation, not the conclusion.

Before changing a service, I work through a small set of questions:

What job does the current product perform?
Which features are genuinely non-negotiable, and which ones are habits?
Where is the service legally based, where is the data processed, and which external platforms does it still depend on?
Can I export the data in a useful format and move again later?
Can I run the old and new services in parallel before cancelling anything?
Is the alternative better, equivalent, or merely acceptable for this specific job?

That last question matters. I am willing to accept a small difference when privacy, control, or supporting a European provider makes the trade worthwhile. I am not willing to ignore a product that fails the workflow simply because it is European.

The safest changes happen at natural decision points. Register the next domain with a different registrar. Test another search engine without removing the old one. Import a copy of a password vault before cancelling the existing subscription. Send the next large file with a service that supports the size you need.

Moving all of them at once would turn a preference into an outage plan.

Change the next decision

I still use services from American companies, and I expect that to continue. Work, collaboration, audience, and network effects do not disappear because a European alternative exists.

The difference is that I no longer want the American option to win by default. When a subscription renews, a new need appears, or a current product creates friction, I check what exists in Europe before repeating the old decision.

The outcomes vary. A European product may be good enough, SwissTransfer may be better for large files, or Spotify may already be the European answer. Brainy sits at the other end of the range because I had to build the alternative around the workflow I wanted.

This process does not need a dramatic finish. The next decision is enough.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele BartolesiFollow

🏆 Microsoft MVP (12x) & GitHub Star (4x) ⭐ 👨‍🎓 LinkedIn Technical Instructor 🎓

INP and Partytown: give the main thread back to your users

Nicolas Frizzarin — Wed, 23 Sep 2026 08:18:37 +0000

Introduction

You click on a button. Nothing happens.
You click again. Still nothing.
Then the menu opens... and closes right away.

We have all lived this. It's a responsiveness problem. And since March 12, 2024, Google measures it with a Core Web Vital: INP.

Very often, the problem is not your code. It's the code you didn't write: analytics, tag managers, pixels, A/B testing tools...

This article explains:

What INP really measures
Why third-party scripts hurt it so much
How Partytown works
How to use it in React and Angular, with real examples
When you should not use it

INP in a few words

INP means Interaction to Next Paint.

It measures the time between a user interaction and the next frame painted by the browser. In other words: how long does the user wait before seeing that something happened?

Only three types of interaction count:

a click with a mouse
a tap on a touchscreen
a key press

Scroll, hover and zoom are not measured.

INP looks at all the interactions during the visit, and reports the worst one. If there are a lot of interactions, the browser ignores the highest one for every 50 interactions. That way, one random hiccup does not ruin your score.

The thresholds, at the 75th percentile of your real users:

INP	Result
≤ 200 ms	🟢 Good
200 ms to 500 ms	🟠 Needs improvement
> 500 ms	🔴 Poor

Just a reminder: INP replaced FID (First Input Delay). FID only measured the waiting time of the first interaction. INP measures every interaction, from start to paint. Much stricter.

What's inside an interaction?

An interaction has three phases:

 user clicks                                              next frame
     │                                                        │
     ▼                                                        ▼
     ├────────────────┬──────────────────────┬────────────────┤
     │  Input delay   │ Processing duration  │ Presentation   │
     │                │                      │ delay          │
     └────────────────┴──────────────────────┴────────────────┘
     │◄───────────────── interaction latency ───────────────►│

Input delay: the time before your event handlers start. The browser is busy with something else.
Processing duration: the time to run all your event handlers.
Presentation delay: the time to compute style, layout and paint the next frame.

Keep the first one in mind. This is where third-party scripts hurt the most.

The main thread: a one lane road

The browser has one main thread. It does everything:

runs JavaScript
handles events
computes style and layout
paints

And it does one thing at a time.

A task longer than 50 ms is a long task. During a long task, the browser can't respond to the user.

Now imagine your page with Google Tag Manager, a marketing pixel and an analytics script. The user clicks at the wrong moment:

Main thread, without Partytown

──[ your app ]──[ tag manager 180ms ]──[ pixel 120ms ]──[ click handler ]──[ paint ]──
                      ▲
                user clicks here
                      │◄──────── input delay ────────►│

Your click handler is fast. Your code is clean. And your INP is still bad.

This is the key point: you can write perfect code and still fail INP, because you share the road with scripts you don't control.

Partytown: move the party somewhere else

Partytown is a small library, lazy-loaded, maintained by the QwikDev team. Its goal is simple: move third-party scripts from the main thread into a web worker.

The philosophy: the main thread is for your code. Everything that is not in the critical path can go elsewhere.

flowchart LR
  subgraph Before["Without Partytown"]
    MT1["Main thread<br/>your app + GTM + pixel + analytics"]
  end
  subgraph After["With Partytown"]
    MT2["Main thread<br/>your app"]
    WW["Web worker<br/>GTM + pixel + analytics"]
    WW -. "DOM calls through a proxy" .-> MT2
  end

And the same timeline as before:

Main thread, with Partytown

──[ your app ]──[ click handler ]──[ paint ]──
                ▲
          user clicks here: almost no input delay

Web worker

──[ tag manager 180ms ]──[ pixel 120ms ]──   ← nobody waits for this

The long tasks still exist. They just don't block the user anymore.

⚠️ Partytown is still in beta. It's not guaranteed to work for every script. Test before you ship.

How does it work?

Here comes the tricky part.

A web worker has no DOM. No document, no real window. But third-party scripts expect them. They call document.cookie, getBoundingClientRect(), addEventListener...

On top of that, communication between a worker and the main thread is asynchronous. Third-party scripts are written in a synchronous way. No await, no callback.

So Partytown does two things:

In the worker, it creates JavaScript Proxies that look like window and document.
Each call to these proxies is sent to the main thread through a synchronous channel, and the worker waits for the answer.

From the script's point of view, nothing changed. This code works as is inside the worker:

const rect = element.getBoundingClientRect(); // blocking call, like on the main thread
console.log(rect.x, rect.y);

There are two ways to get this synchronous channel.

Option 1: Service Worker (the fallback)

The worker sends a synchronous XHR. A service worker intercepts it, asks the main thread, and answers.

sequenceDiagram
  participant W as Web worker (3rd-party script)
  participant SW as Service worker
  participant M as Main thread (DOM)
  W->>SW: sync XHR "getBoundingClientRect()"
  SW->>M: postMessage
  M-->>SW: result
  SW-->>W: response { x, y }
  Note over W: for the script, it was a normal blocking call

That's why you'll see a lot of proxytown requests in the network tab. They are not real HTTP requests. They're handled locally. You can hide them with the -url:proxytown filter in Chrome DevTools.

Option 2: Atomics (the fast one)

With Atomics and SharedArrayBuffer, the worker writes the request, calls Atomics.wait(), and reads the result when the main thread answers. No service worker needed.

It's about 10x faster to transfer data between threads.

But there's a condition: the page must be cross-origin isolated. You need these response headers on your document:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Two things to know:

Safari doesn't support credentialless. So Safari falls back to the service worker.
You can use require-corp instead, which works in Safari. But it blocks every cross-origin image, script or video that doesn't have a crossorigin attribute. Be careful with your CDN.

If the headers are not there, no problem: Partytown falls back to the service worker automatically.

The two rules to remember

Before the code, two rules. They are the same for every framework.

Rule 1: type="text/partytown"

The browser doesn't know this type, so it doesn't run the script. Partytown finds it with a selector and runs it in the worker.

- <script src="https://third-party.com/script.js"></script>
+ <script type="text/partytown" src="https://third-party.com/script.js"></script>

Partytown is opt-in. Only the scripts with this type move. All the others stay where they are. You choose.

Rule 2: forward

Your own code still calls dataLayer.push(...) on the main thread. For example, when a user adds a product to the cart.

But GTM now lives in the worker. So Partytown needs to know which window functions to patch and send to the worker. That's the role of forward. It even queues the calls made before Partytown is ready.

flowchart LR
  A["Your code<br/>dataLayer.push(...)"] -->|"patched by forward"| B["Partytown<br/>(main thread side)"]
  B -->|"serialized message"| C["GTM<br/>in the web worker"]
  C -->|"network"| D["Google servers"]

By default, a forwarded call only runs in the worker. If you need the original function to also run on the main thread, use preserveBehavior:

partytown = {
  forward: [
    ['dataLayer.push', { preserveBehavior: true }], // runs on both sides
    'fbq'                                           // worker only (default)
  ]
};

Now let's have some code.

Angular

Our goal: run Google Tag Manager in the worker, and track page views and a click from our Angular app.

Step 1: install

npm install @qwik.dev/partytown

Step 2: serve the Partytown files

The worker and the service worker are real files. They must be served by your app. In angular.json, add them to the assets:

"build": {
  "options": {
    "assets": [
      {
        "glob": "**/*",
        "input": "node_modules/@qwik.dev/partytown/lib",
        "output": "/~partytown"
      }
    ]
  }
}

After a build, you should see a ~partytown/ folder in your output, with partytown.js, partytown-sw.js, partytown-atomics.js...

Step 3: `index.html`

Third-party scripts must be there early, before Angular starts. So we put everything in src/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My Shop</title>
  <base href="/">

  <!-- 1. Partytown configuration: BEFORE partytown.js -->
  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>

  <!-- 2. Partytown itself: no async, no defer -->
  <script src="/~partytown/partytown.js"></script>

  <!-- 3. Google Tag Manager, moved to the worker -->
  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <app-root></app-root>
</body>
</html>

💡 While you set things up, use /~partytown/debug/partytown.js and add debug: true to the config. You get logs in the console. Don't ship the debug build to production.

Step 4: an analytics service

Now, our Angular code must talk to GTM. We only push to dataLayer. Thanks to forward, Partytown sends it to the worker.

// analytics.service.ts
import { DOCUMENT, Injectable, inject } from '@angular/core';
import { NavigationEnd, Router } from '@angular/router';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { filter } from 'rxjs';

declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

@Injectable({ providedIn: 'root' })
export class AnalyticsService {
  private readonly router = inject(Router);
  private readonly window = inject(DOCUMENT).defaultView; // null on the server (SSR)

  constructor() {
    // An SPA has no real page load after the first one.
    // So we send a page view on each navigation.
    this.router.events
      .pipe(
        filter((event): event is NavigationEnd => event instanceof NavigationEnd),
        takeUntilDestroyed()
      )
      .subscribe((event) => this.track('page_view', { page_path: event.urlAfterRedirects }));
  }

  track(event: string, params: Record<string, unknown> = {}): void {
    if (!this.window) return; // nothing to do on the server

    this.window.dataLayer = this.window.dataLayer || [];
    // This call is patched by Partytown: it's serialized and sent to the worker.
    // GTM does its heavy work there, not on the main thread.
    this.window.dataLayer.push({ event, ...params });
  }
}

Start it with the application:

// app.config.ts
import { ApplicationConfig, inject, provideAppInitializer } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { AnalyticsService } from './analytics.service';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideAppInitializer(() => {
      inject(AnalyticsService); // create the service, so it listens to the router
    }),
  ],
};

Step 5: track a click

// product-card.ts
import { Component, inject, input } from '@angular/core';
import { AnalyticsService } from './analytics.service';
import { CartStore } from './cart.store';

interface Product {
  id: string;
  name: string;
  price: number;
}

@Component({
  selector: 'app-product-card',
  template: `
    <h3>{{ product().name }}</h3>
    <button (click)="addToCart()">Add to cart</button>
  `,
})
export class ProductCard {
  private readonly analytics = inject(AnalyticsService);
  private readonly cart = inject(CartStore);

  readonly product = input.required<Product>();

  addToCart(): void {
    // 1. What the user wants to see: update the UI first
    this.cart.add(this.product());

    // 2. Tracking: cheap on the main thread, GTM works in the worker
    this.analytics.track('add_to_cart', {
      item_id: this.product().id,
      value: this.product().price,
    });
  }
}

Look at the click handler. Without Partytown, dataLayer.push wakes up GTM on the main thread, in the same frame as your click. With Partytown, the push is sent to the worker, and GTM runs its tags there. Your handler stays small. Your processing duration stays small.

React

Same goal, same app: GTM in the worker, page views and a click.

There are two ways to do it in React:

Option A: index.html, for a client-side app (Vite, Create React App...). The simplest.
Option B: the <Partytown /> component, for apps rendered on the server (React Router framework mode, Remix, Gatsby...).

Step 1: install and copy the files

npm install @qwik.dev/partytown

Partytown comes with a small CLI to copy its files into your public folder. Run it before dev and build:

"scripts": {
  "partytown": "partytown copylib public/~partytown",
  "dev": "npm run partytown && vite",
  "build": "npm run partytown && vite build"
}

Add public/~partytown to your .gitignore. It's generated.

Option A: client-side app (Vite)

Everything goes in index.html, like in Angular:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>My Shop</title>

  <script>
    partytown = {
      forward: ['dataLayer.push']
    };
  </script>
  <script src="/~partytown/partytown.js"></script>

  <script type="text/partytown">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXXX');
  </script>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

Why not in a component? Because a client-side app renders late. The third-party scripts would wait for React to boot. In index.html, they're found as soon as Partytown starts.

Option B: server-rendered app (the `<Partytown />` component)

The package ships a React component: @qwik.dev/partytown/react. It's a thin wrapper around the Partytown snippet. The config becomes JSX props. And the snippet is inlined in the HTML, so there's no extra request for partytown.js.

Example with a root layout (React Router framework mode / Remix style):

// app/root.tsx
import { Partytown } from '@qwik.dev/partytown/react';
import { Links, Meta, Outlet, Scripts } from 'react-router';

const GTM_ID = 'GTM-XXXXXXX';

const gtmSnippet = `
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','${GTM_ID}');
`;

export default function App() {
  return (
    <html lang="en">
      <head>
        <Meta />
        <Links />

        {/* 1. Partytown: config as props */}
        <Partytown forward={['dataLayer.push']} />

        {/* 2. GTM in the worker */}
        <script
          type="text/partytown"
          dangerouslySetInnerHTML={{ __html: gtmSnippet }}
        />
      </head>
      <body>
        <Outlet />
        <Scripts />
      </body>
    </html>
  );
}

💡 Add debug={true} on <Partytown /> while you set things up.

Scripts added later

If a text/partytown script is added to the page after Partytown started (lazy loading, route change...), recent versions of Partytown (0.14.3 and later) find it automatically. On older versions, you have to tell Partytown:

const script = document.createElement('script');
script.type = 'text/partytown'; // set the type BEFORE adding it to the DOM
script.src = 'https://third-party.com/widget.js';
document.head.appendChild(script);

window.dispatchEvent(new CustomEvent('ptupdate')); // only needed before 0.14.3

Track page views and clicks

A small module, no library needed:

// analytics.ts
declare global {
  interface Window {
    dataLayer: unknown[];
  }
}

export function track(event: string, params: Record<string, unknown> = {}): void {
  if (typeof window === 'undefined') return; // nothing to do on the server

  window.dataLayer = window.dataLayer || [];
  // Patched by Partytown: serialized and sent to the worker
  window.dataLayer.push({ event, ...params });
}

A hook for page views:

// usePageView.ts
import { useEffect } from 'react';
import { useLocation } from 'react-router';
import { track } from './analytics';

export function usePageView(): void {
  const location = useLocation();

  useEffect(() => {
    track('page_view', { page_path: location.pathname + location.search });
  }, [location.pathname, location.search]);
}

Call it once, in your layout:

// Layout.tsx
import { Outlet } from 'react-router';
import { usePageView } from './usePageView';

export function Layout() {
  usePageView();
  return <Outlet />;
}

And the click:

// ProductCard.tsx
import { track } from './analytics';
import { useCart } from './useCart';

interface Product {
  id: string;
  name: string;
  price: number;
}

export function ProductCard({ product }: { product: Product }) {
  const { add } = useCart();

  function handleAddToCart() {
    // 1. UI first: this is what the user is waiting for
    add(product);

    // 2. Tracking: GTM does the heavy work in the worker
    track('add_to_cart', { item_id: product.id, value: product.price });
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <button onClick={handleAddToCart}>Add to cart</button>
    </article>
  );
}

Using Next.js? Partytown has its own Next.js integration page. Check it, the setup is a bit different.

Check that it works

Don't trust, verify. Three quick checks in Chrome DevTools:

Console: with the debug build, Partytown logs what runs in the worker.
Sources panel: look at the threads. GTM should run in the Partytown web worker, not in the main one.
Performance panel: record a page load and a few clicks. The long tasks from googletagmanager.com should be gone from the main thread track.

Then check in GTM Preview mode that your page_view and add_to_cart events arrive. If nothing arrives, check your forward config first. It's the most common mistake.

Where INP really wins

Let's go back to our three phases.

               Input delay     Processing      Presentation
               ───────────     ──────────      ────────────
Partytown:     big impact      some impact     small impact

Input delay: the big win. Third-party long tasks no longer block the main thread, so the click is handled right away.
Processing duration: the work done by third-party scripts when you push an event (like in addToCart) happens in the worker, not in your handler's frame.
Presentation delay: Partytown batches DOM reads and writes into group updates. Less layout thrashing from third-party code.

Trade-offs: no magic here

Partytown is a great tool. It's not a silver bullet. Here is what you need to know before using it.

preventDefault() has no effect. When the worker receives the event, it's already too late. A script that needs to block a link or a form submit won't work.
DOM operations are throttled. Each call crosses threads. That's fine for analytics, not for scripts that build UI.
UI-heavy scripts are a bad fit. A chat widget, a cookie banner with a dialog, anything that injects a lot of DOM nodes: keep them on the main thread.
CORS. Some third-party scripts don't send the right CORS headers. You'll need to proxy them.
Cross-origin iframes created from a Partytown script can't persist cookies or storage.
Bad scripts stay bad. A script that reads the whole document every X milliseconds with setInterval will overload Partytown.

A quick rule:

Good fit ✅	Bad fit ❌
Google Tag Manager	Chat widgets
Google Analytics 4	Cookie consent dialogs
Facebook Pixel	Scripts that call `preventDefault()`
Mixpanel, Segment, Amplitude	Scripts that inject a lot of DOM

Measure, don't guess

Never move a script "because it should be better". Measure before, measure after.

INP is a field metric. Your real users on real devices are the source of truth. Use the web-vitals library with the attribution build to see which phase is slow. It works the same in React and Angular:

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log('INP:', value);
  console.log('Element:', attribution.interactionTarget);
  console.log('Input delay:', attribution.inputDelay);
  console.log('Processing:', attribution.processingDuration);
  console.log('Presentation:', attribution.presentationDelay);
  // send it to your analytics
});

Put it in main.ts (Angular) or main.tsx (React).

Here's how to read the result:

High input delay? Look at what runs before the click. Third-party scripts are the usual suspects. This is where Partytown shines.
High processing duration? It's probably your handler. Partytown won't help.
High presentation delay? Look at your DOM size and your layout.

In the lab, INP depends on what you click. Two tips:

Interact with the page while it loads. That's when the main thread is the busiest.
Use Total Blocking Time (TBT) as a proxy. It's not INP, but it tells you if the main thread is crowded.

Partytown won't fix your own code

If your click handler takes 400 ms, moving GTM to a worker changes nothing.

For your own code, the classic tools still apply:

Break long tasks into smaller ones.
Yield to the main thread (setTimeout, or scheduler.yield() where it's supported).
Show visual feedback first, do the heavy work after.
Move heavy computation to your own web worker.

Partytown handles the code you don't own. You handle the code you own.

Conclusion

INP measures what users feel: "I clicked, did something happen?"

Third-party scripts are often the hidden reason for a bad INP. They take the main thread, and your users wait.

Partytown moves them into a web worker, and keeps them working thanks to a clever synchronous bridge (Atomics or a service worker).

In Angular and React, the setup is small:

serve the Partytown files
add the config and type="text/partytown"
forward the functions your code calls
keep your tracking code as simple as a dataLayer.push

It's not magic. It's in beta, it has trade-offs, and it's not made for UI scripts. But for analytics, tag managers and pixels, it can give the main thread back to the only code that should be there: yours.

Measure first. Move the right scripts. Measure again. 🎉

The Grand Unifying Architecture of Frontend

Ryan Carniato — Tue, 22 Sep 2026 16:43:06 +0000

I used to joke that the history of frontend development could be retraced by following the argument of who owned the state. And the truth is both sides have gone back and forth on this over the years. We started on the document web where state was on the server. Then we added JavaScript and Applets where we could have stateful things in the client. But developers at the time didn't like either much and tried to wire state across both sides in their server languages and we got ASP.NET and the like.

I sit here over 30 years later and it is still going on. Going to replace your React app with HTMX? Maybe. Maybe it isn't that simple. Although this seems like an endless spiral, I don't think this is unsolvable. Even though it has been going on so long, I actually think the answer is in front of us.

The unified model comes down to understanding responsibilities. And they are as old as the web itself. Every time we misalign complexity soars. Every time we ignore part of the puzzle it goes on to bite us. Every solution straddles part of this solution space but we've struggled to cover the whole range.

Core Responsibilities

My observation is that all frontend architectures come down to layering of three responsibilities. Some are more present than others but they all exist in some form.

1. Navigation (client)

The URL is the basis of the web experience and it belongs to the browser. Orchestration is a client responsibility and every solution from SPA to HTML partial agrees with this. JavaScript in the browser is the root of our application.

2. Content (server)

Conversely, content belongs to the server whether it is markup or JSON. The server is the authoritative source. It hangs off of our navigation.

3. Affordances (client)

Affordances find us back in the browser. Local UI state, in progress work, optimistic updates. We need to provide our user feedback faster than a round-trip to the server.

Following the Shape

All web application architectures follow this client -> server -> client layering. A user navigates or performs an action, content comes back from the server, and the client settles it. That's the Single Page Application(SPA) architecture after load, but it's also HTMX. And also LiveView, if the server -> client protocol is powerful enough.

It feels like I'm stating the obvious here. But the web generally maps writes to navigation, and the server only pushes reads. Mutations travel through layer 1 with forms, actions, invalidation, and requests for the content. Layer 2, content, never writes and only publishes.

This asymmetry is what makes it composable. Breaking that leads to two stateful systems fighting against themselves. Which is why affordances like optimism(layer 3) fit cleanly on top if viewed as an overlay. The client never writes server content directly as it doesn't own it.

Revisiting the Spectrum

I've tried many times to map the solution space to a 4 quadrant grid but I never found the right axis. But I'm now seeing how all solutions can sit in the same diagram.

Obviously this is a rough placement, solutions fit spaces not points, and something like React can be used as a frontend in a sync engine like Zero. Here React represents classic SPAs + JSON API. But most frameworks fix both transport and affordance weight so they don't move much.

But if you put it under our lens of responsibility:

HTMX: Minimal layer 1, HTML carries the majority of the work under layer 2, and layer 3 is almost nothing.
LiveView: Layer 2 expands its capability, while layer 3 remains nearly non-existent. Same dance with the read window stretched to the length of the session.
DataStar: More machinery in layer 2 with the addition of server populated Signals allowing for some closer interaction with the client.
Astro(+ View Transitions): navigation(view transition) -> server(markup) -> client(islands). All 3 parts laid out explicitly.
Server Components(Next.js): Like Astro except shared client state is preserved.
SPA + JSON(React): Layer 3 grows until it merges with layer 1. And layer 2 is delegated to JSON APIs.
Sync Engine(Zero): Layer 2 becomes a persistent read of a replicated store, and layer 3 grows to hold a full local copy of it. Optimism over the whole dataset.

Every solution, with a bit of coaxing, is capable of expressing all of these. They differ in transport, window length, and how much affordance code you ship. So it comes down to efficiency and authoring. Which means one framework could cover it all, if each responsibility is adjustable.

A Modern Take

Nothing I've laid out is any different than how the base platform has always worked, but can we mirror this in a way that encompasses the full spectrum of the past 30 years?

I'm going to paint a picture using our 3 responsibilities with Solid 2.0.

Navigation: Delegation and progressive enhancement

Solid's router owns nothing in the render tree. There is no <Link>(or <A>) component. Instead our JSX compiler registers a claim on every a[href] and form[action] element it creates, and server-streamed content gets the same claims swept over any subtree the runtime renders.

// lib/users.ts
export const renameUser = action(
  async (id: string, formData: FormData) => {
    "use server";
    updateUser(id, { name: String(formData.get("name")) });
  }
);

// routes/users/[id].tsx — plain HTML. The compiler claims the
// anchor and the form. The router intercepts both. Works before 
// hydration and after.
<a href={`/users/${id}`}>{user().name}</a>
<form action={renameUser.with(id)} method="post">
  <input name="name" value={user().name} />
  <button>Rename</button>
</form>

Note: There are no components in this markup.

A SolidJS router consumes those claims to manage aria-current, active classes, and interception. This means server-rendered markup with zero client components participates fully in client-side navigation. So it works not only with "No JS" but with JavaScript with no interactive components.

Forms and buttons delegate to server function actions the same way. You hoist your preloads and invalidation correctly and single-flight mutations mean one round trip settles every piece of UI the mutation invalidated whether that UI is JSON-fed client components or server-owned markup.

Content: Reactive reads over the wire

Solid's powerful protocol for layer 2 stands on our "use server" functions. Solid serializes across the boundary with Seroval, which handles not just plain data but async structures, like Promises and async iterators. The communication between server and client is about the data, including data that hasn't settled yet.

export async function report(id: string) {
  "use server";
  return {
    title: await getTitle(id),
    // AsyncIterable<string> — crosses the wire as-is
    progress: watchProgress(id), 
  };
}

// client: the iterable's latest yield is just a reactive read
const r = createMemo(() => report(props.id));
const progress = createMemo(() => r().progress);
<h1>{r().title}</h1>
<p>{progress()}</p>

More than that, the reactive graph propagates over the wire. On the server, every expression feeding the client is an open binding for the life of the response. When a promise settles or iterator yields the server re-runs the expression and sends the new value to the client to be replaced or morphed.

So far I've showcased this in examples around the original response, ie what happens during hydration. Even if the content chunks stream in as they initially are ready, we can continue to update the stream in place as long as the request stays open.

But the same can be true of server function requests after the fact. We can send back would-be static markup, "Server Components", and have their reactive graph never ship to the client while still doing these streamed pinpoint updates. We will be announcing the preview for our Server Component feature soon (but if you look you can already see fully working examples in our repo).

export async function countdown(n: number) {
  "use server";
  const ticks = tick(n); // AsyncIterable<number>, one per second

  // returning a function returns a Server Component
  return () => {
    const count = createMemo(() => ticks);
    return <p>Counted to {count()} of {n}</p>;
  };
}

// client — zero component code ships for this
const Counter = dynamic(() => countdown(10));
<Counter />

Because the communication is one-way with a single authoring model, the transport is pluggable. Today we use Request/Response, so it lives as long as the request is open and you reconnect as needed. Swap in something persistent like SSE or a socket and the same server component becomes a non-terminating live component.

// request/response — left side of the grid
export const getAuction = GET(async () => {
  "use server";
  return read();
});

// persistent — right side of the grid
export const liveAuction = live(async function* () {
  "use server";
  while (true) { yield read(); await changed(); }
});

// the consumer doesn't care which one it got
const [auction] = createOptimisticStore(() => liveAuction(), {});

What makes this safe is what LiveView's failure mode teaches us: The server's live graph must be a re-derivable projection of durable state. It is never the source of truth. Reconnection doesn't depend on sessions, event replay, or anything that dies with a process.

Affordances: An async-aware graph that hydrates once

This is an area SolidJS has excelled in. But in 2.0, async became native to the graph. A value arriving from the server content channel and a value computed locally are indistinguishable to the consumer.

Optimism is a first-class primitive. It isn't just something bundled with the server functions or query caching library. Optimism represents any uncommitted state predicted over async, whatever the async source. It's a general concept. It doesn't just represent what some might consider "lying to the user", it doesn't have to masquerade as an invisible success. It represents any predictive ephemeral affordance. It either settles eventually as truth or it is reverted, but it never outlives its transaction. It prevents getting out of sync.

const [auction, setAuction] = createOptimisticStore(() => liveAuction(), {});

const placeBid = action(function* (amount: number) {
  // overlay — reverts on settle
  setAuction(a => { a.highBid = amount });
  // mutation - the write goes up
  yield bid(amount);
  // hold until truth comes back down             
  yield until(() => auction.highBid >= amount);
});

This all works because we never hydrate more than once. After startup, the server should never render a client component as client state has diverged from anything the server could know. This is a critical naive breaking point in HTML Partial and Islands solutions that share client state. Hydrating after state has updated is a recipe for hydration mismatches. While we can safeguard during the initial streaming progression, that isn't a realistic proposition over the life of an application.

A rule like that only holds if the system enforces it. Every piece of server content is keyed by the call that produced it, the function and its arguments, the same key a query cache would use. Content arriving on any transport only ever writes to that address's store, and mounted UI pulls from the address it's bound to. There is no direct connection from the network to the DOM. So a hover preload can't clobber the page you're looking at, a refetch morphs in place while the client-owned ranges inside it survive, and a stale response doesn't pass a version check.

Under this unified model, initial load gets the same treatment without paying serialization twice. Client components claim their server-rendered nodes and boot makes zero requests. The only serialized records are values the client requires. Server-only content ships as HTML or as data, never both. The page markup is the payload. For server components, that means always one copy. View-source and search for any piece of content and you'll find it exactly once.

I once positioned this as "Facing Frontend's Existential Crisis", but now it is a solved problem.

Traversing the Spectrum

What makes this exciting is with the pieces above you are completely free to move the whole solution space and every point in between.

If you start in the lower left corner, that would be like a SolidJS app with no client components that just swaps server component chunks on server "use server" actions bound to <form action>. Server markup streams and morphs, and navigation is handled without any client components.

The top left-hand side is when we extend layer 3 until it dominates and you have the SPA and there are no server components or server rendering at all. Just JSON APIs.

And we can continue to traverse over the top to the right-hand side by the way of persistent "use server" functions and our granular optimistic layer. Solid's live and until operators help close the gap when the client state is streamed in as available. I'd still use a dedicated sync engine, but the base primitives alone do a good impression.

Finally, the lower right corner, is closer to where we started. Except this time our server components have reactive bindings and their connection is persistent. No client components, just our same "use server" action protocol to write back, while our reads stream fine-grained markup partials over the wire. In this world, even the server components could be optimistic depending on how you write your actions, and until again gives us a mechanism for completion acknowledgements.

The incredible part is that this required nothing that users of Solid 2.0 aren't already familiar with. Async Signals and use server. With that, all these experiences are authorable using basically the same patterns, in the same framework, even in the same application.

Conclusion

It goes back to where we started. A few pieces that have been sitting in front of us this whole time.

The browser owns navigation and affordances. The server owns content. Communication is a loop with writes travelling as navigation and content travelling as one-way reads. And the transport and the response window should be configurable without changing the shape of authoring.

Everything from HTMX to LiveView to islands to the SPA is a coordinate on this grid. The differences between them are efficiency and ergonomics rather than expressiveness.

What makes this more than an exercise in categorization is that all the hard pieces are built. We serialize and hydrate once. The reactive graph serializes its own updates. Content is stored by address, so stale hydration can't be represented.

It comes as little surprise to me that Signals can act as that common representation on all sides. Sync and async. Server and client. Stateful and stateless.

This is stupidly ambitious. RSCs only aimed to provide the left half of the grid and many felt they still fell short. The HTML-over-the-wire camp has aimed to provide the bottom half, but ignoring the client is ignoring an entire responsibility.

And yet, this is a future that I want to live in. One where choosing a framework doesn't require you to choose a religion. And one, from my perspective, that is already here.

SpellBook of Skill: The Twin Project Nobody Asked For, But I Built Anyway 🧙🏻‍♂️

Domenico Tenace — Mon, 21 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

A while back I launched Spellbook of Prompt, my curated collection of prompts organized by use case. It's been out there growing steadily, and at some point while adding new entries I kept thinking: prompts are only half the story. Knowing how to build something matters just as much as knowing what to ask an AI to do.

So I built the twin project. Meet Spellbook of Skill, a curated collection of development skills, tutorials, and guides to help you level up your craft from fundamentals to advanced techniques.

Let's dive in! 🤙

What It Actually Is 🤔

Where Spellbook of Prompt gives you the incantation, Spellbook of Skill teaches you the magic behind it. It's structured, practical guides organized by category and difficulty, each one built to save time and actually get you somewhere, not just another wall of theory.

Every guide follows the same shape: a clear learning objective, a working code example, prerequisites listed upfront, and a troubleshooting section for when things inevitably don't work on the first try. The concepts are language and framework agnostic where possible, so what you learn actually transfers instead of being locked to one stack.

The whole thing runs on Astro with Starlight, same setup as Spellbook of Prompt, so browsing is fast and the docs feel consistent across both projects. It's a genuine sibling project, same philosophy, different content.

Built Entirely with OpenCode + OpenRouter + DeepSeek V4 Pro 🛠️

Here's the part that ties back to everything I've been writing about lately. I built Spellbook of Skill end to end using OpenCode wired through OpenRouter, running on DeepSeek V4 Pro 0813.

No manual scaffolding, no switching to a pricier model halfway through. The project structure, the Astro and Starlight configuration, the content schema, the initial category setup, all of it came out of that same combo I've been using as my daily driver. If you've read my previous pieces on DeepSeek's cost-to-quality ratio or on wiring OpenRouter into OpenCode, this is that setup doing real, shippable work again.

It's honestly become my proof of concept for "can a budget model stack actually ship a complete open source project." So far the answer keeps being yes.

What's In There Right Now 📚

The structure is organized by category, starting with:

Content Creation, structured prompts and guides for writing clear technical articles, the same kind of workflow I use for these posts.

More categories are marked as coming soon: coding and development workflows, DevOps and deployment, system design and architecture, design and creative development, career and professional growth.

It's early. I'd rather be upfront about that than oversell it. The foundation, the docs site, the contribution flow, the conventions, is all solid and ready. The content library is what needs to grow now, and that's exactly where the community comes in.

This Is Where You Come In 🤝

Spellbook of Skill is MIT licensed and genuinely open to contributions. Whether you want to add a new guide, improve an existing one, or just fix something that's broken, there's a clear path to do it.

The process is simple: search existing guides first to avoid duplicates, add or update a guide in the right category folder, include a clear title, description, and at least one complete working example, then open a pull request with a short summary. Guides should stay concise and actionable, list prerequisites and learning objectives, include a troubleshooting section, and obviously never contain real secrets or sensitive data.

Full details are in the CONTRIBUTING.md file if you want the complete picture before jumping in.

If you've got a skill you wish someone had written down clearly when you were learning it, that's exactly the kind of guide this project needs. Beginner content is just as valuable as advanced content here.

Try It Out 🚀

The live docs are up at spellbook-of-skill.netlify.app, or clone it and run it locally:

git clone https://github.com/Domenico-Tenace-Open-Labs/spellbook-of-skill.git
cd spellbook-of-skill
pnpm install
pnpm dev

Then open localhost:4321 and start browsing.

Final Thoughts 🌟

Spellbook of Prompt and Spellbook of Skill now sit side by side under Domenico Tenace Open Labs, one teaching you what to ask, the other teaching you how to actually do it. Together they cover more ground than either could alone.

If you're curious about the project, go star it, and if you've got something worth teaching, open a PR. This is exactly the kind of thing that gets better the more people show up.

The spellbook grows. 🔥

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

OpenCode + DeepSeek V4: The Budget Combo That Doesn't Feel Like a Budget Combo 🐋

Domenico Tenace — Tue, 01 Sep 2026 07:00:00 +0000

Overview

Hey everyone 👋

I've spent the last few weeks running most of my daily coding work through OpenCode wired to DeepSeek V4, both Pro and Flash. Not as an experiment, as my actual default setup. And the thing that keeps surprising me is how rarely I miss Claude or GPT for everyday tasks, while paying a fraction of the price.

I also used DeepSeek exclusively to generate an entire Astro template from scratch, Studio Pulse, which turned out to be a genuinely good test of what these models can actually do unattended.

Let me walk you through what I found. Let's dive in! 🤙

Quick Context on DeepSeek V4 🤔

DeepSeek V4 is an open weight, MIT licensed model family that went GA in two waves this year, V4-Flash on July 31 and V4-Pro on August 13. Both are mixture of experts models with a 1M token context window.

V4-Pro runs 1.6T total parameters with 49B active per token. V4-Flash is leaner, 284B total with 13B active. Both support tool use, function calling, and a thinking mode that effectively replaces the old R1 reasoning line.

The current API pricing sits at $0.435/$0.87 per million input/output tokens for Pro, and $0.14/$0.28 for Flash. Cache hit input drops even further, down to $0.0036 for Pro and $0.0028 for Flash. For context, Claude Opus output alone costs $25 per million tokens. A dollar buys you roughly 500K off-peak output tokens from V4-Pro, versus 40K from Opus.

That's not a small gap. That's an order of magnitude.

Setting It Up with OpenCode 🔧

Since OpenCode is model agnostic, plugging in DeepSeek is just a matter of pointing it at DeepSeek's API endpoint (or routing through OpenRouter, which I also do for some workflows). No special configuration, no compatibility layer, it speaks both OpenAI ChatCompletions and Anthropic API formats natively.

I keep both models available and switch depending on the task:

DeepSeek V4 Flash for quick iterations, small fixes, boilerplate, and anything where speed matters more than depth.

DeepSeek V4 Pro for anything that needs real reasoning, architecture decisions, or larger refactors.

Switching between them mid-session in OpenCode takes one command. No restart, no reconfiguration.

What Actually Impressed Me 👍

The cost is almost absurd. Running a full day of development work, dozens of file edits, multiple refactoring sessions, test generation, through V4-Pro costs me less than a coffee. Through V4-Flash it's closer to pocket change. I stopped thinking about token budgets entirely, which changes how you work. You stop being conservative with your prompts.

Coding quality holds up. On Artificial Analysis benchmarks, V4-Flash scores 69.1 on the coding index, ranking 29th out of nearly 200 models tracked. That's genuinely competitive, not "good for the price," just good. For everyday tasks, boilerplate, CRUD logic, component generation, API routes, I couldn't tell the difference from more expensive models in blind use.

The 1M token context window is a real advantage. Both models default to a million tokens of context. For large codebases or long refactoring sessions where you want the model to see everything at once, this matters more than raw intelligence scores.

Tool use and function calling are solid. Agentic workflows in OpenCode, file edits, shell commands, multi-step tasks, worked reliably. I didn't run into the kind of tool-call confusion I've seen with smaller open models in the past.

Cache hit pricing rewards good habits. If you structure your prompts with static content first and variable content last, DeepSeek's caching drops input costs by roughly 88%. That's a meaningful incentive to write better prompts, and OpenCode's session handling makes this easy to leverage naturally.

Where It Falls Short 👎

Agentic capability trails coding capability. DeepSeek themselves and independent reviews are honest about this: the model handles individual coding tasks well, but complex autonomous multi-step processes need tighter task boundaries and more validation than you'd need with Claude Opus or GPT-5.5. Long, loosely defined agent runs are where it's more likely to drift.

No image or video input. V4 is text and code only. If your workflow involves reviewing screenshots or mockups, you're switching models anyway.

Pricing isn't fully stable. DeepSeek has already signaled a broader price increase without publishing new rates yet, and peak/off-peak tiers were introduced in mid-August. The eye-popping pricing I quoted above could shift. Budget for it, but don't assume it's permanent.

Less polished on ambiguous instructions. When a prompt is vague, DeepSeek tends to make more assumptions than Claude does. Being explicit about what you want pays off more here than with pricier models that are better at inferring intent.

Reasoning depth on genuinely hard problems. For architecture decisions with lots of competing trade-offs, V4-Pro is good but not at the level of the very top tier models. I still occasionally reach for something stronger when the stakes are high enough to justify the cost difference.

The Real Test: Studio Pulse 🚀

To really push this setup, I built Studio Pulse entirely through DeepSeek, no manual coding, no assist from another model.

It's a template for a full-service communication agency marketing site: multi-page structure with home, about, blog, and contact, dark and light mode with OS preference detection and persistence, SPA-style page transitions via Astro's ClientRouter, a blog powered by content collections with typed frontmatter, and accessibility handled properly, skip links, semantic landmarks, focus-visible outlines, reduced-motion support.

Stack is Astro 7 with Bulma 1.0.4, statically generated, dependency-light, pnpm as the package manager. Clean project structure, typed content schema, CSS custom properties for theming.

What stood out building it: DeepSeek handled the Astro-specific patterns (content collections, the loaders API, client router transitions) correctly on the first or second pass most of the time. The accessibility details weren't an afterthought either, I asked for them once early in the process and the model kept applying them consistently across new pages without being reminded.

It's live at studio-pulse-demo.netlify.app, MIT licensed, and available as a GitHub template if you want to spin up something similar.

Who Should Try This Combo 🎯

If you're cost-conscious and building things where "good enough" coding quality is genuinely enough, which is most day-to-day development, this setup is hard to beat. Side projects, templates, internal tools, prototypes, all of it fits well within DeepSeek's strengths.

If you're running agent pipelines at scale where token costs actually matter to your bottom line, the math here is compelling enough to at least test against your current model.

Where I'd still reach for something else: safety-critical code, deeply ambiguous architecture decisions, or long autonomous agent runs with minimal supervision. That's where the extra cost of a stronger model still earns its keep.

Final Thoughts 🌟

I didn't expect to make DeepSeek V4 my daily driver, but that's what's happened. Between OpenCode's flexibility and DeepSeek's pricing, the barrier to just trying things dropped to nearly zero, and that changed how much I experiment.

Studio Pulse is proof that a fully model-generated project doesn't have to feel like a rough draft. It's not a toy, it's an actual usable template with real attention to detail.

Is DeepSeek the best model on the market right now? No. Is it the best model per dollar? By a wide margin, yes. And for most of what I build day to day, that's the metric that actually matters.

Happy coding! ✨

🌲 Links: https://links.domenicotenace.dev/
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs
📰 Newsletter: https://domenicotenace.substack.com/subscribe

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Nobody Argued For Your Stack

Ryan Carniato — Thu, 27 Aug 2026 18:34:44 +0000

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React. This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release. Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is:

I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle.

Then I checked the Internet Archive and realized this has been there since at least April 2026. Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument.

Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed.

Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters.

Why This Matters More Than It Used To

It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses this predates AI by decades. Optics and politics have always beaten pure technical merit. The weight of Facebook definitely helped React's early propagation.

But a narrative used to come with friction. It was always in the race, but it couldn't outrun the argument. This has changed for two reasons:

First, execution cost has collapsed. Bun's rewrite from Zig to Rust — about a million lines — was executed almost entirely by Claude agents in days, not months. And before you start thinking "lock-in", going the opposite way, while not as easy, has never been easier. Migrating from Rust to Zig or React to Solid has never been easier.

That sounds like good news. And it is. When migrations took years of human effort, cost put a damper on fashion. Now execution is a lot cheaper in all directions. The only thing left is the reason. Which suggests, on the surface, these decisions should be rooted in technical merit. But when narrative is what sets the direction, you start to see how a line buried in documentation is worth an essay.

Second, verdict production has been industrialized. Cognition just migrated its marketing site from Astro to Next.js. A content site. Astro's home turf, by near-universal consensus, including from people with no stake in the fight. The migration was performed by Devin itself and published as a case study: the agent made the changes, tested them, recorded its own verification runs. No repository, no before-and-after numbers, no benchmark. The output wasn't the site. It was the story.

And believe me, there is no shortage of these stories. Migrations are now the demo genre of the agent industry. Theo Browne was trying to tell me this a couple weeks back with some very good advice. But it hits a lot harder when you feel it firsthand. Migrations that demo flawlessly are, by definition, the ones moving toward what the agent writes best today. Marketing departments are generating "X → dominant library" verdicts at a rate organic engineering decisions never would.

So you see the tension. Stacks have never been more sensitive to circulating verdicts, and verdicts have never been produced faster or with less reasoning attached.

What an Argument Looks Like

These aren't unheard of. They are just becoming rarer.

When Bun moved from Zig to Rust, Jarred Sumner made the case in public, with receipts. He talked about bug classes and memory management issues. You can disagree with the argument. People have, point by point, in public. That's the value. An argument can be engaged, checked, narrowed, refuted, or strengthened. A verdict can only be repeated.

Or look at TanStack's journey with React Server Components on tanstack.com. They spent the year almost arguing with themselves. When tanstack.com adopted React Server Components, they wrote it up and measured it. When they stopped using them, they did the same: What changed, what replaced it, why the tradeoff flipped for their specific case — while TanStack Start went right on supporting RSC as an opt-in primitive for everyone else. The reversal post calling the decision "uneventful" is a tell. A public reversal on React's flagship architecture, and it generated insight instead of heat. Because they delivered analysis instead of verdict.

That's what evaluation entering the public record looks like. jQuery didn't lose to React because a training set said so. It lost an argument, in public, on merit over several years. Every library you respect got where it is by winning that kind of fight. The flow of events I described earlier doesn't hold fights. It holds direction, and compounds on it.

The Argument Nobody Published

In all fairness, Cursor never issued a verdict. An experiment that "still needs careful review", then a congratulatory post on the Solid 2.0 RC release. But that post still characterized signals as "perf footguns" and "accidental fan out" — no numbers, nothing to engage — and reached straight for the React Compiler as the cure. No bad faith required. The diagnosis and the cure just came from the same place.

When I tried to reconstruct the case Cursor could have made, it turned out to be interesting. Far more interesting than "perf footguns."

The post obviously highlighted agents were "quite bad at writing good Solid code," everything "ended up being accidentally tracked." While my "Solid-brain" struggles a bit to imagine what they were doing to get there, I don't doubt it for a second. An agent that has internalized React's mental model will write Solid like React, and Solid written like React is bad Solid. I've also seen the reverse. The difference is when the agent fumbles React, the training data catches it. When it fumbles Solid, the training data shrugs. This is a pure numbers game.

But the same post contains a decision in the opposite direction. They're also moving from Tailwind to StyleX. This is a migration against volume. What StyleX offers instead is that agent mistakes get caught. Styles are typed with deterministic merge order, so a hallucinated class is a build error.

Put side by side, one conclusion can be made: make agents' mistakes cheap. Two ways to achieve that. Volume and verification. React (with its compiler) wins on volume and arguably on verification. StyleX loses on volume and wins decisively on verification. I won't pretend under this lens with Solid 1.0 this is a particularly comfortable place for signal-based reactivity. But it's also, not coincidentally, where Solid 2.0's design attention has gone.

That analysis, volume and verification as two axes, is concrete, checkable, and useful. It implies testable claims and gives every framework author a design target. It might also be wrong. I reconstructed it from a benchmark-free post and my own inferences. Cursor's actual reasoning may be entirely different.

The StyleX decision is even more interesting. Agent-driven development can move against volume when verification wins. There is a second angle that small technologies can embrace. To me, this isn't a new revelation, but one where practice confirms theory.

What Happens If Nothing Changes

If you follow this thinking to its logical conclusion, outside of a few exceptions, each layer collapses on its most popular solution today. Frontend converges on React. Systems converges on Rust. Scripting converges on Python. Even the sites that are just pages converge on Next, fit be damned. That's a monoculture, arrived at not by anyone deciding libraries on their merits, but by a system that can no longer distinguish "abundant in the training data" from "better."

If you are a React fan, you should still be concerned. React was good because it had competition. Hooks arrived in a world where composition patterns were being explored. The React Compiler exists, in part, as an answer to the question signals-based frameworks spent years forcing: Why should the developer pay for re-rendering the world? React's greatest strength has always been its ability to metabolize pressure from outside. A monoculture doesn't just kill the alternatives. It kills the pressure. An ecosystem without pressure doesn't stay good. It stays stuck.

There is a path back. Teams publish analysis, not verdict. Model vendors evaluate what they ship in public. Libraries learn from StyleX's example and bank on verification. And the rest of us learn to distinguish output from argument before we amplify it. The last one we've been struggling with since the dawn of social media.

In the meantime, we can keep generating our rules files, llms.txt, docs over MCP, curated examples. We do all of it for Solid 2.0, and it helps a lot. But context is borrowed, not owned. It has to be injected into every session, by every tool, forever, while the inertia works against you for free.

Where Does the Next Idea Come From?

I want to leave you with a more probing thought. The question this all comes down to isn't whether Solid survives. We're fine. We are shipping the biggest release in our history, with a community that chose this framework on purpose and, more importantly, knows why.

The question is where the next idea comes from.

Every paradigm that has mattered started as something the establishment couldn't write. React was mocked for almost a year over JSX. Markup in JavaScript? Are you insane? What about separation of concerns? If today's machinery had existed in 2013, models trained on a web that was all jQuery and Backbone, docs canonizing migrations everyone was already making, verdicts circulating months ahead of their arguments, do you think it could have gotten past that stage?

It didn't win because the defaults favored it. It won because people made a verifiable case in public. And I don't think the mechanisms are gone. Migrations have never been cheaper, in every direction. The door out of any monoculture has never been more open. We just need to keep analysis as part of the conversation even as we distance ourselves from the implementation. That's being informed. That's taking responsibility.

My AI Content Journey

Ryan Carniato — Wed, 19 Aug 2026 16:47:10 +0000

I apologize ahead of time, what follows has no tooling applied to it. No grammar checks, no AI, and no edit passes for flow. It might be a bit rough, but that's important.

For those who know me, I've written hundreds of articles over the last 8 years. I realized very early into my journey of creating SolidJS that education was going to be a fundamental barrier. React's rhetoric had consumed the frontend space in such way that the discussion of different ideas was not welcomed warmly. It may have started with the ideas, but the complexity of the move to modern tooling had left many feeling overwhelmed. The term "JavaScript Fatigue" was being thrown around, and those who didn't sneak in before 2016 were subject to it.

My early writing was rough. I mean really rough. I'd try to articulate my ideas, but they were hard to translate. It wasn't that I didn't have decent command of the English language. I always had done well in school. But the ideas I wanted to articulate extended past code examples. They borrowed from years of observations and cross discipline learning. It would take the span of a whole article for me to get my point across and it was really easy to get lost in the details.

It didn't help that I wrote like I talked. Which is rather disjointed. When I used to type messages on ICQ and MSN back in the day I'd keep thumbing the "." as a way to convey to the recipient the pacing. The more "..." the longer the pause. I had needed to communicate at work, obviously and had gotten used to rewriting my emails on average three times so that I could cut out things that were unnecessary.

So I published my earlier articles on Medium in 2018 and fortunately for me, the early Solid community on Gitter and Spectrum started providing me edits. This pattern of reviewing my articles with the community never went away. Most of my articles today still appear in the Solid Discord days before publishing.

Stepping up my Game

At some point, a community member suggested I pick up Grammarly. Honestly, it was such a huge help. I always skipped words and commas in certain places. Given I had the free tier it would also hint when I phrased something a lot oddly so I could at least give a shot at rewriting it.

This was better but honestly it fixed less than you would think. I wasn't falling into the simple traps. But the writing wasn't really anymore clear. The big break through there was when I started getting my work published through online publications. Specifically, "Angular in Depth" in 2019 time period. They were really supportive of my content but they saw that it was missing the audience.

I remember at one point @layzee sat down with me and picked through an article with me showing me how to break my writing up into more paragraphs. I was accustomed to having a paragraph express what I considered a complete idea. That meant 6-8 run-on sentences. He was like no more than 3. Give them a break to sit with what you just told them. Add spacing and images to your articles for the same reason.

I didn't like this much at first because it made my articles longer. Too long as far as I thought. But it also forced me to really focus on what I wanted to say. I'd need to do one editing pass to break things up and another to eliminate the cruft.

At this point, Solid was picking up steam, and there were others in the community that were interested in seeing us succeed. Some of you may not know but Theo Browne (T3.gg) reviewed many of my articles during the 2020-2022 time period. He had a lot less tolerance for sentences that didn't flow and he would go through and gut all my unnecessary phrasing. All the "And ...", "In fact", "But Honestly", "Actually..", "Simply put,". He emphasized it didn't add anything. By doing that I was able to save those for when I wanted to make a real impact.

So that gives you some insight into where my writing process was through the end of 2025. I'd write something rough, do multiple passes myself, run it through Grammarly, feed it to the Solid community. Have feedback, then pass it to a few specific reviewers (although some like Theo were getting too busy to look at my work regularly). And half a dozen people and twice as many hours later we had an article.

Enter LLMs

Now I never prompted an LLM intentionally before the end of 2025. As I have noted in previous articles, I was an AI laggard. Sure Gemini results would show up on a Google search. And I had dabbled with some image generation for Articles/Streams. But I did not use Chat LLMs directly at all. Funny enough, since late 2023 I had noticed two phenomena.

First, absolute garbage articles quoting my work in like "Best JavaScript Frameworks to use in 2023". At first I thought these were just low effort marketing articles. Some of them probably were. But after a while I came to recognize these as AI generated.

Second, people coming on to my articles and accusing them as being AI generated. My response would be, "Did you read the article?" There is no way AI makes that argument. But the general feedback was that the articles were vague because they tried to pack too much into a small space. And the move between macro and micro details was disorienting. Ironically my trademark writing style because it was born out of necessity.

I mostly pushed both of these aside. What had always mattered was the content. Those two couldn't be more obviously different. Even if I did my own yearly JavaScript summaries, any one with half a brain could tell the difference. My articles had takes that existed nowhere else and provided a deep insight.

Trying LLMs for Myself

I was working on Solid 2.0. High-level design stuff late 2025 and I decided to give LLMs a try. Not for coding just to talk through the problem and see if they had an insight. I believe GPT 5.3 was out but I was just using CoPilot for free which was on 5.1. I found the process very frustrating because it kept losing details. I realized pretty quickly I needed to have it write things down.

As I got more excited about formalizing these designs I got AI to write short explainers about what we had talked about so that I could share them in Discord. This was very helpful since my HackMDs I had been writing were cryptic and people could immediately understand what I was talking about this way. Maybe not deeply but the gist of it.

Summaries of really high level stuff. The thing I was particularly bad at writing. It was very common in the Solid community for people to post AI written summaries on my writing since no one seemed to get what I was saying and I didn't have time to clarify while working on cutting edge things.

But every time I tried to get AI to really capture the real point behind my stuff it missed. Even after moving to Cursor and frontier models. AI could write something coherent but it was never the position or argument the way I'd make it. As before it didn't have my original positioning/takes. Occasionally it would come up with something interesting like: The Architecture of Temporal Determinism. But that was a rare occurence.

AI Assisted Writing

So at some point, tired of the Yellow squigglies I was getting from Grammarly--the ones that you need to pay for that refer to structural issues--I was like why don't I feed my article to the LLM instead? And I was amazed.

It took what I wrote and it sounded coherent. No initial 3 passes, no Grammarly, no community pass, no special editors. Yes I still ended up doing all of those but it was like it skipped to the finish line. There was very little feedback down the line.

The part that really loved was it simultaneously made my writing shorter while bringing back that pacing I heard in my head. The old pauses. The way it used semi-colons and -- was exactly what I intended. No broken sentences. No confusion on flow. It just read perfectly.

I was so impressed. There were a couple things I thought odd. It really liked sumarizing at the end of each section. I had a habit of connecting sections with a probing sentence for sure, but AI liked to try to tie things in a bow. And those additions were the place that I immediately cut out. Easy to see. But for the most part it was like what I had always been looking for. I'd struggled being terse and clear and it just gave it to me, in mostly my own words.

I released my first article like this:

Ryan Carniato for Playful Programming

Mar 13

Two React Design Choices Developers Don’t Like—But Can’t Avoid

#javascript #webdev #solidjs #react

9 min read

and I was pretty excited. This was an important article. It was where I was going to do the unexpected: express to the world that React, a long time competitor philosophically, was actually completely right about a few things. It was controversial. It was honest. And it needed to be clear more than anything I'd done before.

In hindsight, the response should have been obvious. People couldn't get over the AI phrasings in places. That's the thing. It only takes a couple of places for the radar to go off. I had the before and after AI for this article I actually showed it on stream. I wrote every bit of the source. The things that people were accusing being AI were as much me. I thought that by taking accountability, owning it would be enough.

But this kicked up a rage. And I admit I felt a bit resentful. This is critical work. From my perspective earthshaking and all people could seem to talk about was that I used AI to make the message clearer. I had been dismissed in the past for being vague or hard to follow. Now I was being dismissed for the opposite.

I had also received similar feedback on using AI-generated covers. Previously, I was picking up random free images online. It took some cleverness to choose the image but it wasn't some work that I put in. AI had actually given me images suitable to my content. Again it seemed so much better to me. I'm not an artist. But somehow it wasn't acceptable. It seemed irrational to me. I put more effort in, to come up with a better result. I was clearly missing something.

Another Attempt

Last week, I took that lesson and tried something a little different when we dropped the Solid 2.0 RC release announcement. I had written release articles before but they were always tough. Short attention spans and a need to get to the point. And Solid 2.0 was proving difficult. It just had too much stuff in it. A point form list undersold it but there was no way I was going to be able to get into all the details.

I had written an article showed it to AI and it had done some edits. And this time I was more careful to cleanup language. Not because I thought it was bad but because I knew it would trigger people. However, no matter what I did the article was way too long. At some point the agent suggested the obvious. Make a follow-up article series. It would summarize the some of the pieces we would be removing. And we would be set.

I looked at the work and I was impressed it had kept my opening and sentimental parts and filled in the gap with the type of clear, to-the-point way that I'd expect in a release article. It was way shorter than what I had written and after a quick pass, everyone who reviewed agreed it was much more approachable. The language here was not nearly as AI-sounding because I didn't get it to really rewrite what I had written where it mattered. But obviously, even after human edits on the more marketing side there were still some traits.

Again, and I imagine it was because people didn't get to the end. The response was half about the use of AI in those point form lists. The general sentiment was that it was subtle but still enough to notice. It was genuinely a better article for it, it fit the purpose of the writing. But they couldn't see past it. Most of the article had the human soul, but a few point form lists ruined it.

Today

I had an odd week. It started with seeing an AI Gist comparing Solid 2.0 to Octane. I saw that Dominic had responded with some agent-assisted prose, and I knew there was no way I was going to keep up with that discussion while pushing forward all the post-release things I needed to do without doing the same. We literally had the Agents arguing our points. You can tell they are our points. Our fundamental positioning, but it isn't our voice.

But the most warmly genuine thing happens at the end. We both remove the Agent and have a real discussion. I think we both realized how ridiculous it had become.

Now, the problem is that it isn't too far from how we are working today. When I have an agent review and issue or PR even if I'm driving it, reviewing the changes, and setting the response, it no longer sounds like me. It's easy to justify the reasoning.

Look at how many open issues/PRs are on SolidJS right now. There is no way we could be as responsive without it. We've almost closed out every issue. That is between issue submitters using agent-guided PRs and from our own agent work. But a certain human aspect is gone. I used to go on every PR and write a thank you note personally and I know I haven't done that as much the last couple months. I can justify it, but there is a human cost.

I'm also about to release another article. I'm trying yet another approach to this. Where I write it, feed it to AI, but never let AI edit the actual article. When it identifies something that it rewrites, I take that as a sign my writing isn't the best there and read what the AI wrote, then minimize the window and write back the structure myself using my own voice. We'll see if this lands better.

It's tricky because I can already hear LLMism in my own writing. According to critics, I was already pretty close years ago. And if I already think it sounds better than what I write I have a bias. But it's the most honest thing I can do to produce good content. And I mean good content. Not whatever this is. So I'm going to try again. I'm still figuring this out.

That's all we can keep doing.

Functional languages are heavily imperative.

Mike Pearson — Mon, 17 Aug 2026 07:39:18 +0000

This article will seem full of contradictions.

Even writing it feels like a contradiction: Why am I digging through academic Haskell papers from the '90s right in the middle of my AI psychosis moment? Literally, as I write this, I am running my first experiment with an agent delegating tasks to another agent. So why am I spending time on esoteric academic nonsense instead of giving in to the vibes and building my loopy graphy software factory?

I am writing this because AI is a nuclear amplifier on the patterns we establish in our codebases, and we literally do not have the right terminology to establish scalable patterns. Nobody has the answers we need because nobody even has the right terminology to talk about it.

Two Dimensions, Not One

Industry dogma says that functional and declarative are synonyms—that code is either side-effectful and imperative, or pure and declarative:

But functional and declarative are independent dimensions:

Code that is both functional and imperative debunks this, and so does code that is both side-effectful and declarative.

Both exist!

"Imperative Functional Programming"

Simon L Peyton Jones and Philip Wadler helped create Haskell, which is a beautiful, pure functional programming language.

In 1993 they wrote a paper called "Imperative Functional Programming." The title may sound like an oxymoron, but it isn't.

The functional programming community had been struggling with how to manage side-effects like I/O, and these co-creators of Haskell proposed a way to decouple the expression of I/O commands from their execution.

But they noticed something:

It will not have escaped the reader’s notice that programs written in the monadic style look rather similar to imperative programs. For example, the echo program in C:

echo() {
loop: a = getchar(a);
    if (a == eof)
        return;
    else { putchar (a);
        goto loop; }
}

In Haskell:

echo :: IO ()
    echo = getcIO 'bindI0' \a ->
    if (a == eof) then
        doneIO
    else putcI0 a 'seqI0'

Does the monadic style force one, in effect, to write a functional facsimile of an imperative program, thereby losing any advantages of writing in x functional language?

Nope! Jones and Wadler list two advantages that remain:

List operations (like mapand append) can still operate on monadic commands
Effects can be expressed without immediately executing them. "It's a bit like being able to define your own control structures in an imperative language."

Recognizing the imperative structure of the Haskell monadic pattern does not mean we have to abandon the advantages that are inherent in pure functional programming.

But it is still imperative structure.

"Lazy Imperative Programming"

John Launchbury, another creator of Haskell, wrote a paper the following year called Lazy Imperative Programming.

In it he says,

Imperative features were introduced to Glasgow Haskell for expressing input and output.

Could this be plainer? Haskell has imperative features.

And the Haskell code that uses them is imperative. Also from his paper, an "Imperative Scan Left":

writeVar is an imperative statement, which is why this is an example of imperative code—written entirely with pure functions!!!

The paper has many other references to imperative stuff, including this:

In a strict imperative framework such as the IO monad (and most imperative languages), no value could be returned until the whole of the list was traversed. Using lazy sequences, however, this is not the case. If only the head of the list is required then very little of the computation is performed: the variable is allocated and initialised, it is read, and the list returned with that value in the head. If even less is required, merely whether the final list is empty for example, then the variable is not even allocated as only xs needs to be examined in order to give the structure of ys.

🤯
This is insanely cool.

Again, not everything in Haskell has to be declarative for it to still allow for incredible execution properties!

The "Imperative Feel" of Concurrent Haskell

Paul Hudak (another creator of Haskell) and Conal Elliot wrote a paper in 1997 where they weren't happy with the "strongly imperative feel" of Concurrent Haskell—even though it was 100% purely functional.

(Side note: I owe my passion for programming to this paper. More on that later.)

Here's an example of what that pure functional approach with an "strongly imperative feel" looked like:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

puTMVar box 42 expresses a command to set box's value to 42.

In the authors' own words,

While this system is purely functional in the technical sense, its semantics has a strongly imperative feel. That is, expressions are evaluated without side-effects to yield concurrent, imperative computations, which are executed to perform the implied side effects. In contrast, modeling entire behaviors as implicitly concurrent functions of continuous time yields what we consider a more declarative feel.

It is not a coincidence that the definition of "imperative" in English is "expresses a command" and that a line of code that literally "expresses a command" had an "strongly imperative feel"—even in Haskell.

But the authors were dissatisfied with that "imperative feel"—so they invented functional reactive programming (FRP):

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Just a single declaration. Nothing here expresses a command at all. putMVar is 100% imperative, while this is 100% declarative and 0% imperative.

Note on "more declarative" and monoparadigmatic dogma

Since the industry dogma in the 1990s was "functional = declarative", they had to call FRP more declarative. Concurrent Haskell was already declarative, supposedly, by virtue of being in Haskell—so this had to be extra declarative 🤷

And I say that with great admiration for these authors, because I owe my passion for programming to this paper. This was the origin of both RxJS and signals, which I love... very much. Too much for many people.

The "Lazy Imperative Programming" paper was more contradictory. The author often contrasted Haskell with "imperative languages," while dozens of times referring to features within Haskell as imperative.

On the one hand, functional languages are commonly more expressive and easier to reason about than imperative languages,

After reading 20 or so papers from the 1990s talking about programming paradigms, you will understand that the terminology was extremely entrenched. Academics classified programming languages into rigid categories to help explain the programming patterns of the time.

Functional programmers were especially guilty of reinforcing this reductionism, since they were a minority of programmers and had to fight against the grain with every rhetorical tool they could. Branding functional programming languages as automatically 100% declarative was an enticing selling point—even though we have many Haskell creators very plainly referring to features within Haskell as imperative.

Also, in the 1990s very few "imperative languages" had added much functional features, having not had to deal with much concurrent processing yet, which meant languages really did mostly fall into neat categories; multi-paradigmatic languages were not the norm like they are now. The concept of entire languages as "imperative" or "declarative" somewhat applied back then, but today is a nothing but a leftover from decades of synchronous code that all matched the same 2-3 structural patterns.

We have to make a mental note of this history, but if we do not push to correct the terminology, it will continue to confuse developers and AI. Many developers think that stuffing imperative features between < > characters magically makes them declarative because it's part of HTML, a "declarative language." Some are attempting this and creating masses of spaghetti code that only cosmetically looks different from the imperative JavaScript spaghetti they were writing last year.

There are no "declarative languages" and "imperative languages", as much as it would simplify selling them. There are commands expressed in code, which are imperative by the purest definition; and there are features and behaviors declared without scattered commands controlling them from elsewhere.

Conclusion (Imperative Functional Programming)

The literal precise English definition of "imperative" is something that expresses a command. That is what these pure functions are doing in Haskell and other functional languages. This should already rest the argument.

But even the less precise definitions of imperative programming focus on structural descriptions written in code rather than execution details:

"Imperative programming involves writing programs as sequences of explicit commands that are executed in order from top to bottom." https://builtin.com/articles/imperative-programming
"logic encoded as a sequence of ordered operations" https://en.wikipedia.org/wiki/Programming_language
"Imperative programming focuses on describing how a program operates step by step, rather than on high-level descriptions of its expected results" https://en.wikipedia.org/w/index.php?title=Imperative_programming
"With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal." https://learn.microsoft.com/en-us/dotnet/standard/linq/functional-vs-imperative-programming
"Imperative programming languages are composed of step-by-step instructions (how)... By contrast, in declarative programming, the desired result (what) is described directly." https://www.ionos.com/digitalguide/websites/web-development/imperative-programming/
Imperative programming is a paradigm where you explicitly state how the program should achieve the desired result. https://octopus.com/devops/infrastructure-as-code/declarative-vs-imperative-programming/

It's very clear that Haskell and functional programming languages are extremely cool with the flexibility they afford for all kinds of things, including the execution of side effects.

But Haskell has features that enable writing literal imperative commands even with pure functions. This results in code that is structured imperatively: Explicit commands incrementally adding to behavior described elsewhere. The instant a single command appears, it completely takes away the declarative quality of describing the final result of something up-front. The imperative features of Haskell are not just less declarative; they are completely anti-declarative.

Functional programming can be imperative.

Declarative Side-Effects

RxJS

RxJS enables fully declarative code, despite latent side-effects.

RxJS actually came from that Fran paper we looked at earlier, which proposed a way to turn this kind of Concurrent Haskell:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

into this:

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Neither of these trigger side-effects, but the declarative version structures the code as a single description of a complete, final logical result (a behavior over time). The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

The same structural move can be made in side-effectful code:

const box = Promise.withResolvers();

setTimeout(() => {
  box.resolve(42);
}, 1000);

const result = await box.promise;

const box = await lastValueFrom(
  timer(1000).pipe(map(() => 42)),
);

Both of these trigger side-effects when executed, but the declarative version structures the code as a single description of a complete, final logical result. The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

These four code snippets alone are enough to complete our four quadrants:

But let's look at some more common declarative side-effects.

HTML

"HTML is declarative" is often said. And it's mostly true (see above callout "Note on "more declarative" and monoparadigmatic dogma").

Yet the entire point of HTML is a side-effect: You being able to look at beautiful interfaces like this:

It's not just the DOM that's a side effect though. The HTML rendered in the page can itself trigger other kinds of side effects, like network calls:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" />
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
<!-- ... -->
<img src="https://storage.googleapis.com/blog-images-backup/1*tY3o3UFtBaMQ103en48qxA.png" />
<iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ" />

Nondeterministic Declarations

`Math.random`

Math.random() technically produces a side effect because it relies on and mutates a hidden global internal state (the seed or PRNG algorithm pointer) inside the runtime environment to generate its next value.

But this is still totally declarative:

const x = Math.random();

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...

const now = Date.now();
const date = new Date();
const perfNow = performance.now();
const randomBytes = crypto.getRandomValues(new Uint32Array(1));
const uuid = crypto.randomUUID();
const hrtime = process.hrtime();
const uptime = process.uptime();
const memoryUsage = process.memoryUsage();
const freeMemory = os.freemem();
const battery = await navigator.getBattery();
const windowWidth = window.innerWidth;
const visibility = document.visibilityState;
const online = navigator.onLine;

All of these are completely declarative. They are declarations of final results, and no subsequent step-by-step (or any) imperative code is involved.

But they are not pure functions. They don't have side effects, but they have side causes, so they still are not functional. So while they aren't examples of declarative code that causes side effects, they are examples of declarative code that break rules of functional programming, showing that these are independent dimensions.

Declarative "Pure" Functions with Side-Effects

CPU

const fib = (n: number) => n < 2 ? n : fib(n - 1) + fib(n - 2);
const result = fib(50);

Everything here looks pure as the driven snow, and it's definitely declarative.

No side effects at all, right?

In fact, it triggers 40,730,022,147 calls, which means that its side effects are so severe that I really don't recommend pasting that into dev tools and running it. You think jQuery has interesting side effects by reaching into the DOM and changing the behavior of random things, but this will change the behavior of everything on the page. Namely, it eliminates it because it locks up the CPU.

Memory

new Array(2 ** 30).fill(0);

No side effects here, right? It's declarative, at least.

However, this might get compiled into assembly code that looks like this:

mov     rdi, 8589934592
call    malloc

mov     rcx, 1073741824
mov     rdi, rax
xor     eax, eax
rep stosq

There is a huge side-effect in this code: call malloc requests 8589934592 = (2 ** 30) × 8 bytes = 1,073,741,824 × 8 bytes ≈ 8 GiB of memory.

There may be guardrails against creating arrays this big. I didn't feel like testing it. But there is a variation that may not be prevented:

Array.from({ length: 1000 }, () => new Array(1_000_000).fill(0));

This time each inner array has only 1 million elements, but there are 1000 of them, so 1,000,000,000 total elements.

Here are some possible side-effects:

The page or Node.js process becomes unresponsive while the runtime tries to allocate and initialize the array
In a severe case, the browser tab crashes because it exceeds its memory limit.

And yet, it's still declarative.

Conclusion (Declarative Side-Effects)

Declarative and functional are not synonyms. Declarative code is about how a computation is structured: describing a result rather than spelling out a sequence of commands to get there.

Functional purity is about what that computation depends on and affects. A declaration can trigger network requests, consume CPU and memory, observe clocks and runtime state, or depend on hidden mutable state without becoming imperative.

These are separate dimensions.

Conclusion

The point of separating these dimensions is not to win a pointless terminology argument. It is to make better engineering decisions while AI is applying incredible pressure on our architectural patterns.

If we collapse functional into declarative, we lose the ability to talk precisely about what code is doing. Pure code can still be structured imperatively. Declarative code can still observe mutable state, trigger I/O, allocate absurd amounts of memory, or otherwise affect the world.

Structure and purity are independent properties of code that sometimes align, but DO NOT HAVE TO!

If the problem is hidden state, surprising effects, or difficulty reasoning about dependencies, functional programming can help with its explicit inputs, immutable values, pure transformations, effect isolation. And although I love functional programming, in my experience, most apps genuinely will never see significant consequences for not being purely functional.

However, most apps I have seen have suffered severely from being imperative: It always scatters control, with commands reaching across a system (spaghetti code), or behavior that can only be understood by mentally executing twenty steps across multiple contexts. Declarative code fixes this. Functional programming does not.

I am sick of saying I like declarative code and being told to juST UsE ELm or HASkElL.

People can't even understand the problem because they don't have the words to discuss it properly.

Now throw AI into this cross-talking mix of contradictions, and this is what we can expect:

This looks delicious, but can we please try to avoid it anyway?

Let's fix our vocabulary so we can learn real things about imperative code and steer humans and AI away from it.

OpenRouter: One API Key to Rule Them All 🔑

Domenico Tenace — Wed, 12 Aug 2026 07:20:51 +0000

Overview

Hey everyone 👋

Managing AI models in 2026 has gotten ridiculous. Anthropic key here, OpenAI key there, a separate billing account for Google, another for Mistral, and if you want to try DeepSeek you're adding yet another dashboard to the pile. It's chaos.

OpenRouter fixes this. One API key, one credit balance, 300+ models. I've been using it as the backbone of my AI setup for a while now, and recently I wired it directly into OpenCode, which made the whole workflow click into place.

Let me explain how it all works. Let's dive in! 🤙

What Is OpenRouter? 🤔

OpenRouter is a unified API gateway that sits between your application and the underlying LLM providers. You send a request to OpenRouter, it forwards it to the model you specified, and returns the response in a normalized OpenAI-compatible format.

The catalog currently covers 300+ models from every major provider: Anthropic, OpenAI, Google, Meta, Mistral, xAI, DeepSeek, Qwen, NVIDIA, and dozens of smaller ones. You switch models by changing a single parameter in your request. No code changes, no new integrations, no new billing accounts.

It's also OpenAI SDK-compatible, which means if you're already using the OpenAI client in your code, you change the base URL and the API key, and everything else works unchanged.

How It Works 🔧

The setup is three steps:

Create a free account at openrouter.ai
Add credits via credit card or crypto (no minimum purchase, no expiration)
Generate an API key and use it across all your tools

From that point on, switching models is just changing a string. If you were calling Claude Sonnet directly through Anthropic and want to test Gemini Flash or DeepSeek for the same task, you change one line. That's it.

Provider Routing and Fallbacks

One of OpenRouter's strongest practical features is automatic provider fallback. Many popular models are served by multiple infrastructure providers. If one returns an error or hits capacity, OpenRouter silently routes to an alternative and your request succeeds. You don't write retry logic for this, it just works.

There's also an auto-router mode: set the model to openrouter/free and OpenRouter selects the best available free model for your request based on what it needs, structured output, tool calling, image understanding, and so on.

The Free Tier

OpenRouter offers around 29 free models at any given time, including Llama 3, Gemma 4, DeepSeek Flash, Qwen3, and others. Free accounts get 50 requests per day without adding credits, and 1,000 per day after a first top-up.

The free model lineup shifts as providers change their policies, so treat it as a useful resource for prototyping, not a guaranteed production tier.

Pricing: What You Actually Pay 💰

This changed significantly in 2025. OpenRouter used to add per-token markups on top of provider pricing. That model is gone.

The current structure is straightforward: a flat 5.5% fee on credit purchases, and provider token prices passed through at cost. So if Claude Sonnet 4.6 is $3/$15 per million tokens at Anthropic, you pay $3/$15 on OpenRouter. The only overhead is the 5.5% you paid when you loaded credits.

The one additional charge: if you bring your own provider API keys (BYOK) and exceed 1 million requests per month, there's a 5% fee on usage beyond that threshold. Below 1M requests it's free to route through your own keys.

To put it concretely: loading $100 in credits costs $105.50. Everything you buy with those credits is at direct provider rates.

For hobbyists and developers running multiple models, this is genuinely competitive. For enterprises burning millions of tokens per day, negotiated direct rates might beat it, but you'd have to be at serious scale.

OpenRouter + OpenCode 🔗

This is the combination I've been running, and it's become my default setup.

OpenCode supports any OpenAI-compatible endpoint, which OpenRouter is. You point OpenCode at OpenRouter, set your API key, and from that moment you can use any model in OpenCode's model selector without managing separate credentials for each provider.

The practical benefit is flexibility without friction. When I want to try Qwen3 Coder for a refactoring task, I switch the model in OpenCode. When I need Claude Opus for something that requires stronger reasoning, I switch back. One balance covers everything.

It also means I'm not locked into any single provider's availability. If Anthropic has downtime, I route through Gemini or DeepSeek without touching my workflow. OpenRouter's provider fallback does the heavy lifting.

The Pros 👍

One API key and one billing account replace every separate provider integration you'd otherwise manage. For teams or individual developers using more than two models regularly, that alone justifies the overhead.

The OpenAI-compatible API means zero migration cost if you're already using the OpenAI SDK. Change the base URL, change the key, done.

Provider fallback is genuinely useful in production. You stop worrying about individual provider outages because OpenRouter handles the retry layer for you.

The free model catalog gives you a real prototyping environment at zero cost. Qwen3 Coder Free and DeepSeek Flash Free are capable enough for a lot of development tasks.

Transparent pricing with no hidden per-token markups. The 5.5% credit fee is upfront and easy to account for.

The Cons 👎

The 5.5% credit fee is real money at scale. If you're running high-volume production workloads, that overhead adds up. Direct provider APIs will be cheaper once you're large enough to negotiate rates.

Credits don't expire, but they also aren't refundable. You're committing capital upfront even if your usage patterns shift.

Free model availability is unstable. Providers can remove free-tier access at any time and OpenRouter has no control over it. Don't build a production workflow that depends on a specific free model being there next month.

Enterprise teams needing RBAC, per-team budgets, audit logs, and VPC-native routing will hit a ceiling. OpenRouter is primarily a routing and billing layer, not a governance platform. For stricter compliance needs, something like LiteLLM self-hosted or Portkey might be more appropriate.

The auto-router mode (openrouter/free) is convenient, but the model selection varies between requests. If you need consistent output style across sessions, pin a specific model ID instead.

Who Should Use OpenRouter? 🎯

OpenRouter is the obvious choice if you're using more than one or two AI models regularly and don't want to manage the overhead of multiple accounts and billing setups. For individual developers, it removes a real operational annoyance.

It's also the right call for tools like OpenCode that support BYOK or custom endpoints but don't manage multi-provider routing themselves. OpenRouter becomes the infrastructure layer your tool sits on top of.

Where it makes less sense: pure Anthropic shops that only need Claude, or enterprises with compliance requirements that need on-premise routing and audit trails. For those cases, the flexibility isn't worth the trade-offs.

Final Thoughts 🌟

OpenRouter started as a scrappy model aggregator with 30 models. In 2026 it's become the most important middleware layer in the independent developer's AI stack, and the pricing reform that eliminated per-token markups made it significantly more honest to use.

The combination with OpenCode is what made it click for me. Instead of managing Anthropic and Google credentials separately, I load credits into OpenRouter once and switch models from OpenCode's interface as needed. It's the kind of setup that removes decisions you don't want to be making mid-task.

One key, one balance, hundreds of models. For how messy the provider landscape has gotten, that's a genuinely useful simplification.

Happy coding! ✨

Hi 👋🏻

My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.

Don't forget to visit my social links to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/

🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

DEV Community: Playful Programming

Closed vs Open Source AI: Who Really Owns Your Data? 🔓

Overview

Closed vs Open: The Quick Version

Why Open Source Is Worth a Look

Your Data Stays at Home 🔒

No Vendor Lock-in 🔓

You Can Look Inside and Make It Yours 🛠️

The Catch

So What Should You Do? 🎯

Final Thoughts 🌟

Seasoned Developer Advice after 25 years in IT

Ask the question you are embarrassed to ask

Give coordination an owner

Make meetings earn their place

Write code for the person who has to change it

Leave the explanation you would want to find later

Think about the application after it leaves your machine

Review the code without making it personal

Make maintenance part of the plan

Keep learning through things you can use

Choose tools you can trust and understand

Build a way of working you can keep doing

My Windows 11 Laptop Was Struggling with Claude and Codex. Defender Exclusions Helped.

The folders I excluded

How to add a folder exclusion in Windows 11

Moving to European Digital Services, One Decision at a Time

Proton made the change visible

The corporate map is more complicated than the logos

Some changes need almost no migration

Replacing Notion meant building the alternative

Sometimes the correct migration is no migration

The process I use before changing a service

Change the next decision

Emanuele BartolesiFollow

INP and Partytown: give the main thread back to your users

Introduction

INP in a few words

What's inside an interaction?

The main thread: a one lane road

Partytown: move the party somewhere else

How does it work?

Option 1: Service Worker (the fallback)

Option 2: Atomics (the fast one)

The two rules to remember

Angular

Step 1: install

Step 2: serve the Partytown files

Step 3: index.html

Step 4: an analytics service

Step 5: track a click

React

Step 1: install and copy the files

Option A: client-side app (Vite)

Option B: server-rendered app (the <Partytown /> component)

Scripts added later

Track page views and clicks

Check that it works

Where INP really wins

Trade-offs: no magic here

Measure, don't guess

Partytown won't fix your own code

Conclusion

The Grand Unifying Architecture of Frontend

Core Responsibilities

1. Navigation (client)

2. Content (server)

3. Affordances (client)

Following the Shape

Revisiting the Spectrum

A Modern Take

Navigation: Delegation and progressive enhancement

Content: Reactive reads over the wire

Affordances: An async-aware graph that hydrates once

Traversing the Spectrum

Conclusion

SpellBook of Skill: The Twin Project Nobody Asked For, But I Built Anyway 🧙🏻‍♂️

Overview

What It Actually Is 🤔

Built Entirely with OpenCode + OpenRouter + DeepSeek V4 Pro 🛠️

Step 3: `index.html`

Option B: server-rendered app (the `<Partytown />` component)

`Math.random`

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...