DEV Community: Emmanuel Haankwenda

How to Power OpenCode CLI Agent with Decentralized 0G Router

Emmanuel Haankwenda — Tue, 28 Jul 2026 22:31:43 +0000

Agentic coding tools are becoming the default way many developers write software. While most people connect them to centralised APIs, 0G Network lets you run the same OpenAI-compatible workflows on decentralised compute using your 0G credits.

Because the 0G Router API is OpenAI-compatible, OpenCode can use it without any code changes—just point it at a different endpoint.

In this guide you'll learn how to:

Install OpenCode
Configure it to use the 0G Router
Connect your API key
Run GPT-5.6 Sol, DeepSeek V4 Pro, or GLM-5.2 from your terminal

Prerequisites

Before getting started, you'll need:

Node.js installed
A 0G account with compute credits
An API key from the 0G Console

Step 1 - Install OpenCode

Install OpenCode globally:

npm install -g opencode

Step 2 - Generate a 0G API Key

Head over to the 0G Console.

From there you can:

View your available credits
Browse available models
Generate an API key

Useful links:

0G Console: https://pc.0g.ai
Models Catalogue: https://pc.0g.ai/models

Your generated API key will look similar to:

sk-xxxxxxxxxxxxxxxxxxxxxxxx

Step 3 - Configure OpenCode

Open your configuration file:

nano ~/.config/opencode/opencode.json

Replace the contents with:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "0g": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "name": "0G Router",
        "baseURL": "https://router-api.0g.ai/v1",
        "apiKey": "{env:OG_API_KEY}"
      },
      "models": {
        "gpt-5.6-sol": {
          "id": "gpt-5.6-sol",
          "name": "GPT-5.6 Sol",
          "limit": {
            "context": 1048576,
            "output": 128000
          }
        },
        "deepseek-v4-pro": {
          "id": "deepseek-v4-pro",
          "name": "DeepSeek V4 Pro",
          "limit": {
            "context": 1048576,
            "output": 393216
          }
        },
        "glm-5.2": {
          "id": "zai-org/GLM-5-FP8",
          "name": "GLM-5.2",
          "limit": {
            "context": 1048576,
            "output": 131072
          }
        }
      }
    }
  },
  "model": "0g/gpt-5.6-sol"
}

Save the file and exit your editor.

Step 4 - Export Your API Key

Export your key into your terminal session:

export OG_API_KEY="your_0g_api_key_here"

Launch OpenCode:

opencode

Step 5 - Switch Between Models

Inside OpenCode run:

/models

You'll be able to choose between:

Model	Best For
GPT-5.6 Sol	Long reasoning, planning, complex coding tasks
DeepSeek V4 Pro	Fast editing, large refactors, repositories
GLM-5.2	General-purpose coding and analysis

Step 6 - Test Agentic Coding

Give OpenCode a task that requires planning, file creation and execution.

Example:

Create a zero-dependency HTML/JavaScript Flappy Bird game inside ./flappy-bird. Launch a local preview and verify that it works.

OpenCode will:

Create the directory
Generate the game
Write the HTML, CSS and JavaScript
Launch a preview server (when available)
Verify the output

All inference requests are routed through the 0G Router.

How It Works

OpenCode CLI
      │
      ▼
0G Router API
      │
      ▼
Decentralised GPU Compute
      │
      ▼
Model Execution
      │
      ▼
Tool Calls + Generated Code

Because the Router follows the OpenAI API specification, most existing AI SDKs and tools work by simply changing the baseURL.

Why Use 0G Router?

OpenAI-compatible API — works with existing tooling.
Decentralised compute — inference runs across the 0G Network.
Pay with 0G credits — use the credits in your 0G account to access powerful models.
Large context windows — models support up to 1M tokens.
Drop-in compatibility — point existing OpenAI-compatible tools at the Router with minimal configuration.

Resources

0G Console: https://pc.0g.ai
Models Catalogue: https://pc.0g.ai/models
0G Compute Documentation: https://docs.0g.ai/concepts/compute
OpenCode Documentation: https://opencode.ai

Final Thoughts

The best part about the 0G Router is that you don't have to learn a new API. If your application, SDK, or coding agent already supports the OpenAI API, switching to decentralised inference is often as simple as changing the baseURL and supplying a 0G API key.

That makes it easy to experiment with flagship open-weight models like GPT-5.6 Sol, DeepSeek V4 Pro, and GLM-5.2 while taking advantage of decentralised GPU infrastructure.

Have you tried OpenCode with the 0G Router yet? If so, I'd love to hear what you're building in the comments.

Why AI agents still can't buy anything yet

Emmanuel Haankwenda — Thu, 07 May 2026 14:25:14 +0000

A working tour of x402, OKX APP, ERC-3009, TEE-backed inference, and the missing pieces of the autonomous internet stack.

Most "AI agents" today are really just chatbots with tools.

The moment an agent needs to independently spend money, access paid resources, prove identity, or justify a decision, the current web stack starts breaking down.

Every payment, identity, and trust primitive on the modern web was designed for a human clicking a button in a browser.

Agents were never part of the model.

I've been building AI agents for the last six months and this became obvious very quickly: most agents cannot actually do useful things on the open internet without human infrastructure glued around them.

They cannot:

pay for APIs autonomously
prove they're allowed to access a resource
get billed dynamically at request time
carry portable identity and reputation
prove what decision they made and why
protect sensitive business logic from the model provider

The problem is structural.

The good news is that the missing pieces are finally starting to ship publicly, and multiple teams are independently building compatible parts of the stack.

Coinbase is shipping x402.
OKX is shipping APP.
0G Labs is shipping verifiable storage and TEE-backed inference.
Anthropic pushed the MCP ecosystem into the mainstream.

For the first time, these systems are starting to compose into something real.

This post walks through:

what agents are missing today
the protocols filling those gaps
why verifiable receipts and TEE-backed decisions matter
a real implementation stitching all of it together

What a real agent actually needs

Strip the phrase "AI agent" down to fundamentals and the requirements become pretty obvious.

An autonomous system needs:

1. A wallet

Real money it can move programmatically.

Not a Stripe customer ID.
Not a human-owned credit card.
Not a manually refreshed API key.

A real wallet.

Ideally gasless, because forcing every agent to also manage ETH for transaction fees becomes operationally painful very quickly.

2. Identity

Other systems need to know:

who this agent is
who operates it
what permissions it has
what reputation it carries

Without identity, an agent calling your API is just another anonymous request.

You cannot apply:

trust scoring
rate limiting
fraud heuristics
permissions
reputation systems

at the agent level.

3. Dynamic billing at the HTTP layer

The modern web flow looks like this:

request
→ blocked
→ create account
→ verify email
→ add payment method
→ generate API key
→ retry request

That flow completely breaks for autonomous software.

Agents need something closer to:

request resource
→ server says "this costs $0.01"
→ agent evaluates
→ pays
→ receives resource

No signup flow.
No dashboard.
No out-of-band billing.

The payment negotiation has to happen directly inside the request/response cycle.

4. Portable memory

Most agent frameworks today store memory in vector databases controlled by the platform itself.

That creates weird ownership problems.

The agent cannot:

move its memory somewhere else
prove what it knows
selectively reveal memory
keep sensitive memory private from the model provider

Those are not futuristic requirements.

They're basic ownership guarantees we'd expect from any serious software system.

5. Decisions it can defend

This is the part almost nobody talks about.

If an agent:

approves a refund
blocks a payment
rejects a customer
accepts a lead
spends money

somebody downstream is eventually going to ask:

"Why did the agent make that decision?"

Right now, most systems cannot answer that.

"The LLM decided" is not a serious audit trail.

The protocols filling the gap

None of this exists as one unified stack yet.

But almost every missing primitive now has at least one working implementation.

x402: pay on resource access

The HTTP 402 status code ("Payment Required") has existed since 1989 and basically sat unused for decades.

Coinbase revived it in 2025 as x402.

The flow is simple:

Agent
  ↓
GET /resource
  ↓
402 Payment Required
  ↓
sign payment authorization
  ↓
payment submitted
  ↓
resource unlocked

The server responds with:

the price
accepted asset
recipient address
network
settlement requirements

The agent signs a payment authorization and submits it back.

The resource unlocks immediately.

No signup flow.
No API key generation.
No human interaction.

Cloudflare shipped a version of this model for AI crawlers under their "pay per crawl" work.

Smaller services are now exposing:

paid APIs
oracle endpoints
downloadable assets
inference endpoints

through x402-compatible paywalls.

ERC-3009: the gasless payment primitive underneath it

Both x402 and OKX APP rely heavily on ERC-3009.

ERC-3009 is the signing standard underneath most gasless USDC payments.

Instead of sending a transaction directly on-chain, the agent signs a permission slip saying:

"Allow up to $0.01 USDC to move from my wallet to this merchant before this deadline."

Another system then submits the transaction and pays the gas fee for the agent.

This matters because it removes the requirement for agents to hold ETH.

The agent only needs USDC.

That's a surprisingly important usability improvement.

OKX APP: extending the x402 model

OKX shipped their own protocol variant called APP (Agent Payment Protocol).

At the wire level, APP is extremely similar to x402:

same EIP-712 typed signatures
same ERC-3009 settlement model
same request/response payment flow

But APP adds some important extensions.

Deferred aggregation

Instead of settling every tiny payment individually on-chain, agents can batch many small payments together.

Example:

100 API calls
→ 100 off-chain authorizations
→ 1 on-chain settlement

This becomes important for high-frequency agent workloads.

Session-based billing

APP also introduces the idea of prepaid session budgets.

Example:

Agent prepays $5
→ server deducts usage over time
→ long-running workflow completes

This is important for:

video generation
deep research
multi-step workflows
autonomous browsing sessions

The specs exist today.
SDK support is still early.

Agent identity: ERC-8004

Identity for agents is still immature.

ERC-8004 is one early attempt at solving this.

The basic idea:

agents get on-chain identities
identities contain claims
other systems can inspect those claims before interacting

An agent could eventually advertise:

operator identity
capabilities
permissions
reputation
certifications

Very little production infrastructure depends on ERC-8004 today.

But the underlying problem it tries to solve is real.

The real missing layer: verifiability

Payments alone are not enough.

You also need:

verifiable receipts
verifiable decisions

This is where the 0G stack becomes interesting.

Verifiable receipts with 0G Storage + 0G Chain

Suppose an agent buys data for $0.10.

A normal payment system gives you:

transaction hash
payment confirmation

But that is not enough.

You also want:

the exact payload that was served
proof that it wasn't modified later
a permanent cryptographic reference to it

0G Storage handles the content layer.

The receipt or payload gets uploaded into decentralized content-addressed storage.

That returns a root hash.

The root hash then gets anchored onto 0G Chain.

Now the transaction has a 3-layer proof trail:

1. Base transaction
   → proves money moved

2. 0G Storage receipt
   → proves what content was served

3. 0G Chain anchor
   → proves the content was not modified later

A third party can independently verify every step.

Nobody has to trust the merchant.

Verifiable decisions with TEE-backed inference

This is the part I think people are underestimating.

Agents increasingly make policy decisions.

Questions like:

should this refund be approved?
does this request violate policy?
should this payment be blocked?
is this customer risky?
should this lead be accepted?

Today, those prompts usually go directly to:

OpenAI
Anthropic
Google
another centralized inference provider

Which means the provider can theoretically see:

refund policies
fraud heuristics
pricing rules
sensitive business logic
internal compliance workflows

That becomes a serious issue very quickly.

What a TEE actually changes

0G Compute runs inference inside a TEE (Trusted Execution Environment).

Think of a TEE as hardware-isolated secure memory.

The workload runs inside an encrypted enclave protected by the CPU itself.

Even the infrastructure operator cannot inspect:

the prompt
the model input
the output
the business logic

The system then returns:

the result
a hardware attestation proving what code actually ran

This creates something extremely important:

decisions agents can defend cryptographically

Example:

merchant defines refund policy
→ agent evaluates refund request inside TEE
→ signed decision returned
→ merchant policy never leaks

For a $0.10 ebook purchase, this is probably overkill.

For:

healthcare data
financial systems
enterprise automation
compliance workflows
trading systems

it becomes very important.

A real implementation: Coal

Over the last few months I've been building Coal.

Coal is a payment platform for autonomous software running on Base + 0G.

Instead of talking abstractly about the stack, here's the concrete implementation.

Coal does five things.

1. Hosts an agent-discoverable merchant catalog

Merchant catalogs live on 0G Storage.

Agents can discover products without:

API keys
dashboards
centralized marketplaces

2. Accepts both x402 and OKX APP

The same /verify endpoint accepts:

x402-v1
app-v2

The server advertises supported protocols and the agent picks whichever it supports.

3. Settles via Base USDC

Payments settle using USDC on Base.

The operator wallet relays transactions so agents never need ETH.

Typical confirmation time is around 2 seconds.

4. Anchors receipts on 0G

Every payment receipt gets:

uploaded to 0G Storage
anchored onto 0G Chain

Anyone can independently verify the proof trail.

5. Runs policy decisions inside TEEs

Refund checks, quotas, permissions, and policy evaluations run through 0G Compute Sealed Inference.

Merchant rules stay private from the model provider.

A concrete example

Open:

https://agent.usecoal.xyz

Ask the embedded agent:

"Buy me the 0G Builder's Cheatsheet"

The flow looks like this:

discover_merchants
→ find merchant catalog
→ pay_merchant
→ sign ERC-3009 authorization
→ facilitator submits transaction
→ receipt anchored on 0G
→ PDF unlocks

The payment is real USDC on Base.

No human clicks anything.

What's still broken

The stack works today.

But a lot is still rough.

Discovery is fragmented

There is no "Google for agent-payable services" yet.

Current discovery options are fragmented across:

ERC-8004 registries
MCP marketplaces
project-specific catalogs
Coinbase Bazaar
custom integrations

Agents still mostly rely on manually configured endpoints.

That does not scale long term.

Identity is immature

Agent reputation and trust scoring barely exist today.

A malicious agent and a high-quality agent can often look identical at the protocol layer.

Cross-chain UX is messy

Different payment ecosystems prefer different chains.

Agents increasingly need:

multiple wallets
multiple balances
cross-chain settlement paths

which reintroduces operational complexity.

Async billing is still early

The request/response model works well for instant resources.

It breaks down for:

long-running research
asynchronous workflows
large generation jobs

Session-based billing exists in specs but is still early in production SDKs.

TEE tooling is rough

The primitives are good.

The developer experience still feels early.

Attestation verification from TypeScript applications is still awkward and under-tooled.

It reminds me a lot of early Web3 tooling around 2018.

Why this matters

I think the important shift here is conceptual.

For years, "AI agents" mostly meant:

prompts
workflows
tool calling
orchestration

Now we're starting to see:

autonomous payments
machine-native identity
programmable commerce
verifiable decisions
cryptographic receipts

The infrastructure layer is finally catching up.

Try it yourself

Live agent sandbox

https://agent.usecoal.xyz

Runs Claude/Qwen with an embedded wallet capable of autonomous payments.

MCP server

Official MCP Registry
Smithery

https://mcp.usecoal.xyz/api/mcp

13 tools for:

discovery
payment
verification
downloads

Multi-tenant by design.
Every user passes their own wallet key.

Source code

https://github.com/emmanuel39hanks/coal

MIT licensed.

Includes:

x402 facilitator
APP v2 settlement flow
receipt anchoring
React SDK
MCP server
Base USDC integration

The autonomous internet needs more visible reference implementations and fewer speculative threads.

Hopefully this helps move the first category forward.

Quick one for the marketing brains, how important is it really to know every email event during a campaign’s lifespan? Opens, clicks, forwards, replies, unsubscribes, all of it. Do you just need the key insights, or do you prefer full surveillance mode?

Emmanuel Haankwenda — Wed, 28 May 2025 18:23:08 +0000