DEV Community: Matthew Revell

$500 Challenge Drop

Matthew Revell — Fri, 22 May 2026 14:54:18 +0000

If you’re taking part in 100 Days of Solana, look out for the $500 Challenge Drop.

Complete Monday’s or Tuesday’s challenge (Day 36 or 37) and you’ll be entered for a random chance to win $500.

That’s it: complete the challenge, submit your work, and you’re in the draw.

What is 100 Days of Solana?

100 Days of Solana is a daily, hands-on learning challenge from MLH and Solana for Web2 developers who want to understand Solana by building with it.

Each challenge introduces one practical concept at a time, using familiar JavaScript tooling while gradually moving from fundamentals like keypairs and transactions into tokens, accounts, and programmable assets.

This week’s challenges continue the move into Token Extensions, where Solana tokens start to feel less like static assets and more like programmable building blocks.

How to enter

To be entered for the $500 Challenge Drop:

Complete Monday’s or Tuesday’s 100 Days of Solana challenge
Submit your work at the bottom of the challenge
You’ll be entered for a random chance to win $500

Start here: mlh.link/solana-100

Complete the challenge, submit your work, and you’re in.

Arc 1 Recap: Keypairs, Wallets, and Solana Fundamentals

Matthew Revell — Fri, 22 May 2026 10:16:13 +0000

Typical web and mobile development often starts with a few familiar questions:

What's the data model going to look like?
How am I going to handle user accounts and auth?
Where am I going to host this thing?

Web3 development has its own set of "how do I start?" questions but they're not the same as what you'd expect if you're coming from a Web2 background.

Arc 1 of 100 Days of Solana was all about learning those fundamentals.

What are the Solana equivalents of user accounts, dev/prod environments, data storage, and so on?

Identity starts with a keypair

Identify works differently in the Web3 world. It starts with a keypair, rather than an account someone creates for you.

But the similarities with typical user accounts break down once you look at the detail.

A Solana keypair is created on your own computer.

There is no signup request, no account creation API, and no backend service issuing you an identity. Your machine generates two linked pieces of data:

a public key
a private key

The public key is your Solana address. You can share it freely, paste it into a faucet, or look it up in a block explorer.

The private key proves that you control that address. You keep it secret, just like you would keep an SSH private key secret.

The important thing to understand is this:

Creating a keypair gives you a valid Solana address, but it does not automatically create anything on-chain.

That can feel strange if you are coming from Web2. In a normal web app, a user account usually appears only after a row is inserted into a database. On Solana, the address can exist before the network has stored any data for it.

So there are two related ideas:

The address:
This exists as soon as your keypair exists. It is just derived from your public key.

The on-chain account:
This exists on a specific Solana cluster only once the network starts storing state for that address. For example, that might happen when you receive devnet SOL from a faucet.

That means a brand-new address can be completely valid, even if Solana Explorer shows no account data for it yet.

It is a bit like generating an SSH key. You can create the key locally before any server knows about it. The public key is real immediately, but it only becomes useful on a specific server once that server has been told about it. On Solana, your address is real immediately, but a particular cluster only stores account state for it once something happens there.

This is one of the first places where the usual Web2 mental model starts to shift. In a Web2 app, an account usually begins as something a service creates and stores. On Solana, control is cryptographic: you control the wallet because you hold the key that can sign for it. No company needs to store your credentials before the address exists, and no admin panel can recover the private key for you.

That is not the whole story of Solana, but it is one of the foundations everything else builds on. If you do not understand what controls an address, transactions, accounts, tokens, and programs all feel more mysterious than they need to.

From generated key to funded address

If you know one thing about Web3, it might be that each blockchain has its own currency. On Solana, that currency is SOL.

SOL is what pays for activity on the network. In Arc 1, though, we did not start by spending real money. We started with devnet SOL: free test tokens used on Solana’s developer network.

A few lines of @solana/kit produced a brand-new keypair. The important call was small: generateKeyPairSigner() created a signer and returned an address that we could print straight to the terminal.

That first step is intentionally plain. Before there is a wallet app, login screen, dashboard, or account setup flow, there is just a keypair:

a public key, which gives you a Solana address
a private key, which proves you control that address

We then funded that address with free devnet SOL from the Solana faucet. More precisely, the faucet sent lamports to the address. Lamports are the smallest unit of SOL, a bit like cents are to dollars, except 1 SOL equals 1,000,000,000 lamports.

After that, a balance check showed that the address now had account state on devnet.

That is a useful break from the usual Web2 sequence.

In a typical web app, the user account usually starts as a row in a database. The app creates the account, stores the user record, and then the user can do things.

On Solana, the address can exist first. It is valid as soon as the keypair is generated. The network only starts storing account state for that address on a particular cluster once something happens there, such as receiving lamports.

Arc 1 also introduced devnet, one of the most important environments for learning Solana. We were not using local mocks or screenshots of a production system. We were using a real Solana cluster with the same core APIs and concepts as mainnet, but with tokens that have no real-world value.

Persistence makes the key useful

Generating a keypair is only the first step.

If the keypair lives only in memory, it disappears when the script exits. That is fine for a quick demo, but it is not enough if we want to keep using the same Solana identity.

So the next step was persistence. We saved the keypair to a local JSON file, then loaded it again each time the script ran.

That gave us the same address across multiple runs.

This is the point where Solana identity starts to feel less abstract. In a Web2 app, your identity is usually tied to something recoverable: an email address, a password reset flow, maybe a login provider.

With a keypair, the private key is the thing that matters.

If someone has the private key, they can sign transactions for that address. They do not need your password. They do not need your email account. They do not need approval from a backend service.

For devnet, storing a keypair in a local JSON file is fine. There is no real value at stake. But the same approach would be a serious mistake for mainnet funds or production users.

Arc 1 made that visible early:

Key storage affects security.
Address reuse affects privacy.
Signing is how authorization works.

Lamports make value precise

Arc 1 also introduced the unit Solana programs actually work with: lamports.

Wallets usually show balances in SOL because that is easier for humans to read. But Solana code works in lamports because programs need exact whole-number values.

One SOL is 1,000,000,000 lamports.

This should feel familiar if you have worked with payments APIs. Stripe does not ask you to send $19.99 as a decimal amount. It asks for 1999 cents, because money should not be handled with floating point arithmetic.

Solana follows the same basic idea. The network needs every validator to calculate the same result exactly. That means balances, transfers, and fees are represented as integers, not rounded decimal values.

So there are two units to keep straight:

SOL is the readable display unit.
Lamports are the exact unit used by the network.

That small distinction teaches a bigger Solana lesson. What humans see is not always what programs store, sign, or verify. As a developer, you need to know when you are dealing with a friendly display value and when you are dealing with the precise value the network will actually use.

The app gets an address, not your private key

After working with raw keypairs in scripts, we connected a real browser wallet.

Using the Wallet Standard and @wallet-standard/app, we built a browser app that could detect installed wallets such as Phantom, Solflare, and Backpack. The app requested a connection, then displayed the selected address and its devnet balance.

That is the important distinction: the app could show the address and read the balance, but it never handled the private key.

The wallet kept custody of the key. The app only received the public address.

For Web2 developers, this is closer to using an external identity provider than asking users to type their password into every app. The app delegates key management to the wallet. When it needs proof that the user controls an address, it asks the wallet to sign something.

But connecting a wallet is not the same as a full login session.

A wallet connection gives the app an address. It tells the app, “This is the address the user has chosen to share.” It does not automatically prove that the user should stay logged in, access a private account, or perform sensitive actions.

For that, an app usually needs a separate signing step. The wallet signs a message or transaction, and that signature proves control of the address. The wallet should ask the user before signing anything meaningful.

That is why real Solana apps should not ask users to paste secret keys into a form. The private key stays in the wallet. The app asks the wallet for addresses and signatures.

Arc 1 covered both raw keypair management and browser wallet connection because they teach different parts of the same model:

Raw keypairs show what is happening underneath.
Wallet connections show how users should normally interact with apps.

If you come from Web2, connecting a wallet can look a bit like “Sign in with Google.”

Your app does not handle the user’s Google password. The user approves access through Google, and your app receives enough information to recognize them.

A Solana wallet plays a similar role in the app experience. It holds the user’s keys, asks for approval, and gives the app a public address to work with.

But the comparison only gets you so far.

Google is an identity provider. It can reset access, suspend accounts, enforce policies, and sit between the user and the apps they use.

A non-custodial wallet is different. It manages keys and asks the user to approve signatures, but it cannot recreate a lost private key. It also cannot invalidate a private key that still exists somewhere else.

That changes the shape of identity.

In a typical Web2 app, identity often starts with a database row. The app creates a user account, stores profile data, and provides recovery flows if something goes wrong.

On Solana, the address is the durable identifier. A signature is the proof that someone controls that address.

Your app can associate data with an address, but it does not own the user’s identity.

That can feel like losing control if you are used to backend-owned accounts. But it is one of the tradeoffs Solana asks developers to understand. Users can bring the same address to different Solana apps. They can connect, approve, disconnect, and move on.

That portability is powerful, but it has a privacy cost. If someone reuses the same address across many apps, their activity may be easier to link together.

That is why the Web2 analogies in Arc 1 are useful, but only up to a point:

SSH keys help explain keypairs.
Payments APIs help explain lamports.
OAuth-style login helps explain wallet connection.

None of those comparisons maps perfectly. But each gives Web2 developers a foothold before the Solana model starts to feel natural.

There is no ordinary password reset

Arc 1 also introduced one of the harder parts of the Solana mental model:

If you lose the private key, there is no ordinary password reset.

In a typical Web2 app, the service controls the account system. That is why it can offer recovery flows. You can reset a password, verify an email address, contact support, or use an identity provider to get back in.

That convenience comes with a tradeoff. The same service can also lock you out, leak credential data, change the rules, or shut the account down.

Solana works differently.

On Solana, control comes from signing. If you can sign with the private key for an address, you control that address. If you cannot sign, the network does not know that you are “really” the owner.

That makes key storage a real product decision, not just a technical detail.

Different approaches make different tradeoffs:

Browser wallets are convenient, but connected to everyday devices.
Hardware wallets add protection, but introduce more friction.
Custodial services can offer recovery, but someone else holds or manages the keys.
Multisig tools can share control across multiple people or devices.
Cold storage can improve security, but is less practical for frequent use.

The rule for real apps is simple:

Do not ask users to paste secret keys or seed phrases into your app.

A Solana app should connect to a wallet and ask for signatures. The wallet keeps the private key. The user approves or rejects the request. The app receives only what it needs.

Recovery also has to be designed deliberately. It is not a default support flow you get for free. Seed phrases, hardware wallets, multisig setups, and custody providers all exist because key loss, key theft, and shared control are real product problems.

Once that clicks, self-custody stops sounding like a slogan. It becomes a set of design choices about security, usability, and recovery.

You are building around a different foundation: control is proven by signatures, not granted by a service.

What Arc 1 sets up

By the end of Arc 1, we had worked through the core Solana fundamentals that everything else builds on:

generating a keypair in code
understanding public keys and private keys
funding an address on devnet
seeing the difference between an address and account state
saving and reloading a keypair from a local file
converting between SOL and lamports
reading raw lamport balances in logs
connecting a browser wallet to a web app
- understanding that connecting a wallet and signing are separate actions
explaining Solana identity in our own words

For Web2 developers, some of this should feel familiar.

If you have generated an SSH key, you already have a starting point for understanding keypairs. If you have used “Sign in with Google,” you already have a rough analogy for wallet connection. If you have handled money in cents through a payments API, you already understand why Solana uses lamports instead of decimal SOL values in code.

None of those comparisons is perfect. But they give us useful footholds.

Want to see the full thing? Check out the 100 Days of Solana daily challenge series.

Epoch 2: From Reading to Creating

Matthew Revell — Mon, 18 May 2026 12:18:24 +0000

Epoch 1 was about learning how Solana works: wallets, accounts, transactions, balances, and on-chain state.

Epoch 2 turns that foundation into something you can build with. You’ll create tokens, add metadata, experiment with fees and transfer rules, mint NFTs, and see how assets can carry behavior of their own.

What "programmable asset" actually means

We first met SOL pretty early in Epoch 1. It is the currency used on Solana to pay fees, fund accounts, and it gave you a clean first lap around transactions and Explorer.

So it would be easy to think of Solana mainly as a network for moving SOL around.

But Solana also lets you create assets whose rules are part of the asset itself: who can create more, who can hold them, whether they can move, whether transfers take a fee, and what metadata other apps can read.

That might sound like a lot, but the next four weeks of 100 Days of Solana break it down step by step.

If you've built Web2 products, you've probably worked with things users can earn, hold, spend, unlock, or display: loyalty points, in-app credits, course badges, gaming currencies, access passes, reputation scores.

In a traditional app, those things live in your database. Your backend decides how they are created, who they belong to, whether they can move between users, and what they can be used for.

On Solana, some of those rules can move into the asset itself.

To make that work, Solana splits those ideas across a few building blocks. A mint describes the asset. Token accounts record who holds it. Authorities decide who can create more, freeze accounts, update metadata, or collect fees.

A basic token can answer the first question: who holds how much?

But product ideas usually need more than that. What is this asset called? Can another app recognize it? Can it be transferred? Should transfers take a fee? Should a new holder be approved before they can use it?

Token-2022 is Solana’s token program for that next layer. It adds optional extensions, which are predefined features for metadata, fees, frozen accounts, non-transferability, interest-bearing display amounts, and other asset behaviors.

Some of those rules are configured on the mint. Some are tracked on token accounts. But the important shift is this: the rules are enforced by the token program, not only by your application.

Arc 5: A token and then a name for it

The first arc of Epoch 2 starts with the simplest asset you can create: a token on devnet.

You create the mint. You issue some supply to your own wallet. You open Explorer and there it is: an asset you created, controlled by your wallet, sitting on a public network anyone can inspect.

At first, though, it is still pretty bare.

A mint address is useful to a program but it does not mean much to a person. It is just a long base58 string. So the next step is metadata: a name, a symbol, and a URI that can point to richer details such as an image and traits.

That is when the token starts to feel less like a raw account and more like something you can work with.

This first arc of Epoch 2 also introduces a more important design choice: should this asset be transferable?

Not every asset should move freely. A certificate of completion, a verified badge, or a reputation score should belong to the person who earned it. In this arc, you will create a non-transferable token and try to send it to another wallet. And you'll see that the token program refuses the transfer because the rule is part of the asset.

Arc 6: Rules the network enforces for you

Arc 6 is where Token-2022 starts to matter.

You will create an interest-bearing token: a mint with an interest rate in its configuration. The raw balance does not change, but compatible wallets and clients can calculate a display amount that grows over time.

In a Web2 app, that kind of behavior might need timestamps, background jobs, database updates, and careful UI logic. With Token-2022, the rate is part of the token configuration, and compatible clients use it to calculate the displayed balance.

Token-2022 calls these optional features extensions. An extension is a built-in capability you add to a token: metadata, transfer fees, interest-bearing display amounts, frozen accounts, non-transferability, and so on.

In Arc 6, you start combining them.

A token might have metadata, a transfer fee, an interest rate, or other built-in rules. Some extensions can work together; others cannot. That means token design starts to feel a little like schema design: you need to decide what the asset should be able to do before you create it, because some choices are permanent and others are hard to change later.

The arc also introduces default frozen accounts. This means new token accounts start frozen and cannot be used until a freeze authority thaws them.

That gives you a simple version of a gated asset flow. Not every holder is automatically eligible. Someone has to approve the account before it can transact.

Finally, you will combine non-transferable tokens with permanent delegates to model a revocable credential. The holder cannot transfer it to someone else, but a designated authority can still burn it.

That gives you something close to: this credential can be issued and revoked, but it cannot be passed on.

You could model that in a database, but the rule would live inside your application. Here, the rule is part of how the asset works.

Arc 7: NFTs use the same building blocks

Arc 7 moves from fungible tokens into NFTs.

The useful surprise is that NFTs are not a completely separate technical world. At their simplest, they use the same basic ingredients you will have already covered up to that point: a mint, token accounts, metadata, and authority.

The difference is uniqueness.

A normal token is designed so many people can hold units of the same asset. An NFT is designed so there is only one of that asset. One token. One current owner. One piece of metadata that explains what it represents.

You will build the simplest version first: a unique asset on devnet that only your wallet owns. Then you will add the things people expect from an NFT: a name, an image URI, traits, and membership in a collection.

That is where metadata matters again. The NFT stops being just a unique on-chain asset and starts becoming something wallets, explorers, and other apps can present in a recognizable way.

The most satisfying moment in this arc comes when you update it.

You change the metadata on your live devnet NFT, then refresh a compatible wallet or explorer. The image changes. The name changes. The transaction has a signature anyone can audit, and the updated state is visible to compatible tools that read the standard.

You are not just editing a file or changing a row in your own database. You are changing asset state on a public network.

Arc 8: Assets that carry their own behavior

Arc 8 brings the whole epoch together.

You will create a fee-bearing token with a 1% transfer fee. Send 100 tokens to another wallet, and the recipient receives 99. The remaining 1 is withheld automatically according to the rules configured on the token.

That is the important part: your application did not calculate the fee, intercept the transfer, or run a background job. The token program enforced the rule.

Then you will run the rest of the lifecycle. You will inspect the withheld fees, harvest them from token accounts up to the mint, and withdraw them using the withdraw authority.

That gives you the full pattern: transfer, withhold, harvest, withdraw.

From there, the arc pulls together the ideas from the previous weeks. You will stack interest behavior on top of transfer fees. You will audit token mints to understand which rules are configured. You will revisit non-transferable tokens now that you have seen how fees, metadata, frozen accounts, and authorities all fit together.

By this point, Token-2022 should feel less like a list of features and more like a design toolkit.

The point is not that every token should use every extension. Most should not. The point is that you now have a vocabulary for asset behavior: fees, identity, display logic, access control, transfer restrictions, and revocation.

You can design those behaviors without writing a custom Solana program from scratch.

What you'll walk away with

By the end of Epoch 2, you’ll have a small portfolio of real Solana experiments on devnet.

Custom tokens with metadata. Transfer fees configured and inspected. Interest-bearing display amounts. Frozen accounts thawed by an authority. Non-transferable assets that refuse to move. A 1-of-1 NFT minted, added to a collection, updated, and verified on-chain. A fee-bearing token whose withheld fees you harvested and withdrew yourself.

You’ll also have written about what you built.

And that's because explaining a concept in your own words is one of the best ways to find out whether you actually understand it.

So, let's get into it!

Join us on the 100 Days of Solana journey.

Solana Writing Challenge: End of Epoch 1

Matthew Revell — Fri, 15 May 2026 09:45:48 +0000

If you’ve been taking part in 100 Days of Solana so far, you’ve probably discovered that Web3 isn’t as mysterious as it first appears.

And now it's your turn to help other web and mobile developers make the same realization.

To celebrate the end of Epoch 1, where we looked at Solana fundamentals, we're running a week-long 100 Days of Solana Writing Challenge. The focus is simple: write a DEV post that helps another developer understand, build, debug, or try something in Solana.

You don’t need to be an expert. You don’t need to write the definitive guide to anything. The best post might be a small explanation, a useful analogy, a bug you fixed, a project you built, or the moment a concept finally clicked.

What matters is that another developer can read it and come away thinking: “Okay, that makes more sense now.”

Prizes

And, of course, we have prizes.

We’ll award $500 prizes in three categories:

Most helpful post: for the post that does the best job of helping another developer understand, build, debug, or try something in Solana.
Most read, on-topic post: for the eligible post with the most reads during the challenge period.
Best posting streak: for the strongest set of four high-quality, helpful posts published during the challenge week.

We also have ten DEV++ subscriptions for notable submissions that stand out for clarity, originality, practical value, or community spirit.

To be eligible:

Your post must be published on DEV between 15 May and 22 May
Your post must include the 100daysofsolana tag
Your post must be relevant to Solana or your 100 Days of Solana learning journey
Your post must be written to help other developers, not just to announce participation
You must be registered for the 100 Days of Solana challenge

Use our template to get started!

Questions?

Have questions about the challenge or whether your post idea fits?

Ask in the 100 Days of Solana Discord channel. We’re happy to help you find an angle, shape an idea, or turn something you learned into a useful DEV post.

If you're having trouble joining the Discord, email us.

Arc 3 Catch-Up: Solana Transactions Explained for Web2 Developers

Matthew Revell — Mon, 11 May 2026 12:32:11 +0000

Arc 3 of 100 Days of Solana was the arc where Solana stopped being something we read from and started being something we wrote to.

Across the arc, we inspected transactions, sent SOL on devnet, built a transfer tool, tracked confirmation, and deliberately triggered failures. That shift changes how everything else fits together: accounts, programs, fees, confirmation, errors, and application state.

They all hang off one idea:

A Solana transaction is a signed request to change on-chain state.

Reading is pretty much like Web2. Writing is not.

Reading from Solana maps neatly onto things most Web2 developers already do. You ask for a balance. You fetch account data. You look up a transaction. The network answers.

Writing is different. It is closer to making a POST request that changes production data, except there is no single server receiving it.

In a Web2 app, a write usually follows a familiar path: take some input, check authorization, run logic, change state, return a result. Solana has the same broad shape, but the mechanics are different. To change state, you create a transaction: a signed, time-limited message that says which accounts are involved, which program should run, and what instruction that program should execute.

That is why a SOL transfer is such a useful first write. It is small enough to understand, but it contains the ingredients that keep showing up across Solana development: accounts, signatures, instructions, fees, confirmation, and failure modes.

Calling a program, minting a token, swapping an asset, or updating application state all build on the same foundation. The details change, but the shape remains familiar: prepare the instruction, sign the transaction, submit it to the network, and handle the result.

That was the real purpose of Arc 3: not just sending SOL, but learning Solana’s write path.

The HTTP analogy helps, until it doesn't

If you're coming from a Web2 background, the easiest on-ramp is to think of a Solana transaction as something like an HTTP request. At first, the comparison is useful. A transaction has structure, travels over the network, carries authorization, asks another system to do something, and produces a result you can inspect afterwards.

But it breaks down once you look closer.

An HTTP request is handled by an application server or backend service. A Solana transaction is validated by a network.

An HTTP request usually authenticates with a cookie, API key, or bearer token. A Solana transaction is signed with a cryptographic keypair before it leaves your machine.

And unlike a chain of separate API calls, a Solana transaction is atomic. If one instruction fails, the whole transaction fails. You do not get partial success where step two worked but step three did not.

There is also a freshness constraint. Every transaction includes a recent blockhash, which means it is only valid for a short window before the network refuses it.

So maybe it's better to think of it like this:

A Solana transaction is a signed message that says: “Run these instructions, against these accounts, before this short validity window closes.”

That makes it different from a normal API request. It is authorized before it is sent, it only works for a short window, and it succeeds or fails as one unit. On Solana, that short window is enforced with a recent blockhash, which stops old transactions from being replayed forever.

What's actually inside a transaction

Transactions can feel abstract because most of the time we only see the receipt: a signature, a success message, or an Explorer link.

But a transaction is not just a receipt. It is the actual message sent to the network.

If you have ever opened your browser’s network tab and inspected a request, the idea is similar. You stop seeing “the button worked” and start seeing the parts underneath: who sent the request, what data went with it, what endpoint it hit, and what the server returned.

Solana gives us the same kind of visibility. Using solana confirm -v and Solana Explorer, you can open up a transaction and see the main pieces:

Signatures: proof of who authorized the transaction.
Account keys: the accounts the transaction reads from or writes to.
Recent blockhash: the freshness check that helps stop old transactions being replayed.
Instructions: the operations the transaction asks a program to run.

The account list is not just a bag of addresses. Its ordering matters. The transaction header uses position to work out which accounts are signers, which are writable, and which are read-only.

You do not need to memorize the whole transaction format before building anything. The important thing is to see that a transaction is structured data, not magic.

It has authorization. It has inputs. It has instructions. It has constraints.

Once you have seen that structure once, a transaction stops feeling like a mysterious blockchain blob and starts looking more like something a developer can inspect, reason about, and debug.

Why a simple SOL transfer teaches so much

A SOL transfer is a good first write because it is small enough to follow, but complete enough to show the full pattern.

In Web2 terms, it is like starting with the simplest useful endpoint: POST /transfer. You are not building the whole application yet, but you are exercising the important pieces of a write path.

A single SOL transfer includes:

a fee payer, who pays for the transaction
a source account, where the SOL comes from
a recipient public key, where the SOL is going
an amount, measured in lamports
a System Program instruction, which performs the transfer
a signature, which authorizes it
an Explorer record, which proves what happened

That is a lot of Solana in one action. It shows accounts, signatures, instructions, fees, confirmation, and verification without needing to write a custom program first.

It also introduces an important idea for Arc 4: a public key can exist before there is an on-chain account for it. When SOL lands at a brand-new recipient, the System Program can create the account state the network will track from that point on.

That is the first hint that an “account” on Solana is not just another word for “wallet.” It is where state lives.

Wrapping a transfer in a tool

Running a transfer from the CLI proves the basic idea. Turning it into a tool makes the pattern reusable.

In Arc 3, that tool was a small Node.js command-line app built with @solana/kit, the newer Solana JavaScript SDK. You will still see plenty of tutorials using @solana/web3.js, so it is useful to know both names.

The tool did the same things a good wrapper around any important operation should do:

accept a recipient and amount
validate the input
check the sender’s balance
build and sign the transaction
submit it to devnet
print an Explorer link as a receipt

That shape should feel familiar. If you have ever wrapped a payment API, built an internal CLI, or added guardrails around a production write, you already know the pattern: validate, prepare, execute, return something the user can trust.

The difference is what sits underneath.

This tool was not sending a normal API request to one company’s backend. It was creating a signed transaction and submitting it to a decentralized network.

That was the practical bridge in Arc 3: moving from “I understand what a transaction is” to “I can build something that uses one.”

Confirmation is a product decision

One of the most useful realizations in Arc 3 was that “success” on Solana is not a single moment.

A transaction moves through commitment levels: processed, confirmed, and finalized. Each stage tells you something different about how far the transaction has moved through the network.

For developers, that is not just blockchain terminology. It affects the product experience.

If you are building a wallet, payment flow, marketplace, game, or developer tool, you have to decide what the user sees after they click the button.

Do you show “pending” as soon as the transaction is submitted? Do you show success once it is confirmed? Do you wait for finalization before enabling the next action? Do you include an Explorer link so the user can verify the result themselves?

A signature is a receipt, but not an explanation. Good tools show progress.

That is why the Arc 3 tool added confirmation feedback. It helped turn the gap between “sent” and “settled” into something visible, understandable, and useful.

Failed transactions are still real transactions

The most useful thing we did in Arc 3 was break things on purpose.

We tried sending from an empty wallet. We tried sending more SOL than the wallet held. We skipped preflight checks to push a doomed transaction onto the network anyway. Then we inspected what came back: CLI output, Explorer pages, logs, and transaction metadata.

The lesson is important for Web2 developers: on Solana, a failed transaction is still a real transaction attempt.

If signature verification succeeds, the transaction can still pay the base signature fee — 5,000 lamports per signature, before any optional priority fee — even if execution later fails. Validators still did work. The chain still attempted the change. The intended state change failed, but the fee was still real.

That reframes error handling.

You validate before signing. You simulate before submitting. You read structured errors like meta.err and InstructionError. You watch for blockhash expiry. You design flows that avoid wasting user fees on failures you could have caught earlier.

In Web2, error handling is mostly about user experience and reliability. On Solana, it is also part of the cost model.

What Arc 3 sets up

Strip Arc 3 back to its core and the main ideas are clear:

Transactions are how Solana changes state. They are signed before submission. They contain instructions. Those instructions act on accounts. Confirmation happens in stages. Failed transactions can still cost money.

That leads directly to the next question:

If transactions change state, where does that state live?

On Solana, the answer is accounts.

That is where Arc 4 goes next: how state is stored, who owns it, and how programs interact with it.

Use this post as the map, revisit the Arc 3 challenges whenever you want the hands-on version, and jump into Arc 4 from here.

Join us on the 100 Days of Solana journey!

Best AI Agent Frameworks for Production in 2026 (OpenClaw + Gemini)

Matthew Revell — Thu, 07 May 2026 12:18:03 +0000

TLDR

OpenClaw + an agent framework + Gemini is a practical default production architecture for long-context, tool-heavy agents.
Gemini 3.1 Pro is OpenClaw's recommended default model (google/gemini-3.1-pro-preview), mostly for its 1M token context window and native tool-use support.
LangChain/LangGraph is one of the most widely used combinations for Gemini + OpenClaw workflows in production.
Frameworks covered: LangChain, LangGraph, CrewAI, AutoGen, Google ADK, SmolAgents.

A code-review agent fetches a pull request, analyzes three files, flags an issue, then loops back to re-examine the diff. Somewhere between steps two and three, tool call history drops out of context. The agent hallucinates a fix or stalls. The reasoning step succeeded. The state didn't persist.

These failures are rarely dramatic. They show up as lost context, repeated tool calls, inconsistent state between steps.

OpenClaw runs execution and manages tool runtimes. Agent frameworks control orchestration and workflow logic. Gemini provides reasoning. The question is which framework connects those layers without introducing new points of failure. Other models like Claude and GPT-4 may outperform Gemini in raw reasoning depth or autonomous decision-making, but for OpenClaw's workload profile (large codebases, multi-step tool execution, long sessions), Gemini's 1M token context window means the model can often hold an entire agent session in memory without chunking tricks.

Recent Gemini API improvements preserve tool call history and responses across steps. That single change helps address a major source of agent failure in multi-step loops. This guide breaks down which frameworks fit which workflows, with Gemini as the LLM backbone and OpenClaw as the execution environment.

What Is an AI Agent Framework?

An agent framework is the software layer that orchestrates LLM calls, tool invocations, and memory management. It sits between the execution environment and the reasoning model, managing state, branching, retries, and multi-agent coordination.

Three trends define the 2026 landscape. First, Gemini API improvements have reduced tool call history loss in multi-step workflows, shifting some state management burden away from frameworks. Second, MCP and A2A protocols are gaining adoption, giving agents standardized ways to interoperate across frameworks. Third, LangSmith is now available on Google Cloud Marketplace, giving production teams observability tooling on the same cloud infrastructure where many Gemini workloads already run.

How to Choose: A Quick Decision Heuristic

Simple or single-task agents → SmolAgents, or skip the framework entirely
Fast role-based prototyping → CrewAI
Conversational multi-agent loops → AutoGen
Complex stateful or cyclical workflows → LangGraph
Google-native stack with first-party tooling → Google ADK
Production workflows needing governance and observability → LangChain

In practice, framework choice usually comes down to failure modes: use LangGraph when state consistency matters, CrewAI when speed of iteration matters, and AutoGen when behavior emerges from interaction rather than control flow.

A Concrete Example: Code-Review Agent with OpenClaw + LangGraph + Gemini

Consider a code-review agent that monitors a repository for new pull requests. OpenClaw runs the agent, manages tool access (GitHub API, linter, static analysis), and handles auth. LangGraph defines the workflow as a graph with nodes for fetching the PR diff, analyzing each changed file, flagging issues, and conditionally looping back if the analysis is incomplete.

Gemini 3.1 Pro powers reasoning at each node. Because OpenClaw workflows often involve large codebases and multi-step tool execution, Gemini's 1M token context window means the full diff, linter output, and prior analysis can stay in a single session without chunking or state rehydration. LangGraph's cycle support enables a human-in-the-loop checkpoint: a reviewer approves or rejects flagged issues before the agent posts comments.

When the agent encounters an ambiguous diff (a refactor that changes function signatures across multiple files, for example), LangGraph's cycle support means it can loop back to re-examine surrounding context rather than failing silently or hallucinating an interpretation. With LangSmith connected, each node's inputs, outputs, and latency are traceable. Debugging a misbehaving review step stays straightforward even when the graph has cycled multiple times.

You end up with a stateful, auditable agent that doesn't lose context between steps. The framework manages the graph. OpenClaw manages execution. Gemini powers reasoning.

The Best AI Agent Frameworks for OpenClaw in 2026

1. LangChain + LangGraph

Quick Overview

LangChain is commonly used in production setups for Gemini + OpenClaw workflows. The team updated their Google GenAI integration using Google's consolidated Generative AI SDK, accessible through the langchain-google-genai package and the ChatGoogleGenerativeAI class. LangGraph adds stateful, cyclical workflow graphs on top of LangChain's chain primitives.

LangSmith, LangChain's observability and tracing platform, became available on Google Cloud Marketplace in February 2026. Agent Builder templates launched in January 2026 with native support for Gemini models, lowering the barrier to production agent builds.

Best for: Production workflows requiring governance, audit logs, and complex state management with Gemini as the reasoning layer.

Pros:

Updated Gemini integration (langchain-google-genai) lets you use both Gemini API and Vertex AI through a single package, with createDeepAgent supporting google_genai:gemini-3-flash-preview as a model string
500+ integrations cover vector stores (Pinecone, FAISS), document loaders, and retrieval chains out of the box
LangSmith on Google Cloud Marketplace gives production teams observability without leaving their existing cloud infrastructure. LangSmith traces at the node level in LangGraph graphs, which matters when agents loop or branch unexpectedly and you need to pinpoint where behavior diverged.
Cycle and branch support in LangGraph means agents can loop, retry, and conditionally fork, not just execute linear DAGs
Apache-2.0 license with built-in audit log support makes LangChain viable for regulated environments

Cons:

Steeper learning curve than CrewAI or SmolAgents, particularly around LangGraph's graph-based mental model. The full stack has real setup overhead; teams new to graph-based workflows should expect several days before reaching productive iteration speed.
Verbose abstractions can slow early iteration when you're still validating whether the agent concept works at all. Swapping a single chain component triggered cascading type errors across three abstraction layers, turning a five-minute experiment into an hour of debugging imports.

Pricing: Open source (Apache-2.0). LangSmith has paid tiers for production tracing and observability.

Something to consider: Google Cloud's Vertex AI SDK "Generative AI module" is deprecated, with removal scheduled for June 24, 2026. If you're on the old SDK, migrate to langchain-google-genai before that deadline.

2. CrewAI

Quick Overview

If you need a working multi-agent prototype by end of day, CrewAI is probably where you start. Define agent "crews" with distinct roles (researcher, writer, coder), assign them tasks, and CrewAI handles delegation. Gemini integration works through langchain-google-genai or direct Gemini API calls. Version 0.5.2 is stable as of 2026 under the MIT license.

Best for: Fast prototyping of role-based agent teams with Gemini as the shared LLM backbone.

Pros:

A relatively small amount of code to define a working multi-agent crew. Genuinely the fastest path from idea to running prototype.
Lower cost-per-query than AutoGen according to some third-party benchmarks, though the gap varies by workload
Intuitive role abstraction maps well to OpenClaw's task model, where distinct tools and responsibilities already exist

Cons:

Fewer third-party integrations than LangChain (roughly an order of magnitude fewer), which limits extensibility for complex pipelines
No native RBAC and only basic streaming support, which matters once you move beyond prototyping into production with access control requirements
No built-in persistent memory store. Agents share context through task outputs passed sequentially. This works for short workflows but falls apart in long-running sessions where accumulated state matters.
Role-based abstraction complicates unit testing. CrewAI's role model is intuitive until you need to test a single agent's decisions in isolation. At that point, the crew's delegation logic becomes something you have to mock around, and the mocking gets ugly fast once you have three or more agents passing context.

Pricing: Open source (MIT).

3. Microsoft AutoGen

Quick Overview

Where most frameworks have you define explicit workflows, AutoGen takes a different approach: agents communicate through message passing, and complex behaviors emerge from dialogue patterns. Python and .NET are both supported. Version 0.4.5 is current, licensed under MIT.

Gemini integration is available via adapters or OpenAI-compatible layers in some setups, but Gemini is not a natively supported first-class model in AutoGen's SDK.

Best for: Conversational agent loops and research automation workflows where emergent multi-agent behavior is the goal.

Pros:

Emergent multi-agent behaviors arise naturally from AutoGen's conversational design, which suits exploratory and research-oriented workflows
Python and .NET dual support broadens team compatibility when not everyone writes Python
Active development community with strong representation in academic and research use cases

Cons:

Higher token usage per query than LangChain-based approaches, based on directional signals from third-party benchmarks. The conversational loop model also makes it harder to predict token costs at scale, since back-and-forth exchange counts vary per run. Budget for 2-3x your initial estimates.
2025 API shifts broke portions of legacy code, documented across GitHub issues, which creates real migration risk for existing projects. If you built on AutoGen before 0.4, expect to rewrite, not refactor.
Gemini requires adapter layers, adding a failure surface compared to frameworks with native Gemini API support. Adapter mismatches can silently drop tool call metadata, the kind of bug you don't catch until your agent starts repeating itself three steps into a loop.
Limited built-in observability. AutoGen lacks tracing comparable to LangSmith. Production debugging typically requires custom logging infrastructure, which adds engineering overhead that teams consistently underestimate.

Pricing: Open source (MIT).

4. Google ADK (Agent Development Kit)

Quick Overview

Google ADK is the only framework here that talks to the Gemini API without any adapter layer. It supports MCP and A2A protocols for agent interoperability, which can be useful if you're planning for multi-agent communication across framework boundaries. The framework is still emerging, though, with a smaller community than LangChain or CrewAI and fewer production deployments to learn from.

Best for: Developers building on a Google-native stack who want first-party tooling and protocol-level interoperability.

Pros:

Native Gemini API support eliminates the adapter layer entirely, reducing the number of things that can break between your code and the model
MCP/A2A protocol support enables cross-agent interoperability as these protocols gain adoption. Concretely, agents built with ADK can communicate with agents built on LangGraph, CrewAI, or custom setups, so you're not locked into a single framework as your system grows.
Roadmap alignment with Gemini means updates tend to track Gemini API releases closely

Cons:

Smaller community and documentation compared to LangChain or CrewAI. When you hit an edge case, you're often reading source code rather than Stack Overflow answers.
Fewer production examples in the wild make it harder to evaluate edge-case behavior before committing. Community-contributed integrations and battle-tested deployment patterns are still limited compared to LangChain's ecosystem of 500+ integrations or CrewAI's growing library of role templates. The documentation covers the happy path well but has less to say on error handling and retry semantics, which is exactly where you need guidance in production.

Pricing: Contact Google for enterprise pricing.

5. LangGraph (Without Full LangChain Stack)

Most of the orchestration power in the LangChain ecosystem comes from LangGraph, not LangChain itself. If you don't need chains, retrievers, or document loaders, LangGraph works as a standalone graph-based workflow engine with the same cycle support and state management, minus the overhead.

Best for: Complex workflows with branching, cycles, and human-in-the-loop checkpoints where full LangChain abstractions aren't needed.

Pros:

Fine-grained state control over agent transitions, letting you define exactly when and how agents loop, branch, or terminate
Cycle support means agents can revisit previous steps based on output evaluation, which linear DAG frameworks cannot do
Lower overhead than the full LangChain stack when your workflow doesn't involve chains or retrieval pipelines
Human-in-the-loop via checkpoints. LangGraph's checkpoint system lets you pause execution at any node for human review or approval before continuing. For regulated or high-stakes workflows (financial review, medical triage, legal document analysis), this is often a hard requirement rather than a nice-to-have.

Cons:

Still requires langchain-google-genai for Gemini access, so you're not fully decoupled from the LangChain ecosystem
Graph-based mental model has a genuine learning curve, particularly for developers accustomed to sequential pipelines. LangGraph's checkpoint system is useful for regulated workflows, but teams new to graph-based workflows may find the mental model challenging when they're coming from linear pipelines. Expect the first week to feel slower than it should.
No built-in tracing when used standalone. Without LangSmith, you need to wire up your own observability layer, which adds setup cost compared to the full LangChain + LangSmith stack.

Pricing: Open source (MIT).

6. SmolAgents (Hugging Face)

Quick Overview

SmolAgents exists for the cases where a full framework is overkill. It's a lightweight single-agent wrapper from Hugging Face, useful when OpenClaw already handles most orchestration and you just need a thin layer around Gemini for tool dispatch.

Best for: Contained, single-task agents where framework overhead isn't justified.

Pros:

Minimal setup with the fastest path to a running single agent of any framework listed here
Lightweight footprint keeps resource usage low relative to LangChain or AutoGen
MIT license with no commercial restrictions
Strong fit when OpenClaw already manages tool dispatch and execution. SmolAgents provides a thin orchestration wrapper without adding framework overhead. Well suited for contained tasks like summarization, classification, or single-file code review where multi-agent coordination isn't needed.

Cons:

Limited multi-agent support makes SmolAgents a poor fit once your workflow grows beyond a single agent
No stateful or cyclical workflows, which means any looping or branching logic falls back to your own code. The boundary between "SmolAgents is enough" and "I need a real framework" tends to arrive faster than expected. If you find yourself writing custom state management around SmolAgents, you've already outgrown it.

Pricing: Open source (MIT).

Summary Table

Framework	Pricing	Best For	Key Differentiator
LangChain/LangGraph	Open source (Apache-2.0)	Enterprise stateful workflows	500+ integrations, audit logs, updated Gemini integration (langchain-google-genai)
CrewAI	Open source (MIT)	Role-based prototyping	Fast path to a working crew, intuitive roles
AutoGen	Open source (MIT)	Conversational multi-agent	Python/.NET support, emergent behaviors
Google ADK	Contact Google	Google-native Gemini workflows	MCP/A2A protocols, first-party Gemini API support
LangGraph (standalone)	Open source (MIT)	Cyclical stateful graphs	Human-in-the-loop, fine-grained state control
SmolAgents	Open source (MIT)	Lightweight single-agent	Minimal overhead, fast deployment

If you're building long-context, tool-heavy agents with OpenClaw, Gemini is a strong default choice. Pair it with the framework that matches your workflow.

Why Gemini Is a Strong Fit for OpenClaw Agent Workflows

OpenClaw workflows can involve long sessions with large tool outputs (codebases, API responses, log files) and multi-step execution. Gemini 3.1 Pro's 1M token context window directly reduces the need to chunk inputs or rehydrate state between steps, one of the most common failure modes in production agents.

Recent Gemini API improvements preserve tool call history and responses across steps. Follow-up steps can reason over prior tool outputs without the framework needing to re-inject them. For execution-heavy workloads where agents routinely chain five or more tool calls per session, preserving that history matters more than incremental reasoning improvements.

Three additional features strengthen the fit. Native tool use with structured outputs gives clean function-calling semantics for agent workflows. Gemini API Grounding with Google Search provides web-connected agents without bolting on extra tooling. And google/gemini-3.1-pro-preview is OpenClaw's own recommended default, configured with a single command:

openclaw models set google/gemini-3.1-pro-preview

The [openclaw models set command](https://docs.openclaw.ai/concepts/model-providers) configures your default model provider across all sessions.

Auth setup is straightforward. Set GEMINI_API_KEY or GOOGLE_API_KEY as an environment variable, then run [openclaw onboard --auth-choice gemini-api-key](https://docs.openclaw.ai/get-started/install). No OAuth complexity required for the standard path.

If your workload is dominated by short, reasoning-heavy prompts with minimal tool use, other models may be a better fit. Use LangChain + GPT-4 or Claude and skip the context window optimization entirely.

How We Chose These Frameworks

Selection criteria were applied consistently across all six frameworks. Each criterion reflects a distinct dimension of production readiness for OpenClaw + Gemini workflows.

Gemini API compatibility was verified against official documentation and community reports for each framework. Frameworks with native Gemini support (LangChain, Google ADK) scored higher than those requiring adapter layers (AutoGen).

OpenClaw integration path was confirmed via OpenClaw's provider docs. We evaluated how cleanly each framework connects to OpenClaw's execution environment and agent runtime.

Learning curve was assessed by time-to-first-working-agent, not documentation quality. CrewAI and SmolAgents consistently require the least ramp time, while LangGraph's graph-based model takes several days to reach productive iteration.

Multi-agent support distinguishes frameworks with native multi-agent coordination (CrewAI, AutoGen) from those where multi-agent patterns are bolted on or absent (SmolAgents).

Observability was evaluated based on built-in tracing capabilities. LangChain/LangSmith provides the most complete solution out of the box. AutoGen and SmolAgents require custom logging infrastructure for comparable visibility.

Production readiness factors in community size, update cadence, and known breakage history. AutoGen shipped breaking changes in 2025 without a clear migration path, which weighs differently than LangChain's stable releases and active Google partnership.

License type (MIT vs. Apache-2.0 vs. proprietary) matters for enterprise adoption. Apache-2.0 (LangChain) includes patent grants that some legal teams prefer. MIT (CrewAI, AutoGen, SmolAgents, LangGraph) is more permissive. Google ADK requires contacting Google for enterprise terms.

Benchmark references are directional only, sourced from third-party comparisons (Sparkco.ai February 2026, GitHub Gist March 2026). We did not run controlled benchmarks for this guide, and methodology varies significantly across sources. Hard metrics (latency, memory footprint, uptime percentages) were omitted where primary sources were unavailable.

Community activity and 2026 update cadence were factored into each recommendation.

FAQs

What is an AI agent framework?

A software layer that orchestrates LLM calls, tool invocations, and memory management. It sits between the execution environment (OpenClaw) and the reasoning model (Gemini), handling state, branching logic, and multi-agent coordination.

How do I choose the right framework for OpenClaw?

Match the framework to your workflow complexity. CrewAI suits fast prototyping, LangGraph handles complex stateful workflows, and SmolAgents covers simple single-task agents. All frameworks listed here support the Gemini API, so the decision turns on orchestration needs and team experience rather than model compatibility.

Is LangChain better than CrewAI for OpenClaw?

LangChain is the stronger choice for production deployments requiring governance, audit trails, and complex state management. CrewAI wins on prototyping speed and simplicity for role-based agent teams. Both support Gemini. The choice depends on whether your priority is production hardening or iteration velocity.

How does agent orchestration relate to OpenClaw?

OpenClaw is the execution and tool runtime layer. Frameworks provide orchestration logic: how agents call tools, pass state, and coordinate. Gemini reasons at each step. The three layers work together, but they solve different problems. Without a framework, you're rebuilding state management, retries, and coordination yourself. Without OpenClaw, you're managing tool auth and sandboxing yourself.

If I'm already using OpenClaw with Gemini, do I need a framework?

For simple single-agent tasks, SmolAgents or no framework at all may be sufficient. Multi-agent or stateful workflows benefit significantly from LangGraph or CrewAI. Production deployments with governance requirements point toward LangChain.

How quickly can I get a working agent running?

CrewAI offers the fastest path to a working role-based prototype. LangChain and LangGraph require more setup time, which pays off at production scale. SmolAgents is the fastest option for single-agent tasks with minimal configuration. To get started with OpenClaw, setup takes a single command.

What's the difference between LangChain and LangGraph?

LangChain is a broad framework for LLM chains, tool integration, and retrieval. LangGraph is a graph-based extension (from the same team) for stateful, cyclical workflows. In the OpenClaw context, use LangGraph when your agents need to loop, branch conditionally, or include human-in-the-loop checkpoints.

What are the best alternatives to AutoGen for OpenClaw?

CrewAI offers lower overhead and faster prototyping with simpler Gemini integration. LangGraph provides more production stability without the legacy API breakage risk that has affected AutoGen. Google ADK gives native Gemini API support with first-party tooling, though its community is still smaller.

Best LLM for OpenClaw: Gemini 3.1 Pro vs GPT-5.5 vs Claude Opus 4.7 (2026)

Matthew Revell — Tue, 05 May 2026 11:59:31 +0000

That model picker in your OpenClaw config? It determines cost per completed job, how reliably your agent follows SOUL.md instructions, and whether a large PR diff fits in one pass or gets chunked into lossy fragments.

Three flagship models compete for the spot: Gemini 3.1 Pro, GPT-5.5, and Claude Opus 4.7. One model gets my default recommendation. The other two earn it for specific use cases.

TL;DR

Best default: Gemini 3.1 Pro. Fits the workload shape of most OpenClaw deployments: large-context code review, lowest cost per job, free dev tier, native multimodal.
Best for autonomous agents: GPT-5.5. Leads reported agentic benchmarks such as Terminal-Bench 2.0, if your context stays under 128K tokens per call.
Best for strict code review: Claude Opus 4.7. Leads reported SWE-bench Pro results (64.3% in Anthropic's evaluation), strong instruction adherence, often exhibits self-checking behavior in practice.

When Should You Choose Gemini 3.1 Pro?

Choose Gemini if your OpenClaw workflow involves:

Reviewing large PRs or monorepos
Combining SOUL.md, MEMORY.md, and code context in a single call
Working with CI/CD artifacts like screenshots or recordings
Iterating heavily on prompts during development

If your workload fits this pattern, Gemini is usually the most practical choice.

What OpenClaw Actually Demands from an LLM

A single OpenClaw task isn't a chatbot turn. It's a system prompt, plus SOUL.md content, plus MEMORY.md accumulated state, plus tool call payloads, plus multiple back-and-forth exchanges. In practice, OpenClaw tasks involve significantly higher token usage than typical chatbot interactions, due to accumulated context from SOUL.md, MEMORY.md, tool calls, and multi-step exchanges.

OpenClaw is a context-heavy system. The model is not just generating code; it is reasoning over accumulated state (SOUL.md, MEMORY.md, diffs, and tool outputs). That shifts the bottleneck from raw task performance to context handling and cost per call.

Reliable tool-calling degrades first when context fills up. Instruction adherence drops next, especially with layered SOUL.md rules. Context window behavior under load, whether the model actually reasons over tokens near the middle of a long input, determines whether single-pass analysis works or just looks like it works.

Two Workload Categories

OpenClaw deployments generally fall into two patterns:

Large-context analysis covers code review, diff reasoning, and repo-wide changes. These jobs load full PR diffs alongside SOUL.md, MEMORY.md, and surrounding file context into a single call. Token counts are high, and the ability to reason across the entire input in one pass matters more than raw task-completion speed.

Multi-step autonomous tasks involve planning, tool use, and execution loops. The model runs multiple shorter calls, each with moderate context, to complete a sequence of actions. Benchmark scores on agentic task completion are the best proxy for performance here.

Many OpenClaw workflows lean toward large-context analysis, particularly for code review and CI/CD automation. That workload pattern, not just price or benchmarks, should drive model selection. Gemini 3.1 Pro supports large-context workflows without requiring chunking in many cases. GPT-5.5 is built for the second category. Claude Opus 4.7 brings the highest coding-specific benchmark scores and strict instruction adherence across both.

The Three Contenders at a Glance

Gemini 3.1 Pro: 1M token context, $2/$12 per 1M tokens (standard context) (≤200K tokens; $4/1M above that threshold), free dev tier through Google AI Studio, natively multimodal across text, images, audio, and video.

GPT-5.5: 128K context on the standard API, $5/$30 per 1M tokens, the highest Terminal-Bench 2.0 score of the three at 82.7%.

Claude Opus 4.7: 1M context at flat pricing, $5/$25 per 1M tokens, leads reported SWE-bench Pro results (64.3% in Anthropic's evaluation).

Quick Reference Table

Dimension	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Context window	1M tokens	128K (standard API)	1M tokens
Input price ($/1M)	$2.00 (≤200K) / $4.00 (&amp;gt;200K)	$5.00	$5.00
Output price ($/1M)	$12.00	$30.00	$25.00
Free dev tier	✅ Google AI Studio	❌	❌
Terminal-Bench 2.0	68.5%	82.7%	69.4%
SWE-bench Pro	—	—	64.3%
Multimodal (audio/video)	✅ native	⚠️ limited	❌

Evaluation Criteria

Benchmark numbers are drawn from vendor announcements and should be interpreted accordingly. SWE-bench Pro scores come from Anthropic's Opus 4.7 announcement. Pricing is sourced from each provider's official API documentation.

Four dimensions, weighted for OpenClaw production use: context window capacity, cost per completed job, code review quality on benchmarks, and multimodal support for CI/CD workflows.

For OpenClaw workloads, context capacity and cost per job often matter more than raw benchmark scores.

Context Window

Gemini 3.1 Pro

Gemini 3.1 Pro offers a 1M token context window, one of the largest available at standard API pricing. For OpenClaw code review, that means single-pass ingestion of a full PR diff plus surrounding file context, SOUL.md, and MEMORY.md without splitting the input.

Single-pass analysis can capture cross-module relationships that chunked approaches miss. When a renamed interface in one file breaks three consumers in another, Gemini can process the full picture in one call. The tradeoff: requests exceeding 200K tokens are billed at $4.00/1M input instead of the standard $2.00.

Large-context models reduce the need for chunking, but can still struggle if prompts become too diffuse or contain conflicting instructions across files.

GPT-5.5

GPT-5.5's standard API context window is 128K tokens. Larger context tiers (such as 1M tokens) are not generally available on standard API access, which means it's not the default API experience most teams will use.

128K is not a soft limit you can occasionally brush against. A 200K-token PR diff plus SOUL.md plus task history fits in one Gemini call; it doesn't fit in GPT-5.5's standard tier at all. That forces chunked processing or context truncation, and for monorepo-scale OpenClaw workflows, chunking means the model never sees cross-file relationships in a single reasoning step.

Claude Opus 4.7

Claude Opus 4.7 provides a 1M token context window at flat pricing. A 900K-token request is billed at the same per-token rate as a 100K-token request, with no long-context surcharge.

For workloads that consistently exceed 200K tokens per call, Opus 4.7 has a pricing edge over Gemini's tiered model. If your typical OpenClaw job stays under 200K input tokens, Gemini's base rate ($2.00/1M) is cheaper by a wide margin.

Context Window Comparison

	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Max context	1M	128K (standard)	1M
Long-context premium	✅ above 200K	⚠️ 1M not generally available on standard API	❌ flat pricing
Monorepo-scale code review	✅	❌	✅

Cost Per Completed OpenClaw Job

Gemini 3.1 Pro is typically the cheapest at standard on-demand pricing.

Gemini 3.1 Pro

At $2.00 input / $12.00 output per 1M tokens, an illustrative 10-call code review run with roughly 500K input tokens and 50K output tokens comes to approximately $1.60.

The free dev tier through Google AI Studio is a genuine advantage during development. Iterating on SOUL.md prompts and agent configurations without paying per call removes friction that adds up fast when you're tuning agent behavior. Rate limits on the free tier will constrain sustained production use, but for development and testing, nothing else matches it.

Gemini also supports OpenAI-compatible interfaces via certain endpoints and adapters (including Google AI Studio), which means teams can switch from another provider without rewriting integration code. The migration cost is a config change, not an engineering project.

GPT-5.5

GPT-5.5 is the most expensive at standard rates: $5.00 input / $30.00 output per 1M tokens. For the same illustrative scenario, the 10-call code review run costs approximately $4.00, or 2.5x what Gemini charges.

OpenAI claims GPT-5.5 uses fewer tokens to complete equivalent Codex tasks compared to prior models. Token efficiency partially offsets the higher per-token price on agentic runs. Batch and Flex pricing at half the standard rate is available for workloads that tolerate asynchronous processing.

Claude Opus 4.7

Opus 4.7's headline price is $5.00 input / $25.00 output per 1M tokens. For the same illustrative scenario, the 10-call run costs approximately $3.75 before accounting for tokenizer overhead.

Effective cost can increase depending on tokenization and prompt structure. Prompt caching (up to 90% savings) and batch processing (50% savings) can offset the increase, but only if your workload structure supports them. If you're not caching repeated SOUL.md content across calls, you're leaving money on the table.

Cost Comparison Table

These estimates assume approximately 500K input and 50K output tokens across 10 calls; actual costs vary by workload.

	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Input ($/1M)	$2.00	$5.00	$5.00
Output ($/1M)	$12.00	$30.00	$25.00
Free dev tier	✅	❌	❌
Est. 10-call run (illustrative)	~$1.60	~$4.00	~$3.75+
Hidden cost risk	⚠️ extended context premium	✅ token efficiency claim	⚠️ possible tokenizer overhead

Code Review Quality

Gemini 3.1 Pro

68.5% on Terminal-Bench 2.0 and 67.3% on GDPval, the lowest of the three on both agentic benchmarks. On BrowseComp (web research capability), it scores a competitive 85.9%.

Gemini's value in OpenClaw code review comes from fitting the workload pattern rather than leading on isolated coding tasks. Being able to hold an entire codebase diff in one pass means the model reasons over relationships between files that a higher-scoring model working on chunked input may not see together.

GPT-5.5

GPT-5.5 leads Terminal-Bench 2.0 at 82.7% and GDPval at 84.9%. BrowseComp at 90.1% makes it the strongest option when web research is part of the agent loop.

On workloads that fit within 128K tokens, GPT-5.5 will complete agentic tasks more reliably than either competitor.

Claude Opus 4.7

Opus 4.7 leads reported SWE-bench Pro results (64.3% in Anthropic's evaluation), the benchmark most directly tied to coding-specific tasks. Terminal-Bench 2.0 at 69.4% puts it slightly ahead of Gemini.

Two qualitative traits stand out for OpenClaw use: Opus 4.7 often exhibits self-checking behavior in practice (catching its own logical faults during planning) and strict instruction adherence. For teams with complex SOUL.md configurations, Opus 4.7's precision in following multi-layered instructions reduces false positives in code review output.

Benchmark Summary

Benchmark	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Terminal-Bench 2.0	68.5%	82.7%	69.4%
GDPval	67.3%	84.9%	80.3%
SWE-bench Pro	—	—	64.3%
BrowseComp	85.9%	90.1%	79.3%

Multimodal Support for CI/CD Workflows

Gemini 3.1 Pro

Gemini 3.1 Pro natively processes text, images, audio, and video in a single API call. CI/CD build screenshots, architecture diagrams, and video recordings of failing test runs can all be included alongside code context.

No separate vision or audio model required. For teams whose OpenClaw workflows involve visual artifacts, Gemini handles the full spectrum without workarounds.

GPT-5.5

GPT-5.5 supports text, images, and audio. Video support is limited. Computer use and web search tools are available. The multimodal coverage is broad but stops short of Gemini's native four-modality input.

Claude Opus 4.7

Opus 4.7 handles text and images only, with improved resolution compared to Opus 4.6. CI/CD screenshots work well. Audio and video inputs are not supported. If your CI/CD pipeline produces screen recordings or audio logs, Opus 4.7 can't process them.

Multimodal Comparison

	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Images	✅	✅	✅ (improved res)
Audio	✅	✅	❌
Video	✅	⚠️ limited	❌
CI/CD screenshots	✅ native	✅	✅

Who Each Model Serves Best

Gemini 3.1 Pro: Best Default for Most OpenClaw Teams

Most OpenClaw code review workflows load more than 128K tokens per call. Gemini is built for that. A full PR diff, SOUL.md, MEMORY.md, and surrounding file context fit in a single 1M-token call without splitting or coordination logic.

1M context at $2/1M input for requests under 200K tokens, making it the cheapest large-context option for typical OpenClaw code review workloads
Free dev tier removes iteration cost when tuning SOUL.md and agent behavior, a workflow step every OpenClaw team repeats frequently
Native four-modality input covers CI/CD screenshots, audio logs, and video artifacts in a single call. No separate vision or audio model required.
Supports OpenAI-compatible interfaces via certain endpoints and adapters (including Google AI Studio), meaning switching from another provider is a config change, not a migration project
Single-pass monorepo analysis keeps full cross-file context intact in one call

Coding benchmark scores (68.5% Terminal-Bench, 67.3% GDPval) are the lowest of the three on isolated task precision. If your typical job consistently exceeds 200K input tokens, the $4/1M rate erodes the pricing advantage fast. And the free tier rate limits will not sustain production workloads, requiring a paid plan for anything beyond development and testing.

GPT-5.5: Best for Autonomous Multi-Step Workflows

82.7% on Terminal-Bench 2.0 is the strongest agentic score of the three by a wide margin. GPT-5.5's standard context window, however, is 128K tokens. Teams whose primary metric is agentic task completion rate, on workloads that fit within that limit, get the most reliable execution from GPT-5.5.

Token-efficient completions partially offset the higher per-token price, according to OpenAI's claims about reduced token usage per task.

A large PR diff combined with SOUL.md, MEMORY.md, and multi-turn task history will exceed 128K tokens in many monorepo workflows, forcing you to chunk inputs and lose cross-file context. And at an illustrative cost of ~$4.00 per 10-call run, GPT-5.5 is 2.5x the cost of the same workload on Gemini 3.1 Pro.

Claude Opus 4.7: Best for Code Review Precision

64.3% on SWE-bench Pro in Anthropic's evaluation is the highest coding-specific score of the three. For teams where a false positive in code review means a wasted engineering cycle, that number matters more than Terminal-Bench.

Opus 4.7 often exhibits self-checking behavior in practice, catching logical faults during planning and reducing false positive rates in code review output. Strict instruction adherence makes it the strongest option for teams with complex, multi-layered SOUL.md configurations.

The cost picture is more nuanced than the headline $5/$25 suggests. Effective cost can increase depending on tokenization and prompt structure. Prompt caching and batch processing can offset this, but only if your workload supports them. And no audio or video support limits usefulness for CI/CD workflows involving non-text, non-image artifacts.

Frequently Asked Questions

Which model has the largest context window for OpenClaw?

Gemini 3.1 Pro and Claude Opus 4.7 both support 1M tokens at the standard API level. GPT-5.5's standard API is 128K; larger context tiers (such as 1M tokens) are not generally available on standard API access. For monorepo code review, Gemini or Claude are the practical choices.

Does Gemini 3.1 Pro work with OpenClaw out of the box?

Yes. Google AI Studio provides an OpenAI-compatible endpoint that works with OpenClaw's provider configuration. The full setup walkthrough is in the Gemini + OpenClaw guide. The free dev tier is available immediately; rate limits apply on sustained production workloads.

Why is GPT-5.5 the best on benchmarks but not the top recommendation?

The Terminal-Bench 2.0 lead (82.7%) is legitimate, but GPT-5.5's standard context window is 128K tokens. Large OpenClaw workflows regularly exceed that limit. Combined with 2.5x the cost of Gemini at standard API rates, the benchmark advantage doesn't offset the practical constraints for most teams. The typical OpenClaw workload is large-context code review, and GPT-5.5's standard tier doesn't fit that pattern.

Is Claude Opus 4.7 actually more expensive than the headline price suggests?

Effective cost can increase depending on tokenization and prompt structure. The $5/$25 headline price is unchanged, but the same input text may consume more tokens. Prompt caching (up to 90% savings) offsets the increase for repeated content like SOUL.md.

Can I switch models mid-project in OpenClaw?

Yes. OpenClaw supports any OpenAI-compatible endpoint, so the model is a config-level change. SOUL.md and MEMORY.md files are model-agnostic, though agent behavior may vary between models due to differences in instruction interpretation.

Which model handles CI/CD screenshot analysis best?

Gemini 3.1 Pro processes images, audio, and video natively. Claude Opus 4.7 supports images with improved resolution over its predecessor. GPT-5.5 supports images and audio; video support is limited.

Why does context size matter so much for OpenClaw?

Because OpenClaw tasks combine multiple sources of context (SOUL.md, MEMORY.md, code diffs, and tool outputs) into a single reasoning step. If that context exceeds the model's limit, it must be split across multiple calls, which adds complexity and can reduce reasoning quality across the full diff.

Where This Recommendation Breaks Down

Gemini 3.1 Pro is not a universal default.

If your OpenClaw workflow depends on tight iterative loops with smaller contexts, or if instruction-following precision is the primary constraint, GPT-5.5 or Claude Opus 4.7 may perform better despite higher cost or smaller context windows.

Final Verdict

Why Gemini 3.1 Pro Is the Default Choice

Gemini 3.1 Pro matches how most OpenClaw teams actually work: loading 200K+ token PR diffs alongside SOUL.md, MEMORY.md, and surrounding file context into a single call, then running multi-step reviews without splitting inputs.

Large-context workflows without chunking. 1M tokens covers full PR diffs, SOUL.md, MEMORY.md, and surrounding file context in a single pass.
No need to split inputs, coordinate multiple calls, or merge partial reasoning across chunks. Simpler agent architecture, fewer failure modes.
Lowest cost per completed job. For an illustrative scenario, ~$1.60 per 10-call run vs ~$4.00 for GPT-5.5.
Free iteration tier during SOUL.md development. Google AI Studio's free tier removes per-call cost from the prompt tuning cycle.
Native multimodal for CI/CD pipelines. Images, audio, and video in one API call. No separate vision or audio model required.
Config-level migration via OpenAI-compatible interfaces. No integration rewrite required.

Summary Table

Dimension	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Context window	✅ 1M tokens	⚠️ 128K standard	✅ 1M tokens
Cost per job (illustrative)	✅ lowest (~$1.60)	❌ highest (~$4.00)	⚠️ mid (~$3.75+)
Agentic task completion	⚠️ 68.5% Terminal-Bench	✅ 82.7% Terminal-Bench	⚠️ 69.4% Terminal-Bench
Code review precision	⚠️ no SWE-bench data	⚠️ no SWE-bench data	✅ 64.3% SWE-bench Pro
Multimodal (audio/video)	✅ native	⚠️ limited	❌
Free dev tier	✅	❌	❌
Long-context flat pricing	⚠️ premium above 200K	❌	✅

Gemini 3.1 Pro Is the Right Default

Most OpenClaw teams are running code review on repositories that exceed 128K tokens. That single fact eliminates GPT-5.5's standard tier from consideration for the majority of production workloads. Between the two 1M-context options, Gemini's cost advantage is substantial: for an illustrative scenario, roughly $1.60 per 10-call run compared to $3.75+ for Opus 4.7.

The free dev tier removes friction during the SOUL.md iteration cycle that every OpenClaw team goes through repeatedly. Native multimodal support covers CI/CD screenshots and video artifacts without extra configuration or separate model calls. And Gemini supports OpenAI-compatible interfaces via certain endpoints and adapters (including Google AI Studio), meaning zero migration effort if you're switching from another provider.

Gemini 3.1 Pro wins on the combination of workload fit, cost, multimodal coverage, and developer experience. At scale, the $2.40 per-job savings over Opus 4.7 (and $2.40 more over GPT-5.5) compounds into the difference between a sustainable deployment and one that gets cut in a budget review.

When to Choose GPT-5.5 Instead

Your workflow is primarily autonomous multi-step task completion rather than large-context code analysis. Context stays within 128K tokens per call. Your team is already invested in the OpenAI Agents SDK ecosystem and the switching cost outweighs the per-token savings.

When to Choose Claude Opus 4.7 Instead

Code review false positive rate is your primary production concern. Your SOUL.md configurations are complex enough that strict instruction adherence is a requirement, not a nice-to-have. You have prompt caching in place to offset Opus 4.7's higher effective cost.

Using Gemini with OpenClaw: Setup Guide + Real Use Cases

Matthew Revell — Fri, 01 May 2026 09:49:58 +0000

OpenClaw supports a wide range of LLM providers, and choosing the right one shapes how your agents perform on real work. Gemini 3.1 Pro has become a compelling option for teams running developer automation, particularly when workflows involve large codebases, multimodal artifacts, or high-frequency agent calls.

The combination of a large context window, native support for images, audio, and video, and a free development tier through Google AI Studio makes Gemini worth serious consideration as your OpenClaw LLM backend.

This guide walks through the full setup, three practical use cases, and an honest comparison against GPT-5.5 and Claude Opus 4.7 in the same OpenClaw environment.

Why Gemini Works Well as an OpenClaw LLM Backend

Three characteristics make Gemini a strong fit for agentic developer workflows: context capacity, cost structure, and multimodal input.

Large Context Window

Gemini 3.1 Pro supports a large context window, which changes how OpenClaw agents can approach code review and repository-level tasks. Instead of chunking a PR diff into multiple calls and losing cross-file relationships, an agent can ingest the full diff plus surrounding file context in a single pass. For monorepos or PRs that touch dozens of files, the difference between single-pass and chunked analysis is the difference between catching a subtle cross-module bug and missing it entirely.

All three major models (Gemini, GPT-5.5, Claude Opus 4.7) support large context windows, though exact limits and effective usage can vary by tier and endpoint. Gemini's context capacity is among the largest available, which gives it a practical edge for repository-scale analysis.

Cost for High-Frequency Agentic Calls

Agentic workflows are expensive by nature. A single OpenClaw code review run might make ten or more API calls as the agent reasons through a diff, checks style guides, and drafts comments. Gemini 3.1 Pro includes a free development tier through Google AI Studio, which lets you iterate on agent prompts without paying per call during development. That free tier has rate limits that can be exhausted quickly, sometimes within minutes on real agent workloads. For sustained production use, a paid plan is likely necessary; check ai.google.dev/gemini-api/docs/pricing for current details.

Multimodal Input Support

Gemini processes images, audio, and video natively. For CI/CD workflows, an OpenClaw agent can parse a failing build's screenshot artifact or a visual regression diff without requiring a separate OCR pipeline or explicit image-to-text preprocessing. Text-only models typically require external tooling for that.

Setting Up Gemini as Your OpenClaw LLM Backend

The setup takes about five minutes. Google (Gemini) is a built-in provider in OpenClaw's model catalog, so there's no custom provider configuration required.

Step 1: Get Your Gemini API Key

Go to Google AI Studio and generate an API key. The free tier works for development and prompt iteration. You do not need a Google Cloud project for this; AI Studio handles key provisioning directly.

A note on OAuth: some guides mention a Gemini CLI OAuth flow for OpenClaw. The OAuth integration is unofficial and unsupported by Google. Avoid it for any serious use. Stick with the API key method.

Step 2: Set the Environment Variable

Add your API key to your shell environment or .env file:

export GEMINI_API_KEY=<your_key>

OpenClaw reads this variable at startup. If you're running OpenClaw on a VPS or in CI, set it in your deployment config or secrets manager rather than hardcoding it.

Step 3: Select Gemini via the OpenClaw CLI

You have two options. The interactive onboarding flow:

openclaw agent --onboard

Select "Google (Gemini)" when prompted for your provider.

Or set the model directly:

openclaw models set google/gemini-3.1-pro

Both approaches write the same configuration. The direct method is faster if you already know which model you want.

Step 4: Verify the Configuration

Confirm everything is wired up:

openclaw models status --json --agent

You should see output like:

{
  "agents": {
    "defaults": {
      "models": ["google/gemini-3.1-pro"],
      "active": "google/gemini-3.1-pro"
    }
  },
  "status": "ok"
}

If the active field shows your selected model, you're ready.

Choosing a Model: gemini-3.1-pro vs gemini-3.1-pro-preview

Use google/gemini-3.1-pro for stable production workloads. The behavior is consistent between updates, and you won't encounter unexpected changes in reasoning patterns mid-sprint.

google/gemini-3.1-pro-preview gives you access to the latest capabilities and was added in OpenClaw 2026.2.21. Preview variants are useful for evaluating new reasoning improvements, but their behavior may shift between updates. Pin to the stable ref for anything running unattended.

Troubleshooting

OpenClaw rejects your model selection. If you get a model-not-found error, confirm you're on OpenClaw 2026.2.21 or later. Older versions don't include the Gemini 3.1 model refs. Update OpenClaw and try again.

API key errors after setup. Double-check that GEMINI_API_KEY is exported in the same shell session where OpenClaw runs. A common mistake: setting it in .bashrc but running OpenClaw from a different shell profile.

Rate limit errors on the free tier. The free tier's rate limits can be exhausted quickly, sometimes within minutes on real agent workloads. If you're hitting 429 errors consistently, you need the paid tier. As a quick fallback, you can also switch to google/gemini-2.5-flash for a lighter-weight model that consumes less quota per call.

3 Real Use Cases with Gemini + OpenClaw

Use Case 1: Automated Code Review

An OpenClaw agent configured with Gemini 3.1 Pro can review a full PR diff plus the surrounding file context in a single call. The agent flags style violations, potential security issues, and logic errors, then posts inline comments on the PR.

The large context window is what makes single-pass review practical. Rather than splitting a 40-file PR into batches (and losing the ability to reason across files), the agent sees everything at once. Cross-file dependency issues, like a renamed function that's still referenced elsewhere, surface naturally. Gemini often works without requiring heavy prompt engineering for this type of structured analysis task.

Use Case 2: PR Summarization for Engineering Teams

For teams drowning in PR notifications, an OpenClaw agent can generate structured summaries: what changed, why it changed, and a risk-level assessment. These summaries get posted automatically to Slack channels or GitHub PR comments.

The practical value is triage speed. A tech lead scanning 15 PRs before standup can read summaries instead of diffs, focusing review time on the high-risk changes. Gemini's ability to process large diffs in one pass means the summary reflects the full scope of the change, not a truncated view.

Use Case 3: CI/CD Workflow Automation

When a build breaks, an OpenClaw agent can monitor the failure, parse log output, examine visual artifacts (screenshots from e2e test failures, for instance), and draft fix suggestions or open issues automatically.

Gemini's multimodal input is the differentiator here. A failing Playwright test that produces a screenshot comparison can be fed directly to the agent alongside the error log. The agent sees both the visual regression and the stack trace in the same context. Text-only models typically require external tooling for that kind of combined analysis.

Gemini vs GPT-5.5 vs Claude Opus 4.7 in OpenClaw: Quick Comparison

All three are first-class providers in OpenClaw. The right choice depends on your workflow shape.

	Gemini 3.1 Pro	GPT-5.5	Claude Opus 4.7
Context window	Large	Large	Large
Multimodal input	Image, audio, video	Image only	Image only
Tool use & reasoning	Emphasizes tool use and multi-step reasoning	Strong agentic coding per published benchmarks	Strong instruction-following
Cost considerations	Includes free dev tier via Google AI Studio	No free tier	No free tier
Typical use cases	Multimodal CI/CD and agent iteration	General-purpose agents and coding tasks	Precise structured code generation

All three models support large context windows, though exact limits and effective usage can vary by tier and endpoint.

Gemini 3.1 Pro

Best for: Solo developers, hobbyists, and teams working with large PRs or monorepos, CI/CD workflows that include visual artifacts, and anyone running frequent agent loops or iterating on prompts where development-time cost matters.

Pros:

Free development and testing tier via Google AI Studio means you can iterate on agent prompts without paying per call during development. Useful when you're tuning OpenClaw agent behavior across multiple workflows and running dozens of test invocations per session (note: Gemini 3.1 Pro access at higher usage levels may require a paid plan; see ai.google.dev/gemini-api/docs/pricing)
Native multimodal input handles screenshots, diagrams, audio, video, and mixed-format build artifacts directly.

Considerations:

Preview variants introduce the latest reasoning improvements but may behave differently between updates. Use the stable google/gemini-3.1-pro ref for production workloads.
Google AI Studio's free tier is well-suited for development and prompt iteration. For sustained agent workloads, a paid plan gives you the headroom to run without interruption.

GPT-5.5

Best for: General-purpose agent workflows and coding tasks.

Pros:

Strong agentic coding performance per OpenAI's published benchmarks. Per Terminal-Bench 2.0, GPT-5.5 shows strong performance on agentic coding tasks, though results vary by workload and evaluation method.
Broad tool-calling support with a well-established function-calling API that many existing integrations are built against.

Cons:

No free tier for API access. Every call during development and testing costs money.
Image-only multimodal input. No native support for audio or video, which limits CI/CD use cases involving visual or media artifacts.

Claude Opus 4.7

Best for: Precise structured code generation and tasks requiring strict instruction adherence.

Pros:

Strong instruction-following makes Claude Opus 4.7 a good fit when your OpenClaw agent prompts require exact output formatting or rigid schema compliance. Claude's model documentation positions the Opus line for high-precision tasks.
Reliable structured output for code generation workflows where the agent needs to produce syntactically valid, well-formatted code consistently.

Cons:

No free tier for API access, which raises the cost of iterating on agent prompts during development.
Image-only multimodal input. Like GPT-5.5, Claude Opus 4.7 does not natively accept audio or video.

Frequently Asked Questions

Does OpenClaw support Gemini natively?

Yes. Google (Gemini) is a built-in provider in OpenClaw's model catalog. No custom provider configuration is needed. Gemini 3.1 model refs were added in the OpenClaw 2026.2.21 release.

Which Gemini model should I use with OpenClaw?

Use google/gemini-3.1-pro for stable production workloads. Use google/gemini-3.1-pro-preview if you want to test the latest reasoning improvements, but be aware that preview behavior may change between updates.

Is Gemini free to use with OpenClaw?

Google AI Studio provides a free tier that works well for development and prompt iteration. The free tier's rate limits can be exhausted quickly, sometimes within minutes on real agent workloads. Higher usage levels may require a paid plan. Check ai.google.dev/gemini-api/docs/pricing for current limits and pricing.

How do I set the Gemini API key for OpenClaw?

Generate an API key at aistudio.google.com, then set export GEMINI_API_KEY=<your_key> in your shell or .env file before starting OpenClaw. Do not use the unofficial OAuth method.

Can I use Gemini for CI/CD automation in OpenClaw?

Yes, and Gemini's multimodal input gives it an advantage here. An OpenClaw agent backed by Gemini can parse build logs alongside visual artifacts (screenshots, image diffs) without requiring a separate OCR pipeline or explicit image-to-text preprocessing in many cases.

How does Gemini compare to GPT-5.5 and Claude Opus 4.7 in OpenClaw?

Gemini 3.1 Pro's model capabilities emphasize tool use and multi-step reasoning, and it's the only one of the three that accepts audio and video input natively. GPT-5.5 shows strong agentic coding performance per published benchmarks. Claude Opus 4.7 leads on precise instruction-following. All three support large context windows, though exact limits and effective usage can vary by tier and endpoint.

What should I do if OpenClaw rejects my Gemini model selection?

Confirm you're running OpenClaw 2026.2.21 or later. The Gemini 3.1 model refs were added in that release. If you're on an older version, update OpenClaw and retry openclaw models set google/gemini-3.1-pro.

Conclusion

Gemini 3.1 Pro is the strongest default for OpenClaw teams running workflows against large codebases, processing multimodal CI/CD artifacts, or iterating rapidly on agent prompts without wanting to pay for every test call. If your daily work involves reviewing PRs that span dozens of files, parsing build failures that include screenshots, or running high-frequency agent loops during development, Gemini is where you should start.

For teams doing precise structured code generation with strict output formatting, Claude Opus 4.7 is worth evaluating. For general-purpose agent tasks with heavy function-calling, GPT-5.5 remains a solid choice. But for the combination of context capacity, multimodal input, and accessible pricing during development, Gemini paired with OpenClaw covers the most ground for developer automation workflows.

AMA with Solana's Brianna Migliaccio

Matthew Revell — Wed, 29 Apr 2026 13:44:10 +0000

If you're new to Solana—or Web3 and blockchain more broadly—you almost certainly have questions.

That’s expected.

Web3 works under different assumptions to traditional web and mobile development.

Plus, there’s a whole new set of concepts and terminology to get familiar with.

So let’s make that easier.

Join us live

📺 https://twitch.tv/mlh

🗓 Wednesday, April 29

🕛 12:00 Eastern / 17:00 UK / 21:30 India

Come ready with your questions.

And if you can’t make it, we’ll share the highlights here on DEV.

Want to learn more about Solana? Join the 100 Days of Solana challenge >

Web3 Terminology Mapped to What You Already Know

Matthew Revell — Mon, 20 Apr 2026 17:10:05 +0000

Web3 can seem intimidating at first. And a lot of that is to do with terminology.

But once you make the connection between what you already know from web and mobile dev, for example, everything becomes a little clearer.

Here are some common Web3 terms and concepts translated into their Web2 equivalents to help you make the move.

100 Days of Solana

Want to learn Web3? Join 100 Days of Solana for free to go from curiosity to building!

Web3 Fundamentals

Let's start with the basics.

Why is it called Web3?

The idea is that this is third phase of the web.

Web 1 was the original, read-only world wide web of the 90s.
Web 2 made things two-way, so the web became participatory.
Web 3 uses blockchain technologies to make you the owner of your data, rather than the companies running websites and apps you use.

It can take a while to realize why that's important and what it means. Seeing it in action makes all the difference.

Web3 Core Pillars

To understand how this actually works, you only need to know three things:

The Blockchain: A public ledger (think of it like a very distributed database) that lives on thousands of computers at once. It’s "permissionless", meaning no one can block you from using it.
The Wallet: Your digital identity. Instead of an email and password, you use a private key stored in your wallet to prove you own your assets.
Smart Contracts: Pieces of code that live on the blockchain. They execute automatically when certain conditions are met.

But there are plenty more ideas and phrases that you'll need to get used to in order to feel fully comfortable in the Web3 world.

Making Sense of the Rest

Now that you understand the three core pieces — blockchain, wallet, and smart contracts — everything else in Web3 is really just combinations of those ideas.

The terminology can still feel unfamiliar, though. So let’s map the most common terms to things you already use as a developer.

Identity: Wallets Replace Accounts

You already know that in Web2:

users sign up
you store their credentials
you authenticate requests

In Web3, your wallet replaces all of that.

Web3	How to think about it
Wallet	Your account (but you control it, not a platform)
Public Key	Your user ID or username
Private Key	Your cryptographic identity — used to prove ownership and sign actions
Signing	Logging in / proving who you are

The key difference is simple but important:

Instead of logging in to a server, you prove who you are by signing requests with your private key.

Data: The Blockchain Is the Database

You already understand databases, APIs, and writes.

The blockchain is just a very different kind of database.

Web3	How to think about it
Blockchain	A shared, append-only database
Transaction	A write operation
Node	A server running the database
Gas / Fees	Paying for compute or writes, just like paying for API calls or cloud compute

What changes here isn’t what you’re doing but, instead, the constraints:

writes are public
writes are permanent
writes cost money

That can make you think much more carefully about what you store and when.

Logic: Smart Contracts Are Your Backend

You already write backend code that:

processes requests
enforces rules
updates data

Smart contracts do the same thing.

Web3	How to think about it
Smart Contract	Backend logic
Program (on Solana)	A deployed service
Calling a contract	Making an API request

The important shift:

You don’t control the runtime once it’s deployed.

Value: Ownership Is Built In

In Web2, ownership is just a database entry you or someone else controls.

In Web3, it’s enforced by the system itself.

Web3	How to think about it
Token	Money or API credits that aren’t tied to a single service (like Stripe balance, but portable and user-owned)
NFT	Like owning a domain name, it's a unique asset with verifiable ownership (and not just a picture of an ape)
Wallet balance	Your bank balance but without a bank controlling it

The difference:

In Web2, ownership is just a row in someone's database. In Web3, it’s enforced by the network and you can’t change it manually.

Apps: Same Shape, Different Backend

At a high level, Web3 apps still look familiar.

Web3	How to think about it
dApp	A web app
RPC endpoint	Your backend API
Explorer	A read-only database viewer
Mainnet / Devnet	Production / staging

The frontend is still yours.

The backend is now a public network.

What Actually Changes

If this all feels surprisingly familiar, that’s the point.

Much of Web3 isn't a completely new model, instead it's a new way of thinking about things you already know well. The core differences are:

You control identity (wallets instead of accounts)
You pay for writes (like calls to a paid API)
You deploy immutable logic (contracts instead of editable app code)
You rely on shared infrastructure (networks instead of owned backends)

That’s it.

The Only Way This Really Clicks

Reading helps. But it won’t fully land until you try it.

The moment you:

generate a keypair
send a transaction
see it appear on-chain

…all of this terminology stops feeling abstract.

And we're here to help with that. 100 Days of Solana is a hands-on daily coding challenge that takes you from no Web3 experience to able to build with Solana. Join free!

100 Daily Challenges to Learn Web3 and Solana

Matthew Revell — Fri, 17 Apr 2026 15:14:12 +0000

Web3 is different. But it doesn't have to be hard.

Most of what you do in a Web3 ecosystem, like Solana, maps directly to things you already understand from building web and mobile apps. You just need to learn some new terminology and assumptions first.

That's why we're launching 100 Days of Solana! It's a free, daily programming challenge that will take you from Web3 curiosity to creating your own projects with Solana.

TL;DR

Here's the short version of everything you need to know:

Start date: April 20th but you can join any time.
What you’ll learn: How Solana works in practice, including transactions, accounts, programs, and how to build real apps on top.
How it works: One focused challenge per day (~30–60 mins), each building on the last.

One Theme Each Week

We’ve structured 100 Days of Solana into Arcs (weekly themes) and Epochs (bigger milestones).

Each Arc runs Monday to Sunday and focuses on one topic, starting with Identity and Your First Wallet.

If you're busy one week, you can cover just the basics on Monday and Tuesday. But to make the most of the event, it’s worth aiming for all seven days.

Big Stories

Each set of Arcs builds into a larger milestone that we’re calling Epochs.

Those Epochs take you from understanding how data works on Solana to building and shipping your own applications:

Reading and Writing Data
Owning and Moving Data
Building Programs, Making Contracts
Shipping and Exploring

By the end, you'll have learned what you can build with Solana, why you'd choose Solana, and how to put all the pieces together.

A Community

You won’t be doing this alone.

When you register, you’ll join the 100 Days of Solana Discord, where you can:

Ask questions and get help from the event team
Share your progress
Connect with other developers working through the same challenges

We’ll also run live AMAs, publish blog posts here on DEV, and more.

There’ll be opportunities to win prizes, get your work showcased, and even take part in MLH’s Solana Fellowship.

Why Solana?

We’re using Solana for this program because it works well for learning by building.

Transactions are fast and inexpensive, so you can try things out, make mistakes, and see what happens without waiting around or worrying about cost.

It’s also one of the platforms we see used most often at MLH hackathons. Developers pick it because they can actually build and ship something in a short amount of time.

That makes it a good place to go from “I kind of get this” to actually putting something together yourself.

Get signed-up

[Boost]

Matthew Revell — Wed, 18 Feb 2026 14:35:34 +0000

Jon Gottfried for Major League Hacking (MLH)

Feb 18

The Future of Software Has a Lot More Builders. They’re Going to Need a Home.

#discuss #news #ai #programming

Comments 19

4 min read