Forem: Matthew Revell

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

Tales of regret from developer onboarding

Matthew Revell — Tue, 01 Feb 2022 14:01:00 +0000

Whether you're just starting out as a developer or you've got years under your belt, learning a new codebase is a defining experience.

Onboarding shapes not only your enjoyment of that project but can influence what sort of work you go on to do next. Either you're running screaming in the opposite direction, or you've found something you want to do again.

For every codebase onboarding that feels like an effortless walk in a sunny meadow, there are plenty more that evoke a 3am hike up an unlit rocky path during a hurricane.

Below is an inexhaustive collection of postcard-sized onboarding stories from real developers. They illustrate some of the specific ways in which onboarding can go wrong, and, at the end, there's a hint at one way we might make it better for the developers who come after us. Names have been changed.

I've suffered, so shall you

If a problem shared really is a problem halved, then perhaps that explains what happened to Mark.

The first day on the job, the incumbent developer asked a question, "How do you feel about spaghetti code?" Not leaving any time to answer, he followed up with, "Because what we have here is code soup."

The product should have been straightforward. It was a web front end to research data held in a PostgreSQL database. However, Mark was the fourth developer to work on the system in a short period of time. It was almost as though each prior developer had gone out of their way to avoid any consistency with their predecessor. Instead, they picked the tools and conventions they preferred. That led to fun situations such as Hibernate taking care of user and project records, while JDBC was used for general querying. As Mark says, "Why have one data abstraction layer when you can have two?"

Sure, the codebase itself was a mess, but the onboarding was essentially a surrender. "I know this is terrible, but I've suffered, so that means you should too," probably isn't the ideal onboarding maxim.

Mismatched expectations

Starting a new job is somewhat stressful, even in ideal circumstances. There's the pressure to show your best in those 30-60-90 reviews and to win round your new colleagues.

But for Gavin, a Python developer, starting one job, in particular, was especially fraught. "They knew I wasn't a Ruby developer but somehow also expected that I did know Ruby."

On top of learning the new codebase, Gavin also had to learn a new language. Not an impossible task but also one that no one at the company had made allowances for. "They pointed me at rubykoans.com and wished me well. The Koans are good, but they don't cover de facto essential stuff like Rails," Gavin said. After years in the Python ecosystem, he also found that the difference in approach between Python and Ruby docs took some getting used to.

For Gavin, it was the shock of the mismatched expectations, combined with his own desire to show his best work, that made this particular onboarding hard. "One person's experience of learning new tech can be worlds apart from your own: I was joining a company of Ruby enthusiasts who probably found it hard to put themselves into my shoes. I had 20 other things competing for my time and attention, as well as that huge pressure to be productive. Having to also learn Ruby, Rails, and the special way in which Rails was used at that company, before being able to be productive was very stressful. I came close to quitting or being fired."

Why can't you just understand?!

There are situations where a problem space is just plain hard. Some things take time to understand fully. But other times, it's not the problem that's hard to understand, it's more that the person getting you up to speed lacks the necessary empathy.

One developer, Gráinne, found that the person onboarding her was perhaps too close to the code to see it from a newcomer's point of view.

"On my first day, I showed up, got access to the code, and then had a two-hour sit down with the CTO. He was also the architect of the product and the lead developer. The trouble was that he talked very fast and got quite exasperated when you didn't immediately understand what he was saying."

For Gráinne that meant making whatever notes she could during the onboarding/interrogation and then trying to fill in the gaps by reading the code.

But even past the onboarding itself, a Monday morning could put things back to square one, "The CTO would often, over a weekend, massively change huge chunks of the code, breaking things in horrible ways, and then would shout about it until we fixed the mess."

We are unreliable narrators

Perhaps there's a theme that unites all of these stories: bad developer onboarding happens when there's no process or a process that fails to take account of people's different expectations and approaches.

Jeroen, a developer for a large multinational, put it this way, "Much of what we do in our business is communication. When we communicate, we're always referring to knowledge in our heads that we hope or assume is also present in the other party's head."

The problem is that it's hard for us to understand where that shared frame of reference ends and where we need to teach something completely new. Gráinne's CTO became frustrated when other people didn't understand his explanations because he couldn't imagine that other people had different experiences to his own.

Yes, we can grow as teachers and communicators. But there's a deeper issue. Onboarding shouldn't be an oral tradition.

Codebase onboarding as oral tradition

Let's take a moment to imagine something different.

You're sat around a fire with your family and close friends. The day has gone well. There is food, you have shelter, and yet there's a threat.

Some of the younger children have been wandering into the woods and eating mushrooms. Most have been fine, but one or two have become seriously ill.

You want to protect the children, but they don't understand why some mushrooms are bad, and others are just really tasty. You don't even know yourself. So, you tell a story to put it in a context you can all understand. You think on your feet. One of the elder members of your village can tell good mushrooms from bad. So, you say that all mushrooms have an evil spirit that only old people can cast out.

The story works. Over the years, it gets retold and embellished. Eventually, there's so much mythos around mushrooms that the original intent of the stories becomes forgotten. Even so, somehow, it continues to protect people, despite there now being a lot of unnecessary ritual associated with preparing mushroom-based meals.

Stories passed by word of mouth work act as vehicles for important knowledge. And we still use stories in our work as software developers.

Onboarding is a documentation problem

When everything is urgent, it's hard to prioritize work that will help you in the future. So it's somewhat understandable why onboarding a new colleague can be haphazard, clumsy, and inconsistent.

However, a bad onboarding is often actually a symptom of other problems. One particular issue is simply that many codebases lack good documentation. While individuals methods might have excellent comments, perhaps understanding of the whole system is less well documented. For example, there are teams where no two members would draw the same architecture diagram despite working on the same product.

At CodeSee, they've built tools that make it easier for teams to onboard new developers. And that's not by doing special extra work that just gets used in onboarding. It's by creating a shared understanding that benefits everyone who works on a codebase from onboarding and for the long term.

Regretful man photo by Nipan Chawcharernpon
Spaghetti by Maurijn Pach
Pomegranate seeds by by Tima Miroshnichenko
Angry cat by Pixabay
Scrabble tiles by Kathy Jones
Campfire by Jens Mahnke

Improve Your Developer Onboarding Path With the 10-3-10 Test

Matthew Revell — Tue, 18 Jan 2022 12:19:07 +0000

Getting to the point is essential for a smooth developer onboarding. Within seconds, you need to answer your product or project's what, why, and how.

But it can be hard to put ourselves in the shoes of a developer who knows nothing of what we do. That's why it's essential that we test and improve the onboarding path we give developers.

One way to do that is the 10-3-10 test. It's quick to perform, requires no special tools, and pretty much anyone can do it. Here's how.

From zero to Hello World in ten minutes

The idea behind the 10-3-10 test is pretty simple. A developer should land on your site without any context and achieve the Hello World state within 10 minutes.

Before a developer can get to that point, they need to know what the product does and then register to get a developer account.

Within all three of those milestones -- understanding, registration, and first product use -- lurks danger. At each stage, you're asking the developer to give you something on trust. At first, it's their time, then a small amount of information about themselves, and finally, it's both their time and their mental energy. It might sound over the top, but you need to reward the developer for each of those. Get the reward wrong, and the danger becomes apparent: the developer will lose trust and look elsewhere.

Drop-off is real

Work by Microsoft Research shows that typical web users decide whether to stay or go within 10 seconds of arriving at a web page. There is even an old study that suggests web page visitors form an opinion within 50 milliseconds of landing.

Keeping someone on the page long enough to explain the offering is just the start, though. Research on conversion rates by product analytics firm Heap suggests that 63% of SaaS users fail to complete product sign-up.

We are operating in a world of spam, clickbait, unregulated advertising, and other underhanded attempts to grab our attention. People have trained themselves to apply harsh relevance criteria to the information they find on the web.

Arguably, developers are not typical web users. Whether that makes them more or less patient will depend on their level of motivation, among other factors. What is clear, though, is that you have very little time in which to capture a developer's attention and then turn that into an interest in your product.

Three questions

There are multiple pressures on your developer onboarding flow. Product marketing might have a particular wording they want you to use. Someone in the growth team wants to try an experiment they read about recently. The VP of Sales is pushing for more data collection to assign new developer sign-ups to the appropriate salesperson.

Whether good or bad, the reality of these demands is that they can lead to a loss of focus. And in most companies, the demand for such change never really stops.

The 10-3-10 test is simple, repeatable, and quick, helping you measure whether you're continuing to serve developers. It asks three questions:

10 (understanding): Can a developer get a solid idea of what your product does within ten seconds of arriving on a developer-targeted landing page?
3 (registration): Can that person register for a developer account within three minutes of landing?
10 (first use): Can they get to Hello World ten minutes after first landing on the site? Whether you perform each test informally yourself or set up an ethnographic research session, it's worth diving into some of the factors that influence each stage first.

Understanding

How often have you been to a product website and come away none the wiser about what it does?

Competing demands too often lead to product pages that say a lot but communicate nothing. A common scenario is messaging that attempts to address too many different audiences at once. If a vendor compromises its message to serve both developers and, say, procurement managers, it'll serve neither well.

Sometimes, it's just that companies overthink how they talk about their products. As someone writing about a product, it can be hard to extract yourself from the context you have. It's tempting to build every comment, every meeting about the Chief Marketing Officer's vocab preferences, every barb thrown by the competition into that one very clever headline. But does that serve someone who just wants to know what problem your product solves and how?

The first step to passing the understanding test is to make sure you have a dedicated space to speak primarily to developers.

Next, stay specific and tell developers what your product does for them. Consider CodeSee's own home page. The headline and sub-head get straight to the action:

Visualize codebases faster

Map an entire codebase in just a few clicks.

The short follow-up paragraph then expands on that in a way that sticks entirely to the facts of how the product benefits developers.

Avoid the temptation to over-egg how you describe your offering. "SMS API," rather than "customer engagement solution." That kind of messaging has its place for certain audiences, and it makes product marketers feel good, but for developers, it's just another hurdle in the way of understanding whether that thing solves a problem that they have.

To pass the first test, a typical developer should understand the practical purpose of your product within ten seconds of landing on your developer home page.

Registration

Registration is a chasm in your developer onboarding. This is where developers must put the most trust in you by providing personal information without a clear idea of the pay-off. Provide them with guide ropes, way finding, and a hint of the reward that is to come.

First, how do you get a developer from the landing page to sign-up? The button or link you provide needs to be immediately obvious, not so wordy that people are tempted to skip it, and yet still communicate what's to come. Oh, and the copy must avoid scaring people off.

"Get started" and "Start now" are common choices. However, at least one study has shown that "Get started" attracts clicks, but not all are from people who are ready to try, download, or buy your product.

The Miro API's "Start building" is clearer. Click that, and you know you're about to get hands-on with the API.

CodeSee's "Try Maps now" communicates a lot in three words. "Try" tells you that you're going to be hands-on with the product while making it feel casual rather than intimidating. Naming the product enforces what's coming next, and "now" adds a sense that clicking will lead to a fast pay-off.

That's a lot for a button.

The registration process itself must stick to the principle of "minimum viable information". Sales and marketing colleagues might push to capture more and more information during registration, but your primary aim here is not to add another lead to the CRM. Instead, registration is about enabling access and then allowing the rest of the experience and product to win over the developer.

That doesn't mean you can't ask for more than just an email address and password. Most people have some tolerance for providing extra information. However, you should aim to frame at least some of those additional questions in terms of how they'll benefit the developer. Twilio's registration process is great for this. It asks some questions that might help their sales funnel but also collects information, such as your preferred programming language, that makes the developer dashboard more helpful.

To pass the second test, a typical developer should be able to get a developer account within three minutes of landing on your developer home page.

Hello World

Providing a smooth path through registration is good, but it's only a staging post. The developer's goal is to see for themselves whether your product solves their problem and whether they like the idea of working with your company.

There is enormous scope for ways to improve the path to Hello World, so let's focus on one thing. When the developer first logs into your dashboard, take them by the hand through the steps they need to achieve something worthwhile.

Such a first use experience is more than flashing up a quick-start guide or a click-through signposting of the dashboard's UI. It is a highly focused path that takes the developer from no knowledge of your product to that Hello World interaction. It builds on the supplemental information you've gathered during sign-up. Are they a Ruby developer? Great, get them to download your SDK's gem. They told you they work for a large company? Suggest they link their new account with Okta or other SSO providers to simplify integration with corporate sign-on.

That highly focused first use experience should contain everything the developer needs to get a feel for your solution and what it's like to develop with, in as efficient a way as possible.

If a typical developer can get to Hello World within ten minutes of the first landing on your developer pages, you've passed the 10-3-10 test.

And there's more

The 3-10-3 test is a blunt instrument, but it's useful as a way to keep us honest about whether our onboarding serves developers. It works well for commercial products, and there's plenty of scope to adapt it to onboarding a developer onto a team building a product or a developer joining an open source project.

Microscope picture by Public Domain Pictures

Building an app business using Heroku and Salesforce

Matthew Revell — Tue, 01 Dec 2020 16:22:07 +0000

The past decade was the era of the mobile app store.

Brilliant ideas, well executed, made fortunes for indie developers who were able to reach audiences of billions from their spare rooms, garages, and co-working spaces.

Thanks to the Google Play Store and Apple’s App Store, the best apps could reach users on merit rather than marketing budget.

But those days are gone.

Today, mobile app stores are dominated by big name vendors, while everyone else fights for a handful of ad dollars among millions of competitors. And mobile users are fickle. Most apps are uninstalled within a week of being used.

There is good news, though. We are now in the era of the business to business app marketplace, such as the Salesforce AppExchange. Motivated customers with long-term needs and realistic budgets are actively looking to buy solutions. So, what is it like for a solo developer or small team to develop such a business?

The size of the opportunity

Before we dive into the specifics of developing for an ecosystem such as Salesforce, there’s the question of whether it’s going to be worthwhile.

The short answer is: yes, absolutely.

Analyst firm IDC forecasts that, by 2024, the Salesforce ecosystem will create 4.2 million jobs and contribute $1.2 trillion in new business revenues to local economies.

Crucially, the majority of the value created by Salesforce is going to partners, such as companies making apps for the Salesforce AppExchange. In fact, for every dollar that Salesforce generates, its partners earn six dollars.

Okay, big numbers aren’t always relatable so let’s look at the opportunity in terms of relative growth. Spending on cloud software is predicted to grow 19% each year over that period. For non-cloud, it’s just 3%. If you’re creating something new, it stands a better chance of success if you deliver it as SaaS. And a marketplace will help you reach willing customers.

Look, I've got my stack and I like it

Even if you haven’t used Salesforce, then you’re almost certainly aware of its reach. All those thousands of organizations using Salesforce to run their day to day business offer a potential audience for app developers.

So, the opportunity looks good but how do you actually build an app for one of these marketplaces? Perhaps you’re thinking that it means getting used to a bunch of exotic languages and frameworks.

In the case of Salesforce AppExchange, you use technologies that you’d find anywhere else. Let’s start with the back-end. If you usually work with Ruby, Python, Go, Java, or pretty much any other open source language, then you can use that to do most of your back-end’s heavy lifting on Heroku. Add in Heroku Postgres, Heroku Redis, and tooling such as Apache Kafka on Heroku, and you have a standard, modern web stack.

So, where does Salesforce come in? As Heroku is part of the Salesforce platform, you can easily sync data between a Heroku Postgres database and one or more Salesforce orgs. In effect, your app’s back-end can live mostly on Heroku and synchronize with Salesforce when the need arises.

When it comes to the front-end, you’ll need to work more closely with Salesforce itself as your users will interact with your app from within Salesforce’s UI. Even so, the tools you’ll be using will be immediately familiar. Lightning Web Components is a JavaScript front-end framework much like ReactJS, with ready made elements for common scenarios and the flexibility to create your own when you need to.

In fact, this is another place where mobile development offers a good analogy. If you’re building a mobile app you’ll need to use specific APIs for the front-end, while the back-end can be designed however you like.

How SharinPix built their business with Salesforce

SharinPix is an image management app built specifically for the Salesforce AppExchange. It began life when its founder, Jean-Michel Mougeolle, needed to process photos taken by field agents working for his then company. The agents would upload the images into Salesforce but the company needed to resize them and add supplemental data such as automatic annotation and watermarks.

The challenge for Jean-Michel was that the core Salesforce platform didn’t lend itself to general development tasks, such as image manipulation. However, if he could use a standard web development framework, such as Ruby on Rails, then he could plug into standard image manipulation libraries quite easily.

Already familiar with Heroku, Jean-Michel built a proof of concept using Heroku Connect, which synchronizes data between Heroku Postgres and Salesforce. On Heroku, he had a Rails app that would take images from Salesforce, manipulate them, and then sync the processed images and metadata back into Salesforce. Crucially for Jean-Michel, no one who tried the demo app had any clue that Heroku was involved; as far as they were concerned, it was a standard Salesforce application.

Shortly after, Jean-Michel spun SharinPix out of his original company and today has a team of developers serving 20,000 users. And while the development side has given SharinPix the best of both worlds -- standard web dev on Heroku, with easy integration into Salesforce’s UI -- the company’s success has been as much about the route to market that the AppExchange provides.

“AppExchange is fantastic,” says Jean-Michel. “Customers know that our app is secure and trustworthy because it has the Salesforce stamp of approval. Discovery is also very good. People can search for image manipulation then find our app page, where they can watch videos, read about the app, and start a trial. We don’t have to play the SEO game or spend on ads, because we have a ready made audience.”

Getting your start in the Salesforce ecosystem

The next big opportunities for developer entrepreneurs might not be in the most obvious places. B2B marketplaces are growing, have audiences that have proven their willingness to spend money, and provide an ecosystem of tooling, marketing support, and more.

So, where do you go from here? If you’re interested in building for the Salesforce ecosystem, then there’s a wealth of learning materials on the Trailhead learning site, as well as a friendly and helpful community of fellow developers.

Mug image by Danielle MacInnes

Safari icon photo by Brett Jordan