DEV Community: Playful Programming

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 🥹

OpenCode: The Open Source Coding Agent That Doesn't Lock You In 🔓

Domenico Tenace — Wed, 05 Aug 2026 08:00:00 +0000

Overview

Hey everyone 👋

If you've ever hit your Claude Code token limits mid-task, wondered what's happening under the hood of a closed-source agent, or just wanted to plug in a different model without switching tools entirely, OpenCode might be exactly what you were looking for.

It's the open source alternative that took the terminal agent concept and made it model-agnostic, and by mid-2026 it had already surpassed Claude Code on GitHub stars. That's not a coincidence.

Let me break it down. Let's dive in! 🤙

What Is OpenCode? 🤔

OpenCode is an open source AI coding agent built in Go that runs in the terminal, desktop, and IDE. Its thesis is simple: you bring the model, OpenCode brings the agent. It supports 75+ LLM providers, from Claude and GPT to local models via Ollama, doesn't store your code, doesn't charge a subscription, and over 7.5 million developers use it monthly.

It was built by the SST team, the same people behind the popular serverless framework. The design is a client/server architecture, not a single CLI binary, so one backend drives a terminal TUI, a desktop app, and IDE extensions for VS Code and Cursor.

OpenCode surpassed Claude Code on GitHub stars (160K+ vs 122K+) and is now the most starred open source coding agent. It does what Claude Code does, but lets you plug in any model from 75+ providers, including local models at zero API cost.

How It Works 🔧

Installing OpenCode takes about 30 seconds:

curl -fsSL https://opencode.ai/install | bash

You land in a polished TUI with two modes, Build and Plan. Build mode executes tasks directly. Plan mode is read-only, it lets the agent analyze your codebase and propose an approach before touching a single file. This is the separation of intent and execution that Claude Code doesn't make as explicit.

The design choice that matters most is the one in the name. OpenCode separates the agent harness from the model. Claude Code is tuned end to end around Anthropic's models and talks to them and only them. OpenCode connects to 75+ providers through Models.dev, including Anthropic, OpenAI, Google, Moonshot, Z.ai, local runtimes through Ollama, and any OpenAI-compatible endpoint you hand it.

You can switch models mid-session without restarting. That alone is a feature Claude Code doesn't have.

The Pricing Reality 💰

This is where OpenCode makes its strongest argument. There's no subscription for the software itself, you pay for model access directly.

The options as of mid-2026:

Bring your own key: pay the provider directly at their posted rates. Full flexibility, full cost visibility.

OpenCode Zen: a pay-as-you-go hosted gateway with access to many models.

OpenCode Go: $5 for the first month, then $10/month. Includes access to capable open models like GLM, Kimi K2, Qwen, DeepSeek, and MiniMax with generous per-session request limits.

Compare that to Claude Code's $20/month Pro, $100/month Max 5x, or $200/month Max 20x plans. For individual developers or small teams watching their AI spend, the math is clear.

The caveat: cost visibility helps when you are counting. Once you settle onto a flat Max plan, the math changes. If you're a power user who hits their limits constantly, Claude Code's flat rate might actually be cheaper per task.

The Anthropic Block: What Happened and Where It Stands 🚧

This is the part of the story that redefined what OpenCode actually is.

On January 9, 2026, Anthropic changed its OAuth policy to block third-party applications from authenticating users through Claude.ai accounts. OpenCode was the primary casualty: users who relied on their Claude Pro login lost access overnight. The official reason was "security and ToS compliance."

The January block made that choice less about saving money and more about philosophy. You are no longer choosing a cheaper way to run Claude. You are choosing whether you want a managed product or an open one.

Where it stands today: you can still use Claude models in OpenCode, but only through an Anthropic API key, not your Claude.ai subscription credentials. The more lasting impact was reputational: it accelerated many users migrating to Gemini as their default backend.

OpenCode vs Claude Code: The Real Differences 🥊

Terminal experience

OpenCode tends to win here, and it wins on feel. The TUI is the repeated favorite in nearly every comparison thread. The terminal does not flicker on each update, sections scroll independently, and planning prompts are easy to answer. OpenCode also ships a standalone Tauri desktop app for macOS, Windows, and Linux, something Claude Code doesn't have.

Autonomy features

Claude Code has a wider toolset: Agent View for fleet management, /goal for fire-and-forget autonomous runs, instant rewind via double-Esc, and background monitoring. OpenCode has background subagents and sessions that survive a terminal close, but lacks the orchestration depth.

Output quality

A controlled benchmark found Claude Code faster and OpenCode more thorough using the same model. The summary: "Claude Code is built for speed. OpenCode is built for thoroughness."

One practical issue to know about: multiple testers reported that OpenCode, across all tested models, reformats existing code without authorization. On mature codebases with established style guides, this is a trust issue. There's an open GitHub issue tracking this, and it's the most common complaint in real-world use.

The Pros 👍

True model freedom. No other terminal agent lets you swap between Claude, Gemini, DeepSeek, Qwen, or a local Ollama model mid-session. This is OpenCode's defining advantage.

Open source and inspectable. You can read the codebase, fork it, self-host it, and know exactly what the agent is doing with your code. Claude Code is closed source.

Better terminal UX. The TUI is genuinely nicer. Non-flickering updates, scrollable sections, a dedicated desktop app.

Cost control. Bring your own key, use local models at zero cost, or pay $10/month for the Go tier. The ceiling is much lower than Claude Code's $200/month Max plan.

Data compliance. Teams with strict data requirements can point OpenCode at a local or self-hosted model so code never leaves their network.

The Cons 👎

The code reformatting issue. OpenCode has a known tendency to reformat existing code without being asked. On mature codebases this creates noisy diffs and erodes trust in the agent's edits. Not a dealbreaker, but worth knowing.

Thinner plugin ecosystem. Claude Code has a more mature skills, hooks, and plugin marketplace. OpenCode's extension catalog is catching up, but it's not there yet.

No subscription path for Claude. If you're paying for Claude Pro or Max, you can't use that credit in OpenCode. You need a separate API key, which means paying again.

Fewer autonomous orchestration features. /goal mode, Agent View, instant rewind, and worktree isolation are Claude Code exclusives. For complex multi-agent workflows, Claude Code is still ahead.

Broad permissions by default. Several developers flag that OpenCode's agent permissions are broad by default. Check opencode.json before you point it at anything sensitive.

Who Should Use OpenCode? 🎯

OpenCode is the right choice if:

You want model flexibility and don't want to be locked into Anthropic's roadmap
Budget control matters and you want to use cheaper or local models
You prefer an open source tool you can inspect, fork, and trust
Your team has compliance requirements that require on-premise model inference
You find Claude Code's terminal UX annoying and want something nicer

Stay with Claude Code if:

You need the strongest possible instruction-following on hard tasks
You use Agent View, /goal, or other orchestration features heavily
You want a managed product that "just works" without configuration
You're already paying for Max and want to get full value from it

And honestly, plenty of people run both. OpenCode for day-to-day work with flexible models, Claude Code for the heavy debugging sessions where Opus is worth it.

My Honest Take 💭

OpenCode is a serious tool, not a hobby alternative. 178,000 GitHub stars and 7.5 million monthly users don't lie. The model-agnostic design is genuinely useful, and the terminal UX is objectively better than Claude Code's.

But the January block revealed something important: the moment you depend on Claude's quality and want to pay less, you're in Anthropic's crosshairs. OpenCode solved the tooling problem, not the model dependency problem. If you're using it with Claude via API key, you're still paying Anthropic rates.

The real freedom comes when you combine OpenCode's harness with open or local models. That's the combination that makes the cost argument actually land, and that's where the project's future clearly points.

Managed product or open tool? The answer depends on who you want to be as a developer.

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 Linktree to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Introducing Argus: The Code Security Colleague Your Team Doesn't Have

Davide Imola — Thu, 30 Jul 2026 08:56:00 +0000

Most development teams don't have a security engineer. Not because they don't want one. Security expertise is genuinely hard to find, expensive to keep, and most of us would rather ship features than spend an afternoon reading about deserialization gadget chains. So security becomes the thing you'll get to later, and later never comes.

I've believed for a while that AI is going to change security, and not as a slogan. The reason is structural: there aren't enough people. The industry is short something like 4.8 million security professionals worldwide,¹ which is the gap from that first paragraph counted globally, and no hiring spree closes a hole that size. AI won't close it either, and I want to be honest about that. What it can do is make the gap hurt less: take the routine load off the few people who are there, and keep a small team, or a team of one, from being buried. Same as it did for my coding, where it didn't make me smarter, it just stopped the grunt work from being the bottleneck.

A good model has read more security than most of us ever will: the best practices, the attack patterns, the bugs that hide in plain sight. Point it at code written by someone who isn't a security expert, which is most of us, and it genuinely lifts what they can ship safely. This isn't a spectator take for me either, it's what I spend my days on, building products that live right at that intersection. And the other side already gets it: attackers are using AI right now, so insisting defenders shouldn't is not caution, it's a handicap.

Concretely, I already use AI for security review, enough that I'm building a talk around how to do it well: lean on the skills that already exist, write your own, and point them at the real tools you already have. Give a capable model the right context and it quietly does a lot of the work a tired reviewer skips under a deadline. What it doesn't do is stick around. Every session starts from zero, knows nothing about your last review, forgets what you told it yesterday.

Then I started using OpenClaw, and it reframed the problem for me. OpenClaw is an always-running agent with a SOUL, a memory, and enough context about you that talking to it feels less like prompting a chatbot and more like messaging a colleague. It remembers. It knows your setup. I used it for useful things and for completely useless ones, and I had a lot of fun. We've mostly stopped since, if I'm honest, but it worked, and somewhere in there the idea landed: what if that colleague did security?

That's Argus: an open-source application security agent, written in Go, that I've been building with a few colleagues at RedCarbon. It's the project that quietly took the place of Worky, the tool I built and then never used, except this one has a mission I actually care about, so I'm not going anywhere.

Fair warning before you get excited: Argus is v0.2.0, and it's as much an idea as a tool. It's the thing I kept wishing existed, so I built a first version with people who actually do security for a living. I'm not sure I've got the shape right, but the shape is the part worth arguing about, and I'd rather do that in the open than sit on it.

Why security review needs a different shape

I want to be clear here, because this is easy to misread. I'm not saying AI security review is a bad idea. It's a great idea. What I don't believe in is doing it with AI alone. Models hallucinate, and a confident, wrong answer about a vulnerability is worse than no answer at all. Lean the whole thing on a model and you get a tool that sounds authoritative while quietly missing the one finding that mattered.

So the bet behind Argus isn't "point a model at your code". It's the union of three things that each cover for the others' blind spots: deterministic security tools that have been proven for years, a human kept firmly in the loop, and a model to tie it together and reason across the whole picture. Take any one of the three away and it falls over. Especially the human.

Recognizing a security problem is not something you wing. Get a code suggestion wrong and it's annoying; get a security call wrong and it's a breach. So an agent you'd actually trust with this has to earn that trust in ways a coding assistant never has to. Its answers need to trace back to something real instead of a confident guess. Its memory, from the moment it has one, becomes a thing attackers will try to lie to, so who gets to shape it suddenly matters. And it has to understand your world in particular, not security in the abstract, because a good share of the problems that actually bite only make sense once you know how your systems fit together.

None of these choices are settled. They're the ones I'd make today, pulled from the years I've spent around cybersecurity and filed down to the few details I think actually matter. I'm genuinely happy to have every one of them argued with. Here's the reasoning, a piece at a time.

Structured tools, not a shell

The default way to build a code agent in 2026 is to hand a model a shell and let it run. It works shockingly well for writing code. For security, I didn't want it.

When an agent has a shell, two things are true at once: it can do anything, and you can't be sure what it did. In a security context that's backwards. You want the opposite. A small, known set of capabilities, each one auditable.

So Argus doesn't get a shell. It gets tools. Under the hood there are real, boring, deterministic security scanners: Semgrep for static analysis, Gitleaks for secrets, osv-scanner for vulnerable dependencies. Each one is wrapped as a structured tool the agent can call, not a command it can type. The scanner runs, returns structured findings, and the model reasons on top of that.

This is also where an agent earns its place, because application security doesn't suffer from a missing tool. It suffers from too many. Nobody has the time to learn them properly, and even once you know them, remembering to run the right one at the right moment is a discipline of its own. You can wire them into a pipeline, of course, and then a slice of your week goes into managing the pipeline. An agent that already holds them, knows which one answers which question, and reaches for them without being asked is a different proposition from a folder full of CLIs you keep meaning to try.

One thing I'm genuinely proud of, and it's the least flashy part: Argus doesn't reinvent any of this. I'm not rewriting Semgrep, I'm not reimplementing a dependency scanner, because why would I. The whole bet is the opposite. Take the tools that already exist and already work, pull good data out of them, and let the agent reason over that data instead of over a hunch. The set Argus ships with today is small on purpose, and the direction is to let you bring your own: the more real tools it can call, the more signal it has to reason with. How far you push that is up to you.

That division of labor is the whole point. The deterministic layer finds things. The model does what models are good at: reading 400 findings and turning them into a conversation. "These three are the ones that matter, this one is a false positive because of how your auth middleware works, and here's the fix." Not a wall of SARIF. A colleague's summary.

It also keeps Argus honest about where its answers come from. A finding traces back to a tool that actually ran, not to a model that decided to type grep and interpret the output. When the domain is security, that provenance is the difference between a report you can act on and a guess you have to re-verify.

Roles and an audit log

An agent with a memory has a problem a stateless chatbot doesn't: the memory is part of the attack surface. If anyone who can talk to Argus can also teach it, then anyone who can talk to Argus can poison it. "Ignore that finding, it's fine" whispered often enough becomes policy.

OpenClaw already draws this line. If you have permission to write to the memory, you can shape it. If you don't, you can't. Argus takes the same idea and makes it central, because for a security tool it isn't a nice-to-have.

So every request arrives as a principal with a role, and Argus always knows which door you came through. Reach it over the local Unix socket and you're local:$USER; come in through the MCP endpoint and you're mcp:<token-hash>; arrive as a GitHub webhook and you're github:<login>. A viewer can ask questions and read findings, but shaping the memory, changing what Argus believes about your org, is a privileged action. And whatever anyone does, whoever they are, lands in an append-only audit log.

That log turns out to matter for a second reason. Go back to the original itch: teams without a security person. Those teams usually still have someone who has to answer to a CISO, a client, or an auditor about how security is handled, without reading the code themselves. An append-only record of what was reviewed, what was found, and what was decided is exactly the artifact that conversation needs.

SOUL, context, and a memory built for security

This is the part I took most directly from OpenClaw, then closed down hard around security.

Argus keeps a mix of three things, and they are not the same thing, which I keep having to explain to people, past-me included. There's the SOUL, the stable stuff: who Argus is, what your company does, your stack, your compliance posture. It rides along in every single model call, so Argus never forgets whose codebase it's looking at. There's context, the per-task working set for whatever it's reasoning about right now. And there's memory, the curated knowledge that persists from one conversation to the next.

The memory is where the security focus shows. Argus remembers findings. It remembers the things you tell it. And, my favorite part, it remembers your false positives, so the thing you already triaged and dismissed doesn't come back to eat your afternoon next week. That is the single most colleague-like behavior in the whole system. A good reviewer remembers what you already decided.

Say config.py in one of your repos only holds deploy-time placeholders that your secret manager swaps out at deploy. Tell Argus once, and it stops flagging them on that repo. The next review comes back clean, with a note explaining why, instead of the same false alarm you waved off last sprint.

The SOUL is what makes the reasoning fit your world instead of the abstract world of security-in-general. And the cross-session, cross-project knowledge is where I think this goes somewhere a single-repo tool can't follow. A coding agent pointed at one repository is blind to how that repository talks to the other twelve. Plenty of the security problems that actually hurt live in exactly that gap: the service that trusts input another service should have sanitized. Feed Argus enough of your world and it can start to reason across that boundary. It's early, but that's the direction.

OpenClaw is a general assistant, open-ended by design. Argus is the opposite. It knows it's a security tool, and everything (the tools, the skills, the memory, the persona) is shaped for that one job. Narrower, but deeper.

What Argus does today (v0.2)

Enough philosophy. Here is what actually runs.

One thing to set straight first, because the word "security" invites the wrong expectation. Argus doesn't watch your infrastructure, it doesn't sit in front of your traffic, and it is not a SOC. It reads code. That's the job it's built for, and the rest is somebody else's product.

Argus is a daemon, argusd, one shared instance per organization. Every way you talk to it (a terminal UI, the MCP endpoint, GitHub webhooks, and Slack soon) is a different door into the same process, sharing one memory, one tool registry, one audit log.

The most visible thing it does is review pull requests. Connect it as a GitHub App and it turns up on the thread like any other reviewer, except this one only cares about security. When it flags something you can push back right there, "Argus, is this finding real?", and it answers in context instead of making you go and dig. That back-and-forth isn't a nicety, it's the design: Argus is meant to be argued with, not obeyed.

Because it's also an MCP server, the AI tools you already use can consult it as a colleague rather than a black box. This is the part I reach for most: I point at something I just wrote and ask whether it's safe. And I want to be fair about the alternative, because the tools you already have are good at this. Claude and friends ship security skills, people write their own, and they work. What none of them has is your company: the other twelve repos, how your services talk to each other, which of your systems actually holds the data worth stealing. Ask Argus whether a pattern is a problem and it answers for your world instead of for security in the abstract, because the SOUL and the memory are right there. And it runs skills, which is how security methodology gets baked in. It ships with a handful: pr-quick-check for a fast pass over a diff, authz-audit for hunting authorization flaws, secret-rotation-plan for finding committed secrets and deciding what to rotate first, and threat-modeling for a STRIDE pass. You write your own the same way the built-ins are written, as a Markdown SKILL.md.

Getting started is ./argus init to pick a provider and write your SOUL, ./argus doctor to check the scanners are wired up, ./argus codehost setup to connect GitHub, and plain ./argus to just chat with it. There's a container image on ghcr.io with the scanners pre-bundled if you'd rather not install Semgrep and friends by hand.

A word on which model runs all this, because it's a design choice and not an afterthought. Argus is built to run on the AI you already have and already trust, rather than the one a vendor picks for you. The provider layer sits behind an interface, and argus init is where you choose. Today that choice is still narrow, with one provider implemented, and I won't dress that up as a feature. Support for any OpenAI-compatible endpoint is what I'm building right now, so depending on when you read this it may already be in. That's also the change that opens the door to local models, since most local runners speak the same API, and it matters for the teams I most want to reach: the ones who can't send their code to somebody else's API and don't have the budget to.

Where it's going

The idea list is longer than the changelog, which is the correct ratio for a v0.

The near stuff: Slack as a first-class channel, so Argus really is the colleague you message. Local models. More skills.

The stuff I'm actually excited about: service and code discovery, so Argus builds its own map of your systems instead of waiting to be told, and a view of how your projects connect, because that cross-project graph is where the non-obvious problems hide.

But I want to be careful, because I've made this mistake before. With Worky I built a showcase site and full docs for a tool with zero users, then watched it drift because there was no real usage telling me what to build next. A roadmap without users is fiction. So I'm not going to pretend I know exactly what Argus needs. The roadmap comes from whoever picks it up.

The difference from Worky, the reason I'm not worried this one ends up on the same shelf, is that I use Argus. It has a mission I care about. This is the tool I want to keep alive, and I get a vote in what it becomes precisely because I'm one of its users.

Come build in AI and security

There's a bigger thing behind Argus, and it's the reason I'm writing this instead of just pushing a repo.

AI and cybersecurity are converging fast, and most people are only watching one side of it. Back in June we ran a hackathon at RedCarbon: one day, tiny teams, AI pointed at security problems. I wrote about being on the jury in the Worky retrospective, but the part I keep coming back to is the range. One team went after phishing aimed at non-technical family members. Another built for the SOC. Another attacked the security of AI models themselves. Same prompt, completely different directions, all of them real.

Argus is just my direction, and it comes from something I actually live. I'm lucky here: I have security colleagues at RedCarbon who helped me shape it, pick the tools, and read what those tools are really saying. But they spend their days pointing our own AI agents at SOC problems, and none of them has time to sit behind our code's security posture every single day. So the developers have to, and Argus automates the exact work those colleagues would otherwise do by hand. And that job, it turns out, is increasingly buildable: models are getting good enough at security reasoning that the bottleneck is no longer the model, but whether someone shapes it into something trustworthy and useful.

A while back I wrote that AI will not secure your codebase, that it won't do the job for you but it can surface risk earlier, act as an early-warning system. Argus is me trying to make that concrete. Not a magic box that makes you secure, but a colleague who has read your whole codebase, remembers what you decided, and is awake at 2am when the PR lands.

It's on GitHub, Apache 2.0, v0.2 and honest about it. If you do security, or you just want the security colleague you don't currently have, clone it, break it, write a skill, and tell me how you use it. Real usage is the one thing that turns a fun experiment into a tool that matters, and I learned that the expensive way.

Worky has two stars and I made my peace with that. Argus I'd actually like you to star, because this is the one I'm keeping. And if you've been sitting on your own idea at the intersection of AI and security, stop sitting on it. The water's warm.

The 4.8 million figure is ISC2's estimate of the global cybersecurity workforce gap: the distance between the security professionals organizations say they need and the ones actually available to hire. Source: ISC2 2024 Cybersecurity Workforce Study. ↩

Gemini 3.6 Flash: Google's Fastest Bet in a Crowded Race 🚀

Domenico Tenace — Wed, 29 Jul 2026 08:33:15 +0000

Overview

Hey everyone 👋

Google dropped Gemini 3.6 Flash on July 21, 2026, and it's worth talking about. Not because it's a revolution, but because it quietly improves on almost everything from 3.5 Flash while getting cheaper and faster at the same time. That's a combination you don't see often.

Let me break down what actually changed, how it stacks up against the competition, and whether you should care.

Let's dive in! 🤙

What Is Gemini 3.6 Flash? 🤔

Gemini 3.6 Flash is Google's workhorse model for developers, the go-to for agentic workflows, coding tasks, long-document reasoning, and multimodal work. It's not Google's most capable model (that's still the upcoming 3.5 Pro and eventually Gemini 4), but it's the one most developers will actually use day to day.

It was released alongside two companion models: Gemini 3.5 Flash-Lite, designed for high-throughput and low-latency tasks like agentic search and document processing, and the limited-pilot Gemini 3.5 Flash Cyber for governments and trusted partners.

The model is available in Google AI Studio, the Gemini API (model ID gemini-3.6-flash), the Gemini app, Antigravity, Android Studio, and Vertex AI.

The Numbers: What Actually Changed 📊

Benchmarks

Gemini 3.6 Flash improves on Gemini 3.5 Flash across the board: coding went from 55.1% to 58.7% on SWE-Bench Pro, long-context retrieval went from roughly 27% to 54.0%, and computer use went from 78.4% to 83% on OSWorld Verified.

Average task time fell from 2.7 minutes to 1.3 minutes, while estimated task cost declined about 18 percent. That's not a minor tweak. That's a meaningfully faster agent in practice.

Speed

It runs at about 280 tokens per second, which makes it one of the faster models in its class for interactive use. For agentic workflows where you're chaining multiple LLM calls, this compounds fast.

Pricing

Gemini 3.6 Flash costs $1.50 per million input tokens and $7.50 per million output tokens. Input pricing is unchanged from Gemini 3.5 Flash, but output dropped from $9.00 to $7.50 per million tokens.

Context Window and Knowledge Cutoff

The model runs a 1 million-token context window with a 64,000-token output cap, and its knowledge cutoff is March 2026, up from January 2025 on Gemini 3.5 Flash. That's a 14-month jump, which matters more than it sounds. A model that knows about recent framework releases, pricing changes, and API updates needs less web retrieval to stay useful.

Token Efficiency

The model takes fewer reasoning steps and tool calls to complete multi-step workflows, which is a large part of why it uses roughly 17 percent fewer output tokens than its predecessor. You're paying for less and getting more done. That's the ideal direction.

How It Compares to the Competition 🥊

vs. Claude Sonnet 5

Claude Sonnet 5 outperforms on 3 benchmarks including SWE-Bench Pro and GDPval-AA, while Gemini 3.6 Flash wins on OSWorld-Verified and CharXiv-R. Claude Sonnet 5 has a slight edge in raw benchmark performance.

But the cost story is different. Gemini 3.6 Flash is 25% cheaper on both input and output compared to Claude Sonnet 5. At 100,000 tasks per month with 5,000 input and 10,000 output tokens each, that's $2,750/month in savings. For cost-sensitive workloads, Gemini is the clear winner.

Gemini 3.6 Flash also runs at 304 tokens per second compared to roughly 180 for Claude Sonnet 5. For agent workflows where latency matters, the speed difference is noticeable.

My take: if code quality at any cost is the priority, Claude Sonnet 5 still wins on most coding benchmarks. If you're building high-volume agent pipelines or cost is a real constraint, Gemini 3.6 Flash makes a strong argument.

vs. GPT-5.6 Luna

GPT-5.6 Luna remains cheaper than Gemini 3.6 Flash at public API rates, but Artificial Analysis measured Gemini at 304 output tokens per second compared to 190 for Luna. This creates a practical trade-off: Luna offers lower token rates, while Gemini produces output faster.

Independent testers report Gemini 3.6 Flash loses most coding benchmarks and GDPVal to Grok 4.5 and GPT-5.6 Luna. So if pure coding benchmark numbers are what you're optimizing for, Google isn't at the top of that list right now.

vs. Gemini 3.5 Flash

Both Gemini 3.6 Flash and Gemini 3.5 Flash currently score 50 on the Artificial Analysis Intelligence Index. Existing Gemini 3.5 Flash users have the clearest migration case, especially when latency and output volume drive costs.

In other words: same intelligence, faster, cheaper, fresher knowledge cutoff. The upgrade is a no-brainer if you're already on 3.5 Flash.

What's Missing: The Elephant in the Room 🐘

The most notable absence in this announcement is Gemini 3.5 Pro. Google originally said at I/O in May that 3.5 Pro would launch the following month. That deadline passed without a public release. Bloomberg reported on July 16 that the model was running months behind schedule, with Google spending extra time on its coding capabilities.

Google did not release Gemini 3.5 Pro in this announcement. The company said the Pro model fell short of internal expectations on coding and complex reasoning, so its broader release was delayed.

This is the real story. A delayed Pro model means that right now, Google's top available offering in the Flash tier competes on price and speed but not on raw reasoning against Claude Opus or GPT-5.6. Google also confirmed that pre-training has begun on Gemini 4, which the team described as its most ambitious pre-training run yet. So the roadmap is clearly ambitious, but the present gap is real.

The Pros 👍

Cost efficiency is excellent. Roughly half the output price of Claude Sonnet 5 at production scale is meaningful money. For startups or anyone watching API bills closely, this matters.

Speed is genuinely impressive. At 304 tokens per second, it's 1.7x faster than Claude Sonnet 5 for agent workflows where latency matters.

Multimodal support is broad. Gemini 3.6 Flash supports voice, video processing, images, PDFs, and audio as input. Claude Sonnet 5 doesn't support voice or video. For multimodal applications, Gemini is the stronger choice.

The knowledge cutoff jump is significant. Going from January 2025 to March 2026 in one model generation means you're working with a model that actually knows about tools and frameworks released in the past year and a half.

Token efficiency means lower costs in practice. Fewer output tokens for the same quality work, combined with a lower output price, compounds into real savings at volume.

The Cons 👎

The Pro model is still missing. For developers who need the strongest possible reasoning and coding quality today, Google's delays leave a gap that Claude Opus and GPT-5.6 are filling.

Raw coding benchmark scores lag behind top competitors. On the benchmarks that matter most to developers, Grok 4.5, GPT-5.6 Luna, and Claude Opus 4.8 still outperform Gemini 3.6 Flash. Speed and cost don't compensate for quality when you're debugging something complex.

Intelligence Index hasn't moved. Gemini 3.6 Flash and Gemini 3.5 Flash both score 50 on the Artificial Analysis Intelligence Index. Faster and cheaper is great, but it's not smarter. If you were hoping for a reasoning leap, this isn't it.

Gemini 4 uncertainty. Google teasing their next major model while 3.5 Pro is still delayed creates uncertainty for teams planning their model strategy. Do you build on 3.6 Flash now, or wait?

Who Should Use Gemini 3.6 Flash? 🎯

Existing Gemini 3.5 Flash users. The migration is a pure upgrade: same intelligence, faster, cheaper, better knowledge cutoff. No reason not to switch.

Cost-sensitive teams building agents. If you're running thousands or millions of API calls, the pricing advantage compounds fast. At scale, Gemini 3.6 Flash is the most efficient option in its class.

Multimodal applications. Voice, video, images, audio all in one model with a 1M token context window. If your use case touches multiple modalities, this is the most capable option at this price point.

Developers already in the Google ecosystem. Antigravity, AI Studio, Vertex AI, Android Studio. If you're already in these tools, the integration is seamless.

Who should look elsewhere: if you need the strongest possible code generation today and budget is secondary, Claude Opus 4.8 or GPT-5.6 Luna are stronger choices on raw coding benchmarks.

My Take 💭

Gemini 3.6 Flash is a solid, honest upgrade. Google didn't promise a revolution and didn't deliver one. What they delivered is a faster, cheaper, more efficient model with a dramatically improved knowledge cutoff. For most agentic workloads, that's exactly what you need.

The absence of 3.5 Pro is frustrating, and the coding benchmark gap against the top tier is real. But if you're building cost-sensitive pipelines, working with multimodal content, or already deep in Google's ecosystem, 3.6 Flash makes a compelling case.

The question isn't "is this the best model?" It's "is this the best model for what I'm building?" For a lot of teams, the answer is yes.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Automating my Codemotion Badge with Antigravity

Luca Del Puppo — Wed, 08 Jul 2026 05:50:52 +0000

Today, I wanna show you how to set up your devices with Antigravity using only the agentic mode, without touching any code.

At the last CodeMotion Rome, I got my special badge. A CM Node, a special hardware board, that you can customise for your conferences.

I'm not a super nerd for this kind of stuff, so I decided to use Antigravity and all its capabilities to build and flash the best board ever for my future conferences.

Small intro about the board

This board has been delivered with a GitHub repository to understand how to flash it and how it works. In Rome, I saw different attendees with awesome badges. For instance, Soumaya had built a badge with a small plastic hand that used a sensor when someone was near her; it started waving to say hi.

Since that day, I have been thinking about what I can build to have a cool badge. Nothing has come to my mind, so today, with this blog, we will build my badge together, and thanks to Antigravity, we will create the best version possible.

Antigravity

If you don't know Antigravity. Antigravity is a set of tools built by Google. We have:

Antigravity 2.0: is a dedicated platform to work with agents. Orchestrate multiple autonomous agents working in parallel across independent projects.
Antigravity CLI: terminal-first surface to interact with Antigravity agents. Stay in your flow without context switching
Antigravity IDE: editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent
Antigravity SDK: build AI agents that autonomously read files, run commands, edit code, and more. The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.

Today, in this blog post, we will use Antigravity 2.0 to set up the board. You can use this tool to orchestrate many projects from a unique UI. This tool is fully agentic; using natural language, you can spawn agents, plan, and work on your projects. If you want to check the codebase in detail, you must use the Antigravity IDE. I’m not a fan of this decision, I’d prefer one tool for both, but this is what we have, and we must use it as it is.

Let’s start cooking

Okay, after this introduction, let’s see what we can do with Antigravity and the CodeMotion Board.

So, I’m dumb about this board right now, and I want to use Antigravity to figure out what I can do with it and get an idea of what my badge might look like.

I open the Antigravity app, and from the UI, I start a new project, and in the prompt, I type

I want to set up my Codemotion Badge.

It's a CMNode v0 https://www.cmnode.it/en/, and it can be programmed.

I want to create two different screens: the first a classic one with name, surname, heading, and company, and a QR code linking to my website.

The second one must be fantastic, and I want different options to choose from you.

I have this repository as an example to set up the badge https://github.com/Codemotion-Official/CMNode; you can use it as an example to create my badge.

Lastly, I don't want to flash the ROM every time, so I'd like a small web page I can access via Wi-Fi to update the information.

Can you plan the work to do it?

Include also two or three possible ideas for the second screen. It must be cool and fancy!

The badge is already connected to the laptop in case you want to deploy the result.

Now, I press enter and let’s see the result and what it will cook.

The result

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

User Review Required

IMPORTANT

Please review the proposed ideas for the "Fantastic" screen below. Let me know which one you prefer, or if you'd like to combine elements from different ideas!

Ideas for the "Fantastic" Second Screen:

The "Hacker Terminal" : A retro command-line interface aesthetic. The screen features a black background with white text, simulating a terminal session (e.g., > user@cmnode:~$ whoami, followed by your details). We can use monospace fonts and add some faux hex-dumps or ASCII elements.

The "RPG Stats / Gamer Card" : Your badge becomes a character stat sheet. It will display you as a "Level 99 Developer" with stats like "INT: 99", "COFFEE: 100%", an energy bar, and your details integrated into a game-like UI.

The "Minimalist Cyberpunk" : A bold, modern, and high-contrast design. It uses large vertical typography for your name, heavy geometric shapes, thick red accent lines, and a large barcode aesthetic alongside your QR code.

Let me know which of these three ideas (or a mix!) you want me to build for the second screen.

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

I commented on the plan, deciding to go with option one and asked for an example design.

Antigravity has started reviewing the plan and updated it in this way

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

Design Choice: "Hacker Terminal"

You've selected the Hacker Terminal idea for the second screen. This layout will simulate a retro command-line interface on the E-ink display:

Background : Black (inverted).

Text : Monospace white font, simulating terminal output (root@cmnode:~$ whoami).

Data : Your name, surname, role, and company will be displayed as the "output" of the terminal command.

Accents : Faux hex-dumps or system logs on the side, and a right-aligned QR code.

Here is a mockup of the design:

Does this mockup and the updated plan look good to you? If so, I will proceed with the implementation!

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

As you can see, we now have a clear idea of how the second screen should look and a plan to implement everything, but before spawning the agent work, I'd also like to have a design of the first screen of the badge, so using the chat, I ask to include it also in the plan.

After two iterations of the prompt, this is the result

The implementation

To implement the plan, we just need to press the Proceed button and wait

During the implementation, we can check what is happening through the UI

And if we notice something weird, we can stop the agent and type a new prompt to drive it again on the right path.

If you, like me, prefer to get confirmation before running commands or editing files, you must also approve these actions through the UI.

After 2 minutes, this is the result.

And if I connect my laptop to the badge Wi-Fi, I can configure my badge.

The refine

Now we have a badge working, but we want to improve it a bit: first, I want to change the screen by pressing the button on the back without connecting to the badge's Wi-Fi, and I want to set the Wi-Fi password via Environment Variables.

So I can prompt this

Can we also change the screen view using the button on the rear of the badge without connecting to the badge's Wi-Fi?

And after a minute, the result is ready, and my badge has been flashed.

And lastly, I can ask not to hard-code the password but use an environment variable,

use an environment variable for the wifi password

same here, after one minute and a couple of approvals, the result is again ready and in my badge.

To complete, I want to change the layout by using one of the buttons on the back of the badge. So again I ask Antigravity to do it for me.

Can we change the screen view also by using the button in the rear of the badge without connecting to the badge wifi?

and same here, after some minutes, sometimes the result is happier in the badge.

And the final result is this one

and this one

Conclusion

It's time to wrap up!

So my experience with Antigravity has been great! I love to use it to build new things, or as a teammate to learn new technology, or just to prototype a pet project like this one.

If you are in the agentic development, this tool can be a good one for you!

The experience is great, and if you want to have control over different projects or streams, it can be really helpful. The only pain point for me is the fact that if you want to check the code, you must install another tool, the Antigravity IDE, to check it.

In this era of agent development, what I find great is the ability to plan and review the changes before the agent implements them! This is the game-changer for me in this moment, and then a lot and a lot of code review!

Okay, that's it! I hope you enjoy this introduction to Antigravity and that you now want to test it for your project.

I hope you also like my new super badge 🚀

p.s. to check the code result, you can navigate to this repository

Google Cloud credits are provided for this project.

Daily Prompt Is Out. Long Live Spellbook of Prompt 🧙🏻‍♂️

Domenico Tenace — Mon, 06 Jul 2026 07:00:00 +0000

Overview

Hey everyone 👋

Some projects start as a quick idea and slowly grow into something you actually want to take seriously. That's exactly what happened with Daily Prompt, a small collection of prompts I put together for personal use that at some point became messy, inconsistent, and honestly a bit embarrassing to share.

So I restarted from scratch. New name, new structure, new look. Meet Spellbook of Prompt.

Let's dive in! 🤙

What Was Daily Prompt? 🤔

Daily Prompt was exactly what the name suggests: a daily collection of prompts. The idea was fine, a place to gather useful prompt templates to use with ChatGPT, Claude, Gemini, and whatever else was around. But the execution had problems.

The prompts were scattered with no real organization. There was no clear logic behind the categories. The visual side was the default Starlight theme with zero customization. It felt like a dumping ground more than an actual project.

And the name itself was limiting. "Daily" implied a frequency I couldn't keep up with. It set the wrong expectations.

At some point I looked at it and thought: this doesn't represent what I actually want it to be.

Why Rebrand? 💡

Renaming a project isn't something I do lightly. It breaks URLs, confuses people who already know it, and requires updating everything.

But sometimes a fresh start is the right call.

The rebrand to Spellbook of Prompt came from a simple realization: a spellbook is a perfect metaphor for what this is. It's a collection of incantations, each one carefully crafted, tested, and documented. You open it, find what you need, cast the spell (run the prompt), and get a result.

It fits. And more importantly, it gives the project an identity worth building around.

What Changed: The Structure 🏗️

The biggest improvement is the organization. Daily Prompt was a flat list of prompts with loose labels. Spellbook of Prompt organizes everything by use case, so you can actually find what you need without scrolling forever.

The categories cover the most common real-world scenarios:

Content Creation: scripts, posts, articles, newsletters
Code Generation and Debugging: boilerplate, reviews, refactoring
Data Analysis and Reporting: summaries, structured output, comparisons
Writing and Copywriting: tone adjustments, persuasive copy, editing
Design and Creative Direction: briefs, feedback loops, mood boards
Learning and Education: explanations, quizzes, study guides

Each prompt comes with a clear description, at least one input and output example, and notes on edge cases. The goal was to make every entry actually usable, not just a template you have to figure out yourself.

The documentation is built with Astro and Starlight, which makes browsing fast and the content easy to read. MDX gives us enough flexibility to add interactive examples down the line without switching tools.

What Changed: The Look 🎨

This is where I spent more time than I expected.

The old project was visually generic. Default colors, default fonts, nothing that connected it to anything else I build. It could have belonged to anyone.

For Spellbook of Prompt I brought in my brand colors and made it feel like part of the same ecosystem as my personal site and other projects under Domenico Tenace Open Labs. It's a small thing, but it matters. When you open the docs, you immediately get a sense that someone cared about this, not just about the content but about how it looks.

Consistency across projects builds trust. And building trust was part of the point.

Model-Agnostic by Design 🌍

One thing I wanted to be clear about from the start: Spellbook of Prompt is not tied to any specific AI model.

Most prompts here work across ChatGPT, Claude, Gemini, and any other LLM you're using. Where there are differences in behavior across models, the documentation mentions it. The collection is validated across at least two different models before anything gets merged.

This matters because the AI landscape changes fast. Tying a prompt collection to a specific model would make half of it obsolete every few months.

It's Open Source and You Can Contribute 🤝

Spellbook of Prompt is fully open source under MIT, and contributions are very welcome.

If you have a prompt that works well and you've tested it properly, opening a PR is straightforward. The guidelines are in CONTRIBUTING.md and they're simple: keep prompts concise, include at least one example, validate across multiple models, and don't include sensitive data.

The bar isn't high. The point is quality over quantity. I'd rather have 50 excellent prompts than 500 mediocre ones.

What's Next 🚀

There's still a lot to add. The categories are in place but some of them are thin. The live documentation site is up and running at spellbook-of-prompt.netlify.app, and I'll keep adding prompts regularly.

A few things on the roadmap:

Interactive prompt examples directly in the docs
A tagging system for filtering by LLM compatibility
More prompts for developer workflows (CI/CD explanations, commit messages, PR descriptions)
Better search across the full collection

Final Thoughts 🌟

Sometimes a project needs to die to become something better. Daily Prompt served its purpose, but it had hit a ceiling. Spellbook of Prompt is what it should have been from the beginning, cleaner, more organized, and actually worth sharing.

If you work with AI tools regularly and you keep writing the same prompts from scratch every time, this might save you some time. Go browse the collection, grab what's useful, and if you have something good to add, open a PR.

The spellbook is open. 🔥

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Pasting Code into AI? Here’s Why Your Legal Team is Sweating

Hayk Sargsyan — Sun, 28 Jun 2026 19:13:25 +0000

The integration of Large Language Models (LLMs) like OpenAI’s GPT-5, Anthropic’s Claude, and Google’s Gemini has fundamentally shifted the engineering landscape. For developers, these tools offer unprecedented velocity. However, blind reliance on public AI models introduces severe legal, financial, and architectural liabilities.

Understanding these legal pitfalls is no longer optional-it is a core engineering competency.

The Core Legal Risks of AI in Development

Using AI tools without guardrails exposes your organization to three primary legal vectors: Intellectual Property (IP) leakage, copyright infringement, and breach of contract.

Intellectual Property (IP) Leakage

When you paste proprietary code, business logic, or internal database schemas into a public LLM, you may forfeit trade secret protections. Many standard consumer-grade AI terms of service grant the provider the right to use your inputs to train future models. This means your proprietary algorithms could theoretically be generated for a competitor.

Copyright Infringement & "Copyleft" Contamination

LLMs are trained on massive datasets, including open-source repositories with varying licenses (e.g., GPL, AGPL, MIT).

An LLM might output a block of code that verbatim matches a copyleft-licensed project (like GPL). If that code is integrated into a commercial product, your organization could legally be forced to open-source its entire codebase.

Breach of Client Contracts and NDAs

Most enterprise software contracts include strict Non-Disclosure Agreements (NDAs) and data-handling clauses. Pasting client code into third-party AI models without explicit authorization directly violates these agreements, risking litigation and immediate contract termination.

Photo by Google DeepMind on Pexels

Why "Blind Copy-Pasting" is a High-Risk Practice

Copying and pasting entire business snippets, complex modules, or sensitive data dumps into tools like Claude or ChatGPT creates distinct liabilities.

Pasting entire files often inadvertently includes proprietary APIs, security tokens, internal domain names, and unique business logic.
Free or standard consumer tiers of Anthropic, OpenAI, and Google retain history by default. Even if you delete the chat, the data may remain on third-party servers for compliance auditing or system optimization.
When an AI refactors an entire proprietary snippet, it mixes your IP with its statistical training weights. If the output mimics protected code, proving original ownership in a patent or copyright dispute becomes incredibly difficult.

Photo by George Becker on Pexels

Paths to Solve the AI Risk Problem

Organizations must move away from ad-hoc AI usage and implement structural, engineered guardrails.

Enterprise API Tiers and Zero-Data Retention (ZDR)

Consumer interfaces (like the free web chats) are unsafe for corporate IP. Businesses must mandate the use of Enterprise platforms or direct API integrations. Major providers guarantee via enterprise contracts that inputs and outputs are never used for model training and are deleted within a fixed window (typically 30 days).

Self-Hosted and Local LLMs

For highly sensitive core IP, companies should completely cut off third-party network dependencies. Data never leaves the corporate firewall, entirely eliminating third-party data leakage risks. Implement automated safety checks in the CI/CD pipeline. Use tools like GitHub Copilot’s built-in duplication filters or standalone scanners (e.g., Snyk, SonarQube) to catch AI-generated code that matches public repositories before it merges into production.

Developers must treat LLMs as untrusted, highly competent junior interns. You guide them, verify their work, and never hand them the keys to the vault.

Never paste real business logic. Replace proprietary class names, variable names, and internal APIs with generic equivalents (e.g., convert calculateCorporateTaxBracket() to processNumbers()).
Use AI to generate architectural patterns, algorithmic logic, or regex patterns rather than copy-pasting entire production files.
Treat AI-generated code with higher skepticism than human code. Review it for security vulnerabilities, licensing compliance, and optimization.
Always verify whether your organization utilizes enterprise-grade agreements with providers like Anthropic or OpenAI before utilizing their web interfaces.

Photo by Christina & Peter on Pexels

Conclusion

AI is not going anywhere, and trying to ban its use in development is a losing battle. The key to staying competitive as a developer isn't avoiding LLMs - it's mastering the guardrails around them. By treating AI as an untrusted third-party service, sanitizing your inputs, and pushing for enterprise-grade infrastructure, you can leverage the full velocity of generative AI without compromising your company's intellectual property.

Web MCP: give some tools to your agent

Nicolas Frizzarin — Thu, 11 Jun 2026 15:50:17 +0000

Introduction

Nowadays, AI agents are becoming increasingly powerful at assisting users in their daily web activities. However, we cannot yet allow them to act completely autonomously—there is still a risk of them clicking on the wrong elements, for instance.

In theory, these agents are capable of performing impressive tasks, provided they are guided step-by-step through the interface. The challenge here is not a lack of intelligence in the model, nor a shortage of web APIs to expose data to the agent. The core issue lies in the fact that the agent must currently "guess" its way through applications that were designed exclusively for humans.

This is precisely the problem that WebMCP is here to solve.

It is important to note that these are not intended to replace standard APIs as access points for an application. Instead, they provide a structured way for a web application to "instruct" the AI agent used in the browser on how to navigate its interface. This results in:

Fewer misplaced clicks.
Less trial-and-error when interacting with the UI.

When utilized to their full potential, WebMCPs could redefine the user experience in the coming years.

What is WEBMCP?

As you may have guessed, WebMCP is a browser-side "guide/standard" for exposing tools to an AI agent directly from an active web page.

During Google I/O, this new feature was introduced as a way for web applications to describe how a page functions—and what actions can be performed—to various AI agents. As a result, agents can execute these described actions faster, more efficiently, and with greater precision.

Unsurprisingly, the syntax for creating these descriptions relies on JavaScript functions. These functions take natural language descriptions as parameters, along with structured schemas directly exposed from the web page.

This is exactly where the power of WebMCP lies.

Today, while we have Playwright (designed for end-to-end testing of web applications) and Playwright MCP (which extends this model to LLMs), WebMCP sits right at the intersection. It allows a page to effectively communicate to the agent: "Here are the actions you can perform on this page, how it works, and how you can trigger them."

Difference between WebMCP | MCP | Automation

At first glance, it may seem like all these approaches are similar and perform the same functions. In reality, each serves a well defined purpose, and they are highly complementary. To better understand the distinctions between them, let’s look at things from an AI integration perspective.

Backend MCP

At its core, an MCP server acts as a specialized bridge between AI models and external systems. It functions by providing a direct connection to APIs, effectively removing the friction typically involved in integrating new tools. By establishing a structured framework for data access, it ensures that the information exposed to the agent is organized, predictable, and secure. This architecture makes it an ideal solution for executing data-driven actions, allowing AI agents to perform complex, precise tasks with the reliability required for production grade applications.

Browser Automation

Traditional automation concepts rely on mimicking user behavior to interact with the web. They reproduce human-like interactions, such as clicking buttons or scrolling through pages, and can access any element within the UI by targeting it directly in the DOM. A key characteristic of these methods is that they do not require a predefined data structure, as they operate by observing the visual state of the application. However, because they are so tightly coupled to the underlying HTML structure, the main flow can be quite brittle; even minor UI changes often cause the automation to break, requiring constant maintenance.

WebMCP

By design, it shares the current application context directly with the AI, moving beyond what is merely visible on the screen. It structures and describes UI actions, providing the agent with a clear map of what is possible rather than forcing it to guess. This results in a highly reliable, context-aware interaction model that significantly reduces errors. Furthermore, the architecture is designed with human-in-the-loop capabilities at its core, ensuring that users maintain oversight and can intervene whenever necessary for sensitive or complex workflows.

When to use what: rules to apply.

To ensure your AI agent performs at its best, it is important to select the right integration strategy based on your specific requirements:

When an agent requires direct, structured access to data without interacting with a live web page, an MCP server is the ideal solution.
When you need to interact with a web interface exactly like a human would—whether for automated testing, task execution, or full application usage—browser automation is the right choice.
When a user is already actively navigating your web application and requires an agent that can interact with the entire page with high precision, WebMCP is the optimal path forward.

Different layers, different jobs.

How to use WEBMCP

It is worth noting that, for now, WebMCP is only available in Chrome starting from version 149 (with a strong drive to integrate this feature into the Baseline movement).

To enable this functionality in Chrome today, you need to use a feature flag:

Navigate to chrome://flags in your browser.
Search for and enable the enable-webmcp-testing flag.
Relaunch your browser to apply the changes.

There are two primary ways to utilize the WebMCP APIs to configure the tools exposed by your page:

The Declarative API: This method enables you to create WebMCP tools simply by adding annotations to your standard HTML forms, making the integration process more streamlined and semantic.
The Imperative API: This approach allows you to define custom tools such as form submission, navigation, or other specialized actions directly using standard JavaScript functions.

Defining tools using the Imperative API

document.modelContext.registerTool({
  name: 'search_product',
  description: 'search product based on a user search input'
  inputSchema: {
    type: "object",
    properties: {
      search: { type: 'string' }
    }
    required: ['search']
  }
  outputSchema: { type: 'string', description: 'List of products corresponding to the search'} 
  execute: async ({ search }) => {
    if(!search) return [];
    const products = await (await(fetch(`${url}?search=${search}`)).json());

    return JSON.stringify(products);
  }
})

Defining Form tool with the Declarative API

As previously mentioned, the Declarative API allows you to create form-based tools using annotations. More specifically, it leverages standard HTML attributes on your forms to define and manage how the tool is created.

<form toolname="supportRequestTool"
  tooldescription="Submit a request for support."
  action="/submit">

  <label for="firstName">First Name</label>
  <input type=text name=firstName>

  <label for="lastName">Last Name</label>
  <input type=text name=lastName>

  <select name="select" required 
    toolparamdescription="Determines what team this request is routed to.">
    <option value="Customer happiness team">Return my purchase.</option>
    <option value="Distribution team">Check where my package is.</option>
    <option value="Website support team">Get help on the website.</option>
  </select>

  <button type=submit>Submit</button>
</form>

The declaration process relies on specific attributes to define your tools:

toolname: Used to assign a specific name to your tool, reflecting its purpose.
tooldescription: Used to provide a clear explanation of the action the tool performs.

In practice, when the agent invokes the supportRequestTool, the browser brings the corresponding form to the foreground and fills out the fields while keeping the form visible to the user. Note that if you remove either the toolname or tooldescription attribute, the tool will be automatically unregistered and become inaccessible to the agent.

toolparamdescription: This optional attribute allows you to map a specific element to a detailed description. If this attribute is omitted, the agent will default to using the field's label as the description.

Security

As a reminder, LLMs process all text—including instructions and user data—as a single sequence of tokens. Consequently, once your application implements the WebMCP feature, it becomes susceptible to indirect prompt injection, where malicious instructions can be hidden within the content.

To mitigate these risks, here are several security recommendations for implementing WebMCP:

untrustedContentHint: Use this attribute to signal to the agent that the data originates from an external source, prompting it to exercise greater vigilance.
readOnlyHint: Apply this attribute to tools that should not modify data states, ensuring they require explicit agent confirmation before execution.
Character budgets: Define strict character limits for your tool names and descriptions to prevent prompt-injection attempts via long, malicious strings.
exposedTo: Use this property to restrict access to your tools, limiting them to specific, trusted domains.

It is important to remember that by default, tools are only exposed to the AI agent and are not accessible to other websites or iframes.

Conclusion

WebMCP represents a fundamental shift in how AI agents interact with the web. We are moving beyond the era of "computer-use stunts" where agents must guess intent from messy interfaces toward a model of direct, structured cooperation between sites and assistants.

By exposing structured actions and context, WebMCP allows the browser to share what it already knows: the current page, the user's session, and the precise moment help is needed. While backend integrations remain the best fit for bulk data processing, WebMCP is the optimal path for sites that want to provide a reliable, context-aware experience during live navigation.

We have only scratched the surface. In our next article, we will move from theory to practice by diving deep into implementation join us as we explore how to seamlessly integrate WebMCP into Angular applications.

Google AI Studio: The Playground Every Developer Should Know About 🎮

Domenico Tenace — Fri, 05 Jun 2026 07:00:00 +0000

Overview

Hey everyone 👋

If you've ever wanted to experiment with Gemini models, build AI-powered features, or grab an API key without going through a complex setup, Google AI Studio is the tool you're looking for.

It's free, it's browser-based, and it's probably the fastest way to go from "I have an idea" to "I have working code." Today I'll walk you through what it is, what you can actually do with it, and why it belongs in every developer's toolkit.

Let's dive in! 🤙

What Is Google AI Studio? 🤔

Google AI Studio is a web-based platform where you can interact with Google's AI models, prototype ideas, fine-tune behavior, and export working code, all without writing a single line of infrastructure.

Think of it as a sandbox. You can test prompts, switch between Gemini models, tweak parameters, and when something works, click "Get Code" to get a ready-to-use snippet in Python, JavaScript, or REST. No cloud setup, no billing configuration, no long onboarding. Just go to aistudio.google.com, sign in with your Google account, and you're in.

It sits at the intersection of playground and development tool. Researchers use it to experiment. Developers use it to prototype. Teams use it to validate ideas before committing to a full integration.

What You Actually Need It For 💡

There are a few scenarios where Google AI Studio becomes indispensable:

Getting a Gemini API Key:
This is often the first reason developers land on AI Studio. It's the official way to get a Gemini API key for free, which you then use in your own applications, in tools like Gemini CLI, Antigravity, or any custom integration. No credit card required for the free tier.

Testing Prompts Before Hardcoding Them:
Prompt engineering is trial and error. AI Studio gives you a fast feedback loop where you can iterate on prompts interactively, see the output, adjust, and repeat, before embedding anything in your codebase.

Exploring Model Capabilities:
Not sure if Gemini can handle your specific use case? Test it directly. Upload images, audio, documents, or code and see how different models respond. The multimodal support is all accessible through the UI.

Prototyping Features Quickly:
Even a small team can use it to create prototypes in days instead of weeks. The combination of interactive prompting and instant code export makes it genuinely fast to go from idea to proof of concept.

How It Works 🔧

The interface is organized around a few core concepts:

Prompts and Conversations

When you open AI Studio, you can start a new prompt immediately. You choose between three modes:

Chat Prompts:
Multi-turn conversations where you can test how the model handles back-and-forth dialogue. Perfect for chatbots, assistants, or any conversational feature.

Stream Mode:
Designed for real-time interactivity, it includes webcam integration, screen sharing, and live guidance. This is the mode for live, low-latency applications.

Structured Output:
Force the model to respond in JSON format with a schema you define. Essential when you need predictable, parseable output to feed into your app.

Model Selection

The platform features a multi-model playground allowing you to switch between models seamlessly while working. You can compare responses between Gemini 2.5 Pro, Gemini 2.5 Flash, and other variants side by side. Each model has different trade-offs between speed, cost, and reasoning depth, and AI Studio is the best place to understand those differences before committing to one.

System Instructions

This is where it gets interesting for developers. You can set a system prompt that shapes the model's behavior, persona, and constraints for the entire session. This is exactly how you'd configure an AI assistant for your product, and you can refine it here until it behaves exactly how you want.

Parameters and Controls

On every prompt, you have direct control over:

Temperature: How creative or deterministic the output is
Max output tokens: Limit the response length
Top-P and Top-K: Fine-grained sampling controls
Safety settings: Adjust content filtering thresholds

Changing these and seeing how responses shift in real time is one of the most educational things you can do as someone building with AI.

Get Code

Once you have a prompt and configuration that works, you can click "Get Code" to instantly generate a working code snippet in Python, Node.js, or REST that you can use to integrate that functionality into your own application via the Gemini API.

This is the feature that saves the most time. You iterate in the UI, then export the exact configuration as runnable code. No manual translation needed.

Multimodal: More Than Just Text 🌈

One of AI Studio's strongest points is how naturally it handles multiple input types. You can drag and drop into a prompt:

Images (for visual analysis, OCR, layout understanding)
PDFs and documents (for summarization, Q&A, data extraction)
Audio files (for transcription or analysis)
Videos (for content understanding with timestamps)
URLs (for web content analysis directly)
Code files (for explanation, review, or refactoring)

The Generative Media Kit unlocks creative potential with tools for generating images, speech, music, and videos. This makes AI Studio useful well beyond pure text use cases.

Free vs. Paid: What's the Difference? 💰

AI Studio has a generous free tier, but there are real differences worth knowing:

Free Tier:

Access to most Gemini models
Rate-limited API calls (enough for prototyping and personal projects)
Your prompts and data may be used to improve Google's models
No charge, just a Google account

Paid Tier (via Gemini API billing):

Higher rate limits and quotas
Your data is not used for model training, which is a necessity for most commercial or sensitive applications
Access to advanced features like caching and batch processing
Suitable for production applications

For individual exploration, side projects, and prototyping, the free tier is more than enough. For anything you're shipping to users with sensitive data, upgrade before going live.

AI Studio vs. Vertex AI: Which One? 🤷

A common question for developers already in the Google Cloud ecosystem. The short answer:

Google AI Studio is for individuals, developers, and fast prototyping. Browser-based, simple setup, no infrastructure knowledge required.

Vertex AI is for teams, enterprises, and production-scale deployments. More powerful, more complex, integrates with the full Google Cloud stack, and requires GCP setup and billing configuration.

If you're just getting started or working on a side project, AI Studio is the right choice. If you're building a production system that needs autoscaling, monitoring, and enterprise compliance, you'll eventually migrate to Vertex AI, but start in AI Studio first.

Practical Use Cases 🛠️

Here's how I actually use Google AI Studio in my workflow:

Validating prompt ideas for Gemini CLI Skills:
Before writing a SKILL.md, I test the core instructions in AI Studio to see how the model responds. If it doesn't behave as expected there, it won't behave as expected in the terminal either.

Grabbing API keys for new projects:
Every time I start a new project that needs Gemini integration, AI Studio is where I go first to create a key.

Understanding model differences:
When deciding between Gemini 2.5 Pro and Flash for a specific task, I run the same prompt against both in AI Studio and compare speed vs. quality trade-offs.

Exporting prompt configurations:
When a prompt works well in AI Studio, I click "Get Code" and drop the exported snippet directly into my project as a starting point.

Final Thoughts 🌟

Google AI Studio is the kind of tool that sounds simple until you realize how much time it saves. It's not trying to replace your IDE or your production infrastructure. It's the place you go to think, experiment, and validate before committing to anything.

If you're building with Gemini, it's effectively mandatory. And even if you're just AI-curious and want to understand what these models can actually do, spending an hour in AI Studio will teach you more than reading documentation for days.

Free, browser-based, no setup. There's really no reason not to try it.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Gemini CLI Skills: Teaching Your Terminal Agent How to Think 🧠

Domenico Tenace — Tue, 26 May 2026 06:00:00 +0000

Overview

Hey everyone 👋

If you've been using Gemini CLI for a while, you've probably noticed that the agent is great at general tasks but sometimes needs guidance for specific workflows. That's exactly what Skills are for.

Skills are one of the most underrated features of Gemini CLI, and once you start using them, you'll wonder how you ever managed without. Today I'll walk you through what they are, how to create them, and a real-world example you can steal immediately.

Let's start! 🤙

Quick Note Before We Start 📢

Google has announced that Gemini CLI will transition to Antigravity CLI on June 18th for free tier and Google One users. The good news? Skills work the same way in both tools, so everything you learn here applies directly to Antigravity CLI. If you're already in the migration window, just replace "Gemini CLI" with "Antigravity CLI" in your head.

What Are Skills? 🤔

Think about the difference between a generalist and a specialist. A generalist knows a bit of everything but lacks deep expertise in any one area. A specialist has deep knowledge in their domain and knows exactly how to approach problems in that field.

By default, Gemini CLI is a generalist. It knows a lot, but it doesn't know your specific project, your team's conventions, or the exact steps your deployment pipeline requires.

Skills turn the generalist into a specialist.

A Skill is a self-contained directory that packages specialized instructions and context into a discoverable capability. Unlike GEMINI.md files that are always loaded into context, Skills are loaded on demand, only when the agent determines they're relevant to your current task.

This distinction matters a lot. If you put everything into GEMINI.md, you quickly saturate the model's context window with information that's irrelevant to most tasks. Skills solve this with Progressive Disclosure, the agent sees a brief description of every skill, and only loads the full instructions when the skill is actually needed.

The result: the right knowledge, at the right time, without cluttering the context.

The Anatomy of a Skill 🏗️

A Skill is just a folder with a specific structure:

.gemini/skills/
└── my-skill/
    ├── SKILL.md          # The main definition file (required)
    ├── examples/         # Reference implementations (optional)
    ├── resources/        # Templates and assets (optional)
    └── scripts/          # Helper scripts (optional)

The only required file is SKILL.md. Everything else is supporting material that the agent can reference when the skill is activated.

The SKILL.md File

This is the heart of every skill. It has two parts: a frontmatter header and a body with instructions.

---
name: your-skill-name
description: What this skill does. Use when you need to...
---

# Skill Title

Your instructions here.

The frontmatter is crucial. The description field is what the agent reads at the start of every session to decide whether to load this skill. Write it clearly and specifically, a vague description will cause the skill to be activated at the wrong times (or never).

Good description:

"Reviews code changes for security vulnerabilities, performance issues, and adherence to project conventions. Use when reviewing PRs or checking code before merging."

Bad description:

"Code review stuff."

Where to Put Your Skills 📁

Gemini CLI discovers skills from two locations, and which one you use depends on scope:

Project Skills (.gemini/skills/ in your repo):
These are tied to a specific project. Commit them to version control and your whole team gets the same specialized behavior. Perfect for project-specific workflows like deployment steps, framework conventions, or codebase-specific review guidelines.

Global Skills (~/.gemini/skills/ in your home directory):
These work across all your projects. Perfect for personal workflows, general coding standards, or tools you use everywhere.

The mental model: if a skill is useful for your team and the project, put it in the repo. If it's personal productivity, put it globally.

Creating Your First Skill: Step by Step 🔧

Let's create a practical skill for code review. Here's the full process:

Step 1: Create the Directory

For a project skill:

mkdir -p .gemini/skills/code-review

For a global skill:

mkdir -p ~/.gemini/skills/code-review

Step 2: Write the SKILL.md

Create .gemini/skills/code-review/SKILL.md:

---
name: code-review
description: Reviews code changes for bugs, security issues, performance problems, and style consistency. Use when reviewing PRs, checking diffs, or auditing code quality before merging.
---

# Code Review Skill

You are an expert code reviewer. When reviewing code, follow this checklist systematically.

## Review Checklist

### Correctness
- Does the code do what it's supposed to do?
- Are there logic errors or off-by-one mistakes?
- Are all edge cases handled?

### Security
- Are inputs validated and sanitized?
- Are there potential injection vulnerabilities?
- Is sensitive data handled securely?

### Performance
- Are there unnecessary loops or redundant operations?
- Are database queries optimized?
- Are there memory leaks or heavy resource usage?

### Style and Conventions
- Does the code follow the project's naming conventions?
- Is the code readable and well-structured?
- Are functions small and single-responsibility?

## How to Provide Feedback

For each issue found:
1. Specify the exact location (file and line number)
2. Explain what the problem is and why it matters
3. Suggest a concrete fix with a code example when possible

End the review with a summary: overall assessment (Approve / Request Changes / Needs Discussion) and a brief explanation.

Step 3: Verify the Skill Is Discovered

Start Gemini CLI in your project directory and run:

/skills

You should see your code-review skill listed. If it's not there, double-check the directory structure and file naming.

Step 4: Use It

Just work normally. When you ask for a code review:

Review the changes in auth.js before I merge this PR

Gemini CLI sees the request, matches it against the skill description, loads the full SKILL.md, and follows your checklist systematically. You don't need to explicitly invoke the skill, it happens automatically.

A Practical Example: Conventional Commits Skill 📝

Let me share another skill I use constantly, one that enforces Conventional Commits format across all my projects.

Create .gemini/skills/conventional-commits/SKILL.md:

---
name: conventional-commits
description: Generates commit messages following the Conventional Commits specification. Use when creating, reviewing, or suggesting git commit messages.
---

# Conventional Commits Skill

You are an expert at writing clear, structured commit messages following the Conventional Commits 1.0.0 specification.

## Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)] 

## Types

- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation changes only
- **style**: Formatting changes (no code logic change)
- **refactor**: Code change that neither fixes a bug nor adds a feature
- **perf**: Performance improvement
- **test**: Adding or updating tests
- **chore**: Build process or auxiliary tool changes

## Rules

1. Use the imperative mood in the description ("add feature" not "added feature")
2. Lowercase the entire first line
3. No period at the end of the description
4. Keep the description under 72 characters
5. The body explains "what" and "why", not "how"
6. Reference issue numbers in the footer: `Closes #123`

## Examples

- feat(auth): add JWT token refresh logic
- fix(api): handle null response from payment provider
- docs: update README with pnpm installation steps
- refactor(utils): extract string validation to dedicated module 

When suggesting a commit message, always explain your reasoning for the chosen type and scope.

Now whenever you ask Gemini CLI to help with a commit:

Write a commit message for the changes I just made to the authentication module

The agent loads the skill, understands the full convention, and generates a properly formatted message with the right type, scope, and description style.

Skills vs. GEMINI.md: When to Use What 🔄

A common question: when should you put something in a Skill vs. in GEMINI.md?

Use GEMINI.md for:

Information the agent always needs (project name, tech stack, folder structure)
General coding standards that apply to every task
Critical context that should never be missing

Use a Skill for:

Specialized workflows that only run sometimes (deployments, code review, testing)
Deep expertise for a specific domain (security auditing, accessibility checking)
Complex checklists that would waste context when not needed
Anything you only need occasionally but need deeply when you do

The rule of thumb: if you'd be annoyed by the agent using this knowledge on unrelated tasks, it's a skill. If you'd be annoyed if the agent ever lacked this knowledge, it belongs in GEMINI.md.

Tips for Writing Good Skills 💡

After creating several skills, here's what actually works:

Write narrow descriptions. The description is how the agent decides whether to activate the skill. Narrow is better than broad. "Use when reviewing PRs or checking code quality" is better than "Use for coding tasks."

Add explicit "do not use" hints when needed. If your skill might be over-activated, add clarity: "Do not use for general coding questions or feature implementation."

Keep SKILL.md focused. Put detailed examples and templates in the examples/ or resources/ subdirectories. The core SKILL.md should be scannable and concise.

One skill, one responsibility. Don't create a "general development" mega-skill. Create separate skills for deployment, testing, code review, etc.

Test activation. After creating a skill, try prompts that should and shouldn't activate it. If it activates when it shouldn't, tighten the description.

Final Thoughts 🌟

Skills are a small investment with a big return. You spend 10-15 minutes writing a SKILL.md once, and the agent follows your exact workflow consistently from that point on.

The bigger picture: Skills are how you transform Gemini CLI (or Antigravity CLI) from a generic AI assistant into a tool that understands your team, your conventions, and your processes. The more skills you build, the more the agent feels like a teammate rather than a tool.

Start small, maybe with a code review skill or a commit message skill, and build from there. You'll quickly start noticing the moments where the agent "just knows" what you need, and that's when it clicks.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Gemini CLI: Google's Free AI Agent for Your Terminal 🚀

Domenico Tenace — Tue, 12 May 2026 06:00:00 +0000

Overview

Hey everyone 👋

Google recently dropped something that's been flying under the radar: Gemini CLI, a free, open source AI agent that brings the power of Gemini directly into your terminal. While everyone's been debating Cursor vs Claude Code, Google quietly built a terminal AI that's actually free and surprisingly capable.

I've been using it for a few weeks, and I wanted to share what it is, how it works, where it shines, and where it falls short compared to the competition.

Let's dive in! 🤙

What Is Gemini CLI? 🤔

Gemini CLI is an open source AI agent that runs entirely in your terminal. Think of it as having Gemini 2.5 sitting at your command line, able to read your code, write files, run commands, and help you build software through conversation.

It's not just a chatbot with access to your terminal, it's an agentic tool that uses a ReAct (Reason and Act) loop to complete complex tasks autonomously. You give it a goal, it makes a plan, executes steps, validates results, and iterates until the task is complete.

The Core Philosophy

Google built Gemini CLI with a terminal-first philosophy. It's designed for developers who live in the command line and don't want to context-switch to a GUI. Everything happens in a single terminal pane: the conversation, file edits, command execution, and results.

This is different from tools like Cursor, which give you a full IDE experience. Gemini CLI embraces minimalism, the terminal is your interface, and that's it.

How It Actually Works 💻

Installing Gemini CLI is dead simple:

npm install -g @google/gemini-cli

Or use it without installing:

npx @google/gemini-cli

Once installed, just type gemini in your project directory, authenticate with your Google account, and you're in.

The Authentication Options

Gemini CLI offers several auth methods:

Personal Google Account (Free):
60 requests per minute, 1,000 requests per day. This is the generous free tier that makes Gemini CLI attractive.

Google AI Studio API Key:
Pay-as-you-go with usage-based billing. For heavy users who exceed the free quota.

Vertex AI:
For enterprise users who need Gemini Code Assist integration and higher limits.

Most individual developers will be perfectly happy with the free tier. 60 requests per minute is generous for typical development workflows.

The Agent Experience

When you start Gemini CLI, you get an interactive prompt. You can:

Ask questions about your codebase
Request file edits or new features
Run terminal commands through the agent
Search the web for documentation
Work with images and documents
Execute multi-step workflows

The agent reads your entire project context (up to 1M tokens with Gemini 2.5 Pro), understands your code structure, and makes changes that respect your existing patterns.

Example conversation:

You: Add user authentication to this Express app with JWT tokens
Agent: [reads codebase, creates plan]
Agent: I'll create:
  1. auth middleware (auth.js)
  2. login/signup routes (routes/auth.js)
  3. JWT token utilities (utils/jwt.js)
  4. update existing routes to use auth middleware

Proceed? (y/n)

You approve, and the agent executes the plan, creating files, writing code, and updating your project.

The Built-in Tools 🛠️

Gemini CLI comes with several built-in tools that the agent uses automatically:

Google Search Integration:
The agent can search the web and ground its responses in current information, perfect for finding documentation or recent API changes.

File Operations:
Read, write, create, delete files across your project.

Shell Command Execution:
Run terminal commands, install dependencies, run tests, commit changes, etc.

Web Fetching:
Retrieve web pages and documentation directly into the conversation context.

MCP Server Support:
Integrate custom tools via Model Context Protocol. Want to connect Slack, GitHub, databases, or custom APIs? MCP makes it possible.

The Competitors 🥊

Gemini CLI isn't alone in the terminal AI space. Let's see how it stacks up against the main players.

Claude Code

Claude Code is a terminal-based AI coding assistant built on Anthropic's Claude models. It enables developers to generate, refactor, and reason about code through conversational prompts directly in the command line.

Similarities:
Both are terminal-first agents, both support MCP, both handle multi-step tasks autonomously.

Key Differences:
Claude Code uses Claude models exclusively (Opus, Sonnet) while Gemini CLI uses Gemini 2.5 Pro/Flash. Claude Code delivers the full 200K token context reliably, with a 1M token beta on Opus 4.6, while Gemini CLI offers up to 1M tokens with Gemini 2.5 Pro from the start.

Pricing:
Claude Code is pay-per-token (typically $100-200/month for heavy users). Gemini CLI's free tier is genuinely generous at 60 requests/min.

My take: Claude Code is more mature and polished, but Gemini CLI's free tier is hard to beat for individuals.

Aider

Aider is a Git-native, terminal-based AI coding assistant built to support collaborative, open source workflows.

Similarities:
Both are terminal tools, both are open source, both support multiple LLM providers.

Key Differences:
Aider's strength is that it thinks in git. Every edit is a commit. Every session is a branch you can review, revert, or cherry-pick. Gemini CLI is less git-centric, it's more general-purpose.

My take: If you care deeply about git-native workflows, Aider wins. If you want Google Search integration and broader capabilities, Gemini CLI is better.

Cursor

Cursor isn't really a competitor, it's a different category. Cursor operates as a full-featured IDE with AI capabilities embedded throughout the interface, while Gemini CLI is terminal-only.

The Difference:
Cursor is IDE-first. You drive, the AI assists with completions, suggestions, and edits you approve inline. Gemini CLI is agent-first, you delegate tasks and review results.

My take: Many developers use both. Cursor for active coding sessions, Gemini CLI for delegated tasks or automation.

Where Gemini CLI Excels ✨

After using Gemini CLI alongside other tools, here's where it genuinely shines:

The Free Tier Is Real

60 requests per minute and 1,000 requests per day is generous. Most developers won't hit these limits in normal usage. This makes Gemini CLI the most accessible terminal AI for individuals and students.

Claude Code costs money from day one. Gemini CLI is actually free for most use cases.

Large Context Window

1M tokens with Gemini 2.5 Pro means you can load massive codebases into context. For large refactoring tasks or understanding complex systems, this is powerful.

I've successfully used it to analyze entire monorepos that would have required chunking with smaller context windows.

Google Search Integration

The built-in Google Search tool is surprisingly useful. When the agent encounters something it doesn't know (a new API, a recent framework update, etc.), it can search the web and incorporate current information.

This beats having to manually look things up and paste documentation into the conversation.

MCP Server Support

Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools. Want to integrate GitHub, Slack, databases, or custom APIs? MCP makes it straightforward.

This extensibility means Gemini CLI can grow with your needs.

Multimodal Capabilities

Gemini's vision capabilities are available in the CLI. You can include images in your prompts, perfect for "implement this UI mockup" or "what's wrong with this screenshot" tasks.

Not many terminal AIs support this out of the box.

Low Barrier to Entry

Install with npm, authenticate with Google, done. No API keys to manage (unless you want to), no credit card required, no complex setup.

This makes it perfect for trying out terminal AI without commitment.

Where Gemini CLI Falls Short 😬

Nothing's perfect, and Gemini CLI has real weaknesses:

The UX Needs Polish

Compared to Claude Code's refined interface, Gemini CLI feels rougher around the edges. Error messages aren't always clear, the terminal UI can get cluttered, and occasionally the agent loses track of context mid-task.

It's usable, but it's not as smooth as more mature tools.

Model Quality Varies

Gemini 2.5 Pro is powerful, but it's not Claude Opus. Claude Code for reasoning depth (80.9% SWE-bench). Gemini scores lower on code-specific benchmarks.

For complex reasoning or nuanced refactoring, Claude Code often produces better results.

Limited Community Resources

Claude Code and Aider have large, active communities. Gemini CLI is newer, so there are fewer tutorials, examples, and community-built extensions.

When you hit an issue, you're more likely to be on your own.

Terminal-Only Limitation

Some developers prefer having a visual IDE experience with file trees, side-by-side diffs, and graphical interfaces. Gemini CLI offers none of that, it's terminal or nothing.

If you're not comfortable working purely in the command line, this is a dealbreaker.

Quota Limits for Free Tier

While 60 req/min is generous, heavy users will hit the 1,000 req/day limit. If you're doing intensive work, you'll need to either slow down or pay for API access.

Claude Code's pay-per-token model might actually be cheaper for very heavy usage.

Real-World Use Cases 💼

Here's what I've actually used Gemini CLI for:

Refactoring Legacy Code:
I pointed it at an old project with inconsistent patterns and asked it to modernize the code. The 1M token context meant it could understand the entire codebase and make consistent changes.

Documentation Generation:
"Read this codebase and create comprehensive README documentation." It analyzed the code, understood the architecture, and wrote decent docs.

Debugging:
When I hit errors I couldn't figure out, I'd paste them into Gemini CLI. The Google Search integration meant it could find relevant Stack Overflow answers or GitHub issues.

Prototyping:
"Create a simple Express API with user authentication and a todo list." Quick prototypes are where Gemini CLI excels, fast iteration without worrying about costs.

Learning New Tech:
"Explain how this React codebase implements authentication." The agent would analyze the code and explain patterns, great for onboarding to unfamiliar codebases.

Who Should Use Gemini CLI? 🎯

Gemini CLI isn't for everyone. Here's who will benefit most:

Students and Learners:
The free tier makes it perfect for learning. No financial barrier to experimenting with AI-assisted development.

Individual Developers:
If you don't need enterprise features and want a free terminal AI, Gemini CLI is excellent.

Open Source Maintainers:
For working on community projects where you don't want to pay out of pocket, the free tier is generous enough for regular use.

Developers Trying Terminal AI:
If you're curious about terminal-based AI agents but don't want to commit to paid tools, start here.

Budget-Conscious Teams:
Small teams or startups that can't afford $20-40/month per developer for Claude Code or Cursor.

Who Should Look Elsewhere? 🤷

Gemini CLI isn't ideal if:

You Need the Best Code Quality:
Claude Opus produces higher-quality code for complex tasks. If quality matters more than cost, pay for Claude Code.

You Prefer Visual IDEs:
If terminal-only feels limiting, use Cursor, Windsurf, or another IDE-based tool.

You're a Power User:
If you'll exceed 1,000 requests/day regularly, the free tier won't cut it, and paying for Gemini API might cost more than a Claude Code subscription.

You Need Enterprise Features:
For teams requiring compliance, audit logs, and enterprise support, look at Gemini Code Assist or Claude Code Enterprise.

My Honest Take 💭

Gemini CLI is a solid terminal AI that punches above its weight thanks to the generous free tier. It's not the most polished, and it's not the highest quality, but it's free and good enough for most tasks.

If you're an individual developer who lives in the terminal and wants to try AI-assisted development without paying, Gemini CLI is the obvious choice. The 60 req/min and 1,000 req/day limits are genuinely usable.

That said, if you're doing professional work where code quality matters and you can afford $20-40/month, Claude Code is still better. The reasoning quality, the polish, and the maturity are worth paying for.

But for learning, side projects, open source work, and experimentation? Gemini CLI is fantastic. Google's strategy of making it free is smart, it gets developers hooked on terminal AI without financial friction.

Try It Yourself 🚀

If you're curious, just run:

npx @google/gemini-cli

No commitment, no credit card, no setup beyond Node.js. Try a few tasks and see how it feels.

The worst that happens is you waste 10 minutes. The best that happens is you discover a free tool that transforms how you work.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

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

Why I Built CVE Lite CLI: Moving From "Security Debt" to Real-Time Scanning

Sonu Kapoor — Wed, 29 Apr 2026 02:35:47 +0000

From Security Noise to Developer Flow: Introducing CVE Lite CLI v1.10.0

We have all lived through it. It is Friday afternoon, you have just finished a complex feature, and your code is ready for the finish line. You push your final commit to the CI/CD pipeline, feeling confident, only to receive a notification ten minutes later: Build Failed.

When you open the logs, you are handed a massive report with 40 "Critical" vulnerabilities. Suddenly, your weekend is gone while you dig through deep dependency trees, trying to figure out if a vulnerability in a dev-dependency you do not even use is actually a threat. This is the "Security Debt" cycle: a situation where security scanning is loud, late, and incredibly frustrating.

The Problem: When "Standard" Audits Fail You

The issue is not usually the vulnerabilities themselves—it is the timing and the noise. Most traditional scanners treat every vulnerability with the same weight, regardless of whether that code is actually reachable or if a fix is even available.

Worse, standard tools like npm audit can create a false sense of security while hiding critical traps. A perfect example is the recent community discussion regarding lint-staged (Issue #1763), where high-severity vulnerabilities can remain "hidden" deep in the dependency tree, escaping standard surface-level scans. This forces teams to choose between shipping features and playing security detective. When security feels like a list of chores rather than a part of the craft, it becomes something developers try to bypass rather than embrace.

How We Compare: Workflow vs. Visibility

As I recently explored in InfoWorld, the gap in modern security is not detection—it is the lack of a workflow that developers actually use. While most enterprise tools are built for "organizational visibility," CVE Lite CLI is built for developer decision-making.

Feature	`npm audit`	Snyk (Free Tier)	CVE Lite CLI
Noise Filtering	None (Flags all)	Moderate	High (Heuristic Logic)
Primary Speed	Fast	Network Dependent	Ultra-fast (Local Engine)
Actionable Insight	Low (Alert only)	Moderate	High (Direct vs Transitive)
Workflow Fit	Blocking Gate	Post-Push Audit	Pre-Commit / Real-Time

For a deep dive into how we stack up against other security scanners, check out our Full Comparison Documentation on GitHub.

The Solution: Shifting Logic to the Local Terminal

I developed CVE Lite CLI to change this dynamic. The core philosophy is to make security scanning as fast, local, and quiet as a unit test. Instead of waiting for a central server to tell you what is wrong, CVE Lite brings that intelligence directly to your terminal.

With the release of v1.10.0, we are introducing the Verified Remediation Engine. Key features include:

Heuristic Logic: A refined engine designed to prioritize what is actually actionable.
Noise Reduction: By focusing on separating "Direct" vulnerabilities (those you can fix with a single command) from "Transitive" noise, it allows you to clean up your dependency tree in real-time.
Developer-First UX: It is designed to be a "quiet" tool that only speaks up when there is a legitimate concern, fitting right into your standard git commit or build loop.

Proving the Logic: OWASP Juice Shop Remediation

To prove the efficacy of this approach, we ran CVE Lite CLI against the OWASP Juice Shop —the industry standard for insecure web applications. Rather than just generating a static list of flaws, we used the tool to drive a targeted remediation workflow.

The results demonstrate how a multi-pass approach can systematically dismantle security debt without overwhelming the developer:

Remediation Stage	Total Findings	Critical	High	Medium	Direct	Transitive	Unique Advisories
Baseline Scan	39	3	1	11	10	29	71
After 1st Pass	27	1	0	10	4	23	41
After 2nd Pass	18	1	0	5	3	15	32

As the data shows, the first pass alone cleared the majority of "Directly" actionable issues and zeroed out the "High" severity vulnerabilities. This visibility allows a developer to see exactly where their effort will have the highest impact, turning a daunting report into a manageable task.

A New Chapter with OWASP

This philosophy recently reached a major milestone: CVE Lite CLI has been officially adopted by the OWASP Foundation as part of their Incubator.

Joining the OWASP ecosystem means we are now working with global security experts to refine these heuristics and build a roadmap that helps every developer build more secure software without sacrificing velocity. Security should not be a "Friday afternoon surprise". It should be a natural, quiet part of how we write code every day.

What is Next?

If you want to move away from noisy scanners and into a workflow that focuses on what is actually fixable, I’d love for you to join us. Check out our progress on the OWASP CVE Lite Project Page or use npm to install npm i cve-lite-cli the latest version to run a scan on your own project.

Let's make "shifting left" more than just a buzzword.

DEV Community: Playful Programming

OpenRouter: One API Key to Rule Them All 🔑

Overview

What Is OpenRouter? 🤔

How It Works 🔧

Provider Routing and Fallbacks

The Free Tier

Pricing: What You Actually Pay 💰

OpenRouter + OpenCode 🔗

The Pros 👍

The Cons 👎

Who Should Use OpenRouter? 🎯

Final Thoughts 🌟

OpenCode: The Open Source Coding Agent That Doesn't Lock You In 🔓

Overview

What Is OpenCode? 🤔

How It Works 🔧

The Pricing Reality 💰

The Anthropic Block: What Happened and Where It Stands 🚧

OpenCode vs Claude Code: The Real Differences 🥊

Terminal experience

Autonomy features

Output quality

The Pros 👍

The Cons 👎

Who Should Use OpenCode? 🎯

My Honest Take 💭

Domenico TenaceFollow

Introducing Argus: The Code Security Colleague Your Team Doesn't Have

Why security review needs a different shape

Structured tools, not a shell

Roles and an audit log

SOUL, context, and a memory built for security

What Argus does today (v0.2)

Where it's going

Come build in AI and security

Gemini 3.6 Flash: Google's Fastest Bet in a Crowded Race 🚀

Overview

What Is Gemini 3.6 Flash? 🤔

The Numbers: What Actually Changed 📊

Benchmarks

Speed

Pricing

Context Window and Knowledge Cutoff

Token Efficiency

How It Compares to the Competition 🥊

vs. Claude Sonnet 5

vs. GPT-5.6 Luna

vs. Gemini 3.5 Flash

What's Missing: The Elephant in the Room 🐘

The Pros 👍

The Cons 👎

Who Should Use Gemini 3.6 Flash? 🎯

My Take 💭

Domenico TenaceFollow

Automating my Codemotion Badge with Antigravity

Small intro about the board

Antigravity

Let’s start cooking

CMNode v0 WiFi Configuration & Dual Screen Setup

User Review Required

Ideas for the "Fantastic" Second Screen:

Proposed Changes

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Verification Plan

Manual Verification

CMNode v0 WiFi Configuration & Dual Screen Setup

Design Choice: "Hacker Terminal"

Proposed Changes

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Verification Plan

Manual Verification

The implementation

The refine

Conclusion

Daily Prompt Is Out. Long Live Spellbook of Prompt 🧙🏻‍♂️

Overview

What Was Daily Prompt? 🤔

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)