DEV Community: Timothy Olaleke

Your AI Coding Agent Deserves Its Own Cloud Machine

Timothy Olaleke — Wed, 01 Apr 2026 11:24:07 +0000

I've been running Claude Code locally for months. It works, but my laptop fan sounds like a jet engine, my battery drains in two hours, and if I close the lid mid-session — gone.

Last week I moved my entire dev environment to a cloud VM. Claude Code runs there, my full stack runs there, and I SSH tunnel everything back to localhost. From my laptop it feels identical. From my phone, I can check on my AI coding agent while grabbing coffee.

Here's the exact setup. Every command is copy-pasteable. I verified each step end-to-end.

Step 0: Get Free Google Cloud Credits

If you don't have a GCP account yet, you get $300 in free credits for 90 days — no charge until you explicitly upgrade. That's more than enough to run this setup for months.

Go to cloud.google.com/free
Click Get started for free
Sign in with your Google account, add a payment method (you won't be charged)
You now have $300 in credits

Already have an account? Check your remaining credits at Billing → Overview in the console.

What this setup costs: about $0.13/hour for the VM. With the free tier, you can run it ~2,300 hours — roughly 3 months of 24/7 usage, or 6+ months during work hours only.

If you're a startup, apply for the Google for Startups Cloud Program — up to $200k in credits.

Why a Remote Dev Machine?

Three reasons pushed me off localhost:

Battery and thermals — AI coding agents hammer your CPU. A cloud VM doesn't care.
Session persistence — Close your laptop, hop on your phone, come back to your desk. The session is still running.
Dev environment consistency — Docker, databases, everything runs 24/7 on the VM. No more "let me spin up Postgres first."

The tradeoff is latency. SSH tunneling adds a few milliseconds. I can't feel it.

The Architecture

┌─────────────┐     SSH Tunnel      ┌──────────────────────┐
│   Laptop    │ ──────────────────> │     Cloud VM          │
│  localhost  │  port forwarding    │  ├── Your App         │
└─────────────┘                     │  ├── API Server       │
                                    │  ├── PostgreSQL       │
┌─────────────┐     Happy (E2E)     │  ├── Redis            │
│   Phone     │ ──────────────────> │  └── Claude Code      │
│  Happy App  │  encrypted sync     │     (in tmux)         │
└─────────────┘                     └──────────────────────┘

Your laptop and phone are thin clients. The VM does all the work.

Step 1: Create the VM

I'm using Google Cloud because my Claude Code runs on Vertex AI (covered that in my previous post). But this works with any cloud provider.

First, make sure you have the gcloud CLI installed. If not:

# macOS
brew install google-cloud-sdk

# Or download from https://cloud.google.com/sdk/docs/install

Then authenticate and set your project:

gcloud auth login
gcloud config set project YOUR_PROJECT_ID

Create the VM:

gcloud compute instances create my-dev-vm \
  --zone=us-central1-a \
  --machine-type=e2-standard-4 \
  --boot-disk-size=50GB \
  --boot-disk-type=pd-ssd \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=ubuntu-os-cloud

That's 4 vCPUs, 16GB RAM, 50GB SSD. Costs about $0.13/hour — covered by your free credits.

Step 2: Install Everything on the VM

SSH in:

gcloud compute ssh my-dev-vm --zone=us-central1-a

Then run these on the VM:

# Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker

# Node.js 22 + pnpm
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash -
sudo apt-get install -y nodejs
sudo npm install -g pnpm@9

# Claude Code
sudo npm install -g @anthropic-ai/claude-code

# Happy (mobile access to Claude Code)
sudo npm install -g happy

# tmux (persistent sessions)
sudo apt-get install -y tmux

Verify everything installed:

docker --version    # Docker 29+
node --version      # v22+
claude --version    # Claude Code 2.x
tmux -V             # tmux 3.x

Step 3: Clone Your Project and Start Services

git clone https://github.com/your-org/your-project.git
cd your-project
docker compose up -d

Verify everything is running:

docker compose ps

You should see your containers up with status (healthy):

NAME             STATUS              PORTS
my-app-api       Up 3 min (healthy)  0.0.0.0:3000->3000/tcp
my-app-web       Up 3 min (healthy)  0.0.0.0:3100->3100/tcp
my-app-postgres  Up 5 min (healthy)  0.0.0.0:5432->5432/tcp
my-app-redis     Up 5 min (healthy)  0.0.0.0:6379->6379/tcp

Your full stack is running on the VM. Your laptop isn't doing anything yet.

Step 4: SSH Tunnel to Localhost

This is the key part. From your local machine (not the VM), forward the ports you need:

gcloud compute ssh my-dev-vm --zone=us-central1-a -- \
  -L 3100:localhost:3100 \
  -L 3000:localhost:3000 \
  -N

What this does:

-L 3100:localhost:3100 — requests to localhost:3100 on your laptop go to port 3100 on the VM
-N — don't open a shell, just forward ports

Now open your browser:

http://localhost:3100 — your web app
http://localhost:3000 — your API

It's localhost. Your browser doesn't know the difference. Hot reload works. DevTools work.

Save it as an alias (add to ~/.zshrc or ~/.bashrc on your local machine):

alias dev-tunnel='gcloud compute ssh my-dev-vm --zone=us-central1-a -- \
  -L 3100:localhost:3100 -L 3000:localhost:3000 -N'

Step 5: Run Claude Code in tmux

SSH back into the VM and start Claude Code in a tmux session so it survives disconnects:

gcloud compute ssh my-dev-vm --zone=us-central1-a

On the VM:

tmux new -s claude
cd ~/your-project
claude

If you're using Vertex AI (GCP credits for Claude), add these to ~/.bashrc on the VM first:

export CLAUDE_CODE_USE_VERTEX=1
export ANTHROPIC_VERTEX_PROJECT_ID=YOUR_PROJECT_ID
export CLOUD_ML_REGION=global
export ANTHROPIC_MODEL=claude-opus-4-6

Then source ~/.bashrc before running claude.

Claude Code now has your full project right there — files, Docker services, databases, everything. No latency.

tmux basics:

Ctrl+b d — detach (session keeps running in the background)
tmux attach -t claude — reattach from any SSH session
Close your laptop, come back tomorrow — session is exactly where you left it

Step 6: Code from Your Phone with Happy

This changed my workflow. Happy is an open-source mobile client for Claude Code. End-to-end encrypted.

On the VM, in a new tmux session:

tmux new -s happy
happy claude -- --dangerously-skip-permissions

The --dangerously-skip-permissions flag runs Claude Code in "yolo mode" — no permission prompts. Remove it if you want the default safety checks.

Happy shows a QR code. Scan it with the Happy app:

That's it. You control Claude Code from your phone. When you get back to your desk, press any key on your keyboard and control switches back.

I use this constantly. Standing in line? Check if tests passed. On a call? Glance at what Claude is building.

My Daily Workflow

Morning:

dev-tunnel  # alias from Step 4

Open localhost:3100. Everything is already running from yesterday. No cold start.

During the day:
Claude Code runs in tmux on the VM. Attach when I need it, detach when I don't. Laptop stays cool.

Away from desk:
Happy app on my phone. "Run the test suite." "Show me the API logs."

End of day:
Close the laptop. VM keeps running. Tomorrow: dev-tunnel and I'm back in 2 seconds.

Cost

Resource	Spec	Monthly
VM (e2-standard-4)	4 vCPU, 16GB RAM	~$97 (or ~$39 spot)
Disk (50GB SSD)	pd-ssd	~$8.50
Network	SSH tunnel overhead	~$1-2
Total		~$107 (or ~$49 spot)

All covered by the $300 free credits for about 3 months.

Auto-stop to save money:

gcloud compute resource-policies create vm-maintenance workday-schedule \
  --start-schedule="0 8 * * 1-5" \
  --stop-schedule="0 20 * * 1-5" \
  --timezone=UTC

Tips

Use autossh for reliable tunnels — SSH tunnels drop. autossh reconnects:

# Install: brew install autossh (macOS) or apt install autossh (Linux)
autossh -M 0 -f -N \
  -o "ServerAliveInterval 30" \
  -o "ServerAliveCountMax 3" \
  -L 3100:localhost:3100 \
  -L 3000:localhost:3000 \
  my-dev-vm

VS Code Remote SSH — connect your IDE directly to the VM:

Cmd+Shift+P → "Remote-SSH: Connect to Host" → my-dev-vm

Multiple projects on one VM:

cd ~/project-a && docker compose -p project-a up -d  # ports 3000-3100
cd ~/project-b && docker compose -p project-b up -d  # ports 4000-4100

Quick Reference

What	Command
Get free credits	cloud.google.com/free
Create VM	`gcloud compute instances create my-dev-vm --machine-type=e2-standard-4 --boot-disk-size=50GB ...`
SSH in	`gcloud compute ssh my-dev-vm`
Start stack	`docker compose up -d`
Tunnel ports	`gcloud compute ssh my-dev-vm -- -L 3100:localhost:3100 -L 3000:localhost:3000 -N`
Claude Code	`tmux new -s claude` then `claude`
Mobile access	`happy claude` → scan QR
Stop VM	`gcloud compute instances stop my-dev-vm`
Start VM	`gcloud compute instances start my-dev-vm`

Your laptop should be a thin client. Let the cloud do the heavy lifting.

Part 2 of my Claude Code on Google Cloud series. Part 1: Run Claude Code on Google Cloud

Run Claude Code on Google Cloud: Use Your GCP Credits for AI Coding, Desktop Control, and More

Timothy Olaleke — Tue, 31 Mar 2026 10:14:45 +0000

Run Claude Code on Google Cloud: Use Your GCP Credits for AI Coding, Desktop Control, and More

Claude Code runs natively on Google Cloud's Vertex AI. Same models, same capabilities (coding, agents, MCP servers, even desktop control) but billed entirely through your GCP account.

If you're already on Google Cloud, you don't need a separate Anthropic subscription. Your existing credits, billing, and IAM setup just work. Here's exactly how to set it up.

What You Get

This isn't a watered-down version. Through Vertex AI, you get:

All Claude models: Opus 4.6, Sonnet 4.6, Haiku 4.5, and previous generations
Full Claude Code features: file editing, code generation, terminal commands, MCP servers
Desktop control: screenshots, mouse clicks, keyboard input, browser automation
Your existing GCP billing: startup credits, free trial, enterprise spend, committed use discounts

	Anthropic Direct	Vertex AI
Billing	Separate Anthropic account	Your existing GCP billing
Credits	Pay as you go	Use GCP/startup credits
Auth	API key management	`gcloud auth` (already configured)
Compliance	Separate vendor	Same GCP governance
Models	All Claude models	All Claude models (same day availability)
Desktop Control	Built-in (requires Pro/Max)	Native macOS tools + MCP servers

Step 1: Enable Claude in the Model Garden

Go to Vertex AI Model Garden in your GCP console. Filter by Anthropic under Providers.

You'll see 8 Claude models available:

Claude Opus 4.6: Most intelligent, industry leader for coding and agents
Claude Sonnet 4.6: Frontier intelligence for high volume coding and research
Claude Haiku 4.5: Fastest and most cost effective
Plus previous generations (Opus 4.5, 4.1, 4, Sonnet 4)

Click any model to see its details and model ID:

Click "Open in Vertex AI Studio" to test the model directly in the console before setting up Claude Code.

Step 2: Configure Claude Code

Install Claude Code:

npm install -g @anthropic-ai/claude-code

Add three environment variables to your ~/.zshrc or ~/.bashrc:

# Route Claude Code through Vertex AI
export CLAUDE_CODE_USE_VERTEX=1

# Your GCP project ID (find it at console.cloud.google.com)
export ANTHROPIC_VERTEX_PROJECT_ID=my-gcp-project

# Region (us-east5, europe-west1, or global)
export CLOUD_ML_REGION=us-east5

That's it. No API keys to manage. Claude Code picks up your existing gcloud authentication automatically.

Make sure you're authenticated:

gcloud auth login
gcloud auth application-default login

Want to use Opus instead of Sonnet (the default)?

export ANTHROPIC_MODEL=claude-opus-4-6

Step 3: Run It

source ~/.zshrc
claude

Everything works exactly the same: file editing, code generation, terminal commands, MCP servers. The only difference? Billing goes to your GCP account.

Step 4: Desktop Control on Vertex AI

Here's where it gets interesting. Claude Code's built-in computer use requires a claude.ai Pro/Max subscription. But on Vertex AI, you can get the same capabilities using native macOS tools:

# Take a screenshot (Claude Code is multimodal and can read images)
screencapture -x /tmp/screenshot.png

# Mouse and keyboard control
brew install cliclick

# Click at coordinates
cliclick c:500,300

# Type text
cliclick t:"Hello World"

For browser automation, add an MCP server to ~/.claude/mcp.json:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}

Now Claude Code can control Chrome, navigate pages, fill forms, and take screenshots. All running through Vertex AI on your GCP credits.

I used this exact setup to take the screenshots in this post. Claude Code navigated the GCP console, filtered the Model Garden by Anthropic, and captured everything automatically.

Pro Tips

Use the `global` Region

export CLOUD_ML_REGION=global

The global endpoint gets the latest models first and avoids the 10% regional price premium on older model versions.

Switch Between Vertex and Direct

# Quick alias for direct Anthropic API when needed
cc() {
  CLAUDE_CODE_USE_VERTEX=0 claude "$@"
}

Check Your Quotas

Vertex AI has per region quotas for Claude models:

Console > IAM & Admin > Quotas > Filter: "anthropic"

If you hit rate limits, request a quota increase or switch regions.

TL;DR

What	How
Enable Claude	Model Garden > Anthropic > Click model
Configure	`CLAUDE_CODE_USE_VERTEX=1` + project ID + region
Auth	`gcloud auth login` (you already did this)
Billing	Your existing GCP credits
Desktop control	`screencapture` + `cliclick` + MCP servers
Models	All Claude models (Opus 4.6, Sonnet 4.6, Haiku 4.5)

If you're on GCP, your credits are sitting there. Use them.

Your Browser Has a Remote Control — And Nobody Told You

Timothy Olaleke — Thu, 19 Mar 2026 16:15:50 +0000

Your Browser Has a Remote Control — And Nobody Told You

3 tools that let AI agents drive Chrome. I tested all three. Here's what actually happens.

Every Chrome browser ships with a hidden feature that almost nobody talks about: a remote control API called the Chrome DevTools Protocol (CDP). It's the same protocol that powers Chrome DevTools — the thing you open when you press F12. But here's the part that changes everything: any program can use it. Including AI agents.

I've been using CDP daily for over a year to let AI agents browse the web using my real browser — with all my logged-in sessions intact. No passwords shared. No API keys. No OAuth flows. The AI just uses my browser like I would.

Three major tools have emerged to give AI agents this superpower. I tested all three on the same task, with the same browser, and discovered something that most tutorials and docs don't tell you.

The Three Contenders

	Playwright MCP	Chrome DevTools Protocol	agent-browser
Made by	Microsoft	Google (built into Chrome)	Vercel Labs
GitHub Stars	29,000+	Built-in (no repo needed)	23,500+
Language	TypeScript	Any (HTTP + WebSocket)	Rust
Latest Version	v0.0.68	Ships with Chrome	v0.21.2
Install	`npx @playwright/mcp`	Already in your browser	`npm i -g agent-browser`

They all use CDP under the hood. But they use it very differently — and that difference matters more than you'd think.

Setting It Up (60 Seconds)

Before we compare the tools, let's enable Chrome's remote control. It takes one command.

Start Chrome with remote debugging:

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222

# Linux
google-chrome --remote-debugging-port=9222

# Windows
chrome.exe --remote-debugging-port=9222

Verify it's working:

curl http://localhost:9222/json/version

If you see a JSON response with your Chrome version, you're ready. That's the entire setup.

What just happened? You told Chrome to listen on port 9222 for remote control commands. Any program on your machine can now send instructions to your browser — open tabs, read pages, click buttons, fill forms, take screenshots.

Coming soon: Chrome 146+ is adding a native settings toggle for remote debugging — no command line needed. Go to DevTools (F12) → Settings → Experiments and search for "MCP". Once enabled, AI agents can connect without restarting Chrome. This is rolling out gradually in 2025/2026.

Seeing It in Action: agent-browser

Let's start with the most beginner-friendly tool. agent-browser by Vercel Labs gives you 108+ simple commands to control Chrome from your terminal.

Install it:

npm install -g agent-browser
agent-browser install  # Downloads a browser (first time only)

Fill a form in 4 commands:

Here's what happens at each step:

Step 1 — Open a page. Just like clicking a link, but from the command line.

Step 2 — Snapshot. This is the magic for AI agents. Instead of raw HTML, you get a clean list of interactive elements with reference IDs like [ref=e2]. An AI agent reads this and knows exactly what's on the page.

Step 3 — Interact. Use those ref IDs to fill fields, click buttons, check boxes. agent-browser fill @e2 "John Doe" fills the customer name field. Simple.

Step 4 — Screenshot. Take a picture of the result. With --annotate, every interactive element gets a numbered label — perfect for AI vision models.

Before and after:

The numbered red labels are --annotate mode. Each number maps to an element the AI can interact with. This is how vision-based AI agents understand web pages.

The Discovery: Session Sharing

Here's the thing nobody tells you. I tested all three tools against the same page — an authenticated dashboard behind a login. Same browser, same URL, same Chrome instance.

Two tools saw the full dashboard. One saw a login page.

What's happening?

When you connect via raw CDP or agent-browser --cdp 9222, you're using Chrome's default browser context. This means the AI agent sees exactly what you'd see — all your cookies, all your logged-in sessions, everything.

When you use Playwright MCP or agent-browser in standalone mode, they create an isolated browser context. Think of it like an incognito window. No cookies, no sessions, no logins. A clean slate.

The session sharing table:

Tool	Mode	Sees Your Logins?	Why
Raw CDP	Default context	Yes	Uses Chrome's real cookie jar
agent-browser	`--cdp 9222`	Yes	Connects to Chrome's default context
agent-browser	Standalone	No	Launches its own browser
Playwright MCP	Default	No	Creates an isolated browserContext

If you want your AI agent to use your existing logins — to read your email, check your dashboards, manage your accounts — you need raw CDP or agent-browser connected via --cdp.

If you want isolation — for testing, scraping, or running untrusted automations — Playwright MCP or agent-browser standalone gives you that by default.

Neither is "better." They're for different jobs. But most people don't know the difference exists.

How CDP Actually Works (The 2-Minute Version)

Chrome's remote control has three layers. That's it.

1. List open tabs (HTTP GET)

curl http://localhost:9222/json

Returns a JSON list of every tab with its title, URL, and WebSocket address.

2. Open a new tab (HTTP PUT — changed in Chrome 145+)

curl -X PUT "http://localhost:9222/json/new?https://example.com"

3. Send commands (WebSocket)

// Connect to a tab's WebSocket URL, then send:
{ "method": "Page.navigate", "params": { "url": "https://example.com" } }
{ "method": "Runtime.evaluate", "params": { "expression": "document.title" } }
{ "method": "Page.captureScreenshot" }

That's the entire protocol. HTTP for tab management, WebSocket for commands. You can read, click, type, screenshot, and intercept network requests on any page.

Head-to-Head: Features Compared

Playwright MCP (Microsoft)

Best for: AI agents that need structured browser automation with safety guarantees.

# Add to Claude Code, Cursor, or any MCP-compatible AI tool
npx @playwright/mcp@latest

What it gives you:

Snapshot mode — Returns an accessibility tree. AI agents reference elements by ref IDs instead of fragile CSS selectors
Console + network — Capture console logs and network requests
Form filling — Dedicated tools for clicks, fills, selects
Screenshots — PNG/JPEG with element-level targeting
Session isolation — Each connection gets its own clean context
Extension mode — --extension flag creates a bridge that CAN share sessions (shipped recently)

29,000+ stars. Isolated by default (intentional). Very active development.

agent-browser (Vercel Labs)

Best for: Fast, native CLI automation. AI agents that need speed and flexibility.

npm install -g agent-browser
agent-browser install  # Downloads Chrome for Testing (first time)

What it gives you:

108+ commands — open, click, fill, snapshot, screenshot, eval, get text, find role, mouse, network, har, and more
Annotated screenshots — --annotate labels interactive elements with numbered boxes for vision models
Daemon architecture — Browser persists between commands, chain with &&
CDP connection — --cdp 9222 connects to your real browser with all sessions
Session persistence — --session-name myapp auto-saves and restores browser state
Auto-connect — --auto-connect finds your running Chrome automatically
iOS Simulator support — Test on iPhone simulators via Appium
HAR recording — Capture full HTTP archive of all requests

# Chain commands — browser stays alive between them
agent-browser open example.com && \
agent-browser wait --load networkidle && \
agent-browser snapshot -i

Built in Rust. 78 releases in ~3 months. Created by Malte Ubl (Vercel CTO) and team. 23,500+ stars.

Raw CDP (DIY)

Best for: Maximum control, authenticated workflows, custom integrations.

No install needed — just talk to Chrome's HTTP/WebSocket API directly:

# Check what's running
curl http://localhost:9222/json/version

# List your real open tabs
curl http://localhost:9222/json

# Open a new tab (preserves all cookies and sessions)
curl -X PUT "http://localhost:9222/json/new?https://example.com"

No framework. No dependencies. Just HTTP requests and WebSocket messages. You can build a full browser automation tool in a few hundred lines of code. This is the lowest-level option — maximum power, maximum flexibility.

Using These Tools with AI Coding Agents

These tools really shine when connected to AI coding agents like Claude Code, Cursor, OpenCode, or Windsurf. Here's how:

With Claude Code (MCP)

// Add to .claude/mcp.json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Now Claude Code can browse the web, fill forms, take screenshots, and read pages directly.

With agent-browser (CLI)

Any AI agent that can run shell commands can use agent-browser:

# AI agent runs these commands to research a topic
agent-browser open "en.wikipedia.org/wiki/Chrome_DevTools"
agent-browser snapshot -i      # Read the page content
agent-browser screenshot       # See what it looks like

With agent-browser --cdp (Authenticated)

# Connect to YOUR Chrome — AI reads pages as you
agent-browser --cdp 9222 snapshot -i
# Now the AI can see your dashboards, email, authenticated content

Connecting to Electron Apps

Since Electron apps (VS Code, Slack, Discord) are built on Chromium, you can control them too:

# Launch any Electron app with CDP debugging
"/Applications/Visual Studio Code.app/Contents/MacOS/Electron" --remote-debugging-port=9333

# Connect agent-browser to VS Code
agent-browser --cdp 9333 snapshot

The Landscape Is Moving Fast

This isn't a niche topic anymore. The browser automation for AI agents space is exploding:

browser-use (78,000 stars) — Originally built on Playwright, switched to raw CDP in 2025 for speed
chrome-devtools-mcp (30,000+ stars) — Google's Chrome team released an official MCP server for CDP
Chrome 146 — Google is adding a native settings toggle for AI agent access via MCP, built right into Chrome

The trend is clear: CDP is becoming the standard interface between AI agents and web browsers. Google endorses it. Microsoft builds on it. Vercel bets on it.

When to Use What

Use Playwright MCP when:

You need test isolation — each run starts clean
You're building automated testing pipelines
You want structured accessibility snapshots for AI
Security matters — you don't want the AI accessing your real sessions

Use agent-browser when:

You want speed — native Rust, daemon architecture
You need rich CLI commands — 108+ built-in operations
You want flexibility — standalone OR connected to your browser
You're working in cloud sandboxes with parallel agent sessions
You want the easiest path — just type commands and things happen

Use raw CDP when:

You need authenticated sessions — access your real logins
You want zero dependencies — just HTTP and WebSocket
You're building custom integrations specific to your workflow
You need to intercept network requests or capture auth tokens

Or combine them:

The tools aren't mutually exclusive. You can:

Use raw CDP or agent-browser --cdp for authenticated workflows (read your email, manage dashboards)
Use agent-browser standalone for fast scripted automation (fill forms, scrape data)
Use Playwright MCP for isolated testing (run tests in clean contexts)

All talking to the same Chrome, via the same protocol.

Get Started Now

Step 1: Start Chrome with debugging enabled:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --remote-debugging-port=9222

Step 2: Verify it works:

curl http://localhost:9222/json/version

Step 3: Pick your tool and try it:

# Option A: Playwright MCP (isolated, structured)
npx @playwright/mcp@latest --cdp-endpoint http://localhost:9222

# Option B: agent-browser (fast, flexible)
npm i -g agent-browser
agent-browser open example.com && agent-browser snapshot -i

# Option C: agent-browser connected to YOUR browser (authenticated)
agent-browser --cdp 9222 snapshot -i

# Option D: Raw CDP (minimal, no dependencies)
curl http://localhost:9222/json  # List your real tabs

You now have AI-ready browser control. Your logged-in sessions, your tabs, your data — all accessible to AI agents through the protocol that was hiding in plain sight.

The Bottom Line

Every Chrome browser ships with a remote control. Three major tools let AI agents use it. They all speak the same protocol, but they make fundamentally different choices about session isolation — and that one choice determines whether your AI agent sees a login page or your actual dashboard.

Now you know the difference. Build accordingly.

Give Your AI Agent the Instructions

Want your AI agent to already know how to use these tools? Each project publishes skills — ready-made instruction files you can pass to Claude Code, Cursor, OpenCode, or any AI coding agent.

agent-browser skills

npx skills add github:vercel-labs/agent-browser

5 skills available: general browser automation, QA/dogfood testing, Electron app control (VS Code, Slack, Discord, Figma), Slack workspace automation, and Vercel Sandbox cloud sessions.

The Electron skill is especially powerful — it teaches your AI agent how to launch and control desktop apps like VS Code, Slack, or Figma through CDP. Your AI agent can read Slack messages, navigate VS Code, or interact with any Chromium-based desktop app.

chrome-devtools-mcp skills

npx skills add github:anthropics/anthropic-cookbook chrome-devtools-mcp

5 skills available: core Chrome DevTools automation, CLI scripting, accessibility debugging, LCP performance optimization, and connection troubleshooting.

Raw CDP skill

npx skills add github:anthropics/anthropic-cookbook chrome-cdp

Skill available: Lightweight CDP CLI for live Chrome session control — connects to your real tabs with all cookies preserved. 13 commands, per-tab daemon architecture.

What are skills? Skills are instruction files that teach AI agents how to use specific tools. Instead of explaining everything yourself, you install a skill and your agent instantly knows the commands, best practices, and common patterns. Think of them like a manual the AI reads before it starts working.

Find me at timtech4u.dev or @timtech4u.

Building AI Agents with Google ADK, FastAPI, and MCP

Timothy Olaleke — Mon, 14 Apr 2025 23:58:36 +0000

This guide will walk you through integrating Google's Agent Development Kit (ADK) with FastAPI and the Model Context Protocol (MCP). We'll start with basic ADK usage, then extend it to work with FastAPI, and finally create an MCP server from the same codebase.

What You'll Learn

How to build a basic ADK agent with tools
How to serve your ADK agent using FastAPI
How to expose your ADK tools through an MCP server
Best practices for each integration pattern

Prerequisites

You'll need:

Python 3.10+ installed
Access to Google's Gemini API (or another supported model)
Basic knowledge of Python and APIs

Part 1: Getting Started with Google ADK

The Google Agent Development Kit (ADK) is a framework for building AI agents with tool-using capabilities.

Installation

pip install google-adk python-dotenv

Creating a Basic Agent

Let's create a simple agent with two tools: one to check the weather and another to get the current time in a city.

First, create a directory structure:

adk_agents/
  ├── multi_tool_agent/
  │   ├── __init__.py
  │   └── agent.py
  └── __init__.py

Define your agent in multi_tool_agent/agent.py:

import datetime
from zoneinfo import ZoneInfo
from google.adk.agents import Agent

def get_weather(city: str) -> dict:
    """Get the current weather in a city."""
    if city.lower() == "new york":
        return {
            "status": "success",
            "report": "The weather in New York is sunny with 25°C."
        }
    return {
        "status": "error",
        "error_message": f"Weather for '{city}' unavailable."
    }

def get_current_time(city: str) -> dict:
    """Get the current time in a city."""
    city_timezones = {
        "new york": "America/New_York",
        "london": "Europe/London",
        "tokyo": "Asia/Tokyo",
        "paris": "Europe/Paris"
    }

    if city.lower() in city_timezones:
        try:
            tz = ZoneInfo(city_timezones[city.lower()])
            now = datetime.datetime.now(tz)
            return {
                "status": "success",
                "report": f"The current time in {city} is {now.strftime('%Y-%m-%d %H:%M:%S %Z')}"
            }
        except Exception:
            pass

    return {
        "status": "error",
        "error_message": f"Time information for '{city}' unavailable."
    }

# Define the agent with the name "root_agent" (required by ADK)
root_agent = Agent(
    name="weather_time_agent",
    model="gemini-1.5-flash",  # Use your preferred Gemini model
    description="Agent that provides weather and time information for cities.",
    instruction="You help users with time and weather information for various cities.",
    tools=[get_weather, get_current_time],
)

Make sure to export the agent in multi_tool_agent/__init__.py:

from .agent import root_agent

__all__ = ["root_agent"]

Testing Your Agent

Run the agent using the ADK CLI:

cd adk_agents
adk chat -a multi_tool_agent

If you want to test the GUI:

cd adk_agents
adk web -a multi_tool_agent

Part 2: Integrating with FastAPI

Now let's wrap our ADK agent in a FastAPI application, which makes it deployable as a web service.

Installation

pip install fastapi "uvicorn[standard]" sqlalchemy

Creating the FastAPI Wrapper

Create api.py in your root directory:

import os
import sys
import uvicorn
from fastapi import FastAPI
from google.adk.cli.fast_api import get_fast_api_app
from dotenv import load_dotenv

# Set up paths
BASE_DIR = os.path.abspath(os.path.dirname(__file__))
AGENT_DIR = BASE_DIR  # Parent directory containing multi_tool_agent

# Set up DB path for sessions
SESSION_DB_URL = f"sqlite:///{os.path.join(BASE_DIR, 'sessions.db')}"

# Create the FastAPI app using ADK's helper
app: FastAPI = get_fast_api_app(
    agent_dir=AGENT_DIR,
    session_db_url=SESSION_DB_URL,
    allow_origins=["*"],  # In production, restrict this
    web=True,  # Enable the ADK Web UI
)

# Add custom endpoints
@app.get("/health")
async def health_check():
    return {"status": "healthy"}

@app.get("/agent-info")
async def agent_info():
    """Provide agent information"""
    from multi_tool_agent import root_agent

    return {
        "agent_name": root_agent.name,
        "description": root_agent.description,
        "model": root_agent.model,
        "tools": [t.__name__ for t in root_agent.tools]
    }

if __name__ == "__main__":
    print("Starting FastAPI server...")
    uvicorn.run(
        app, 
        host="0.0.0.0", 
        port=9999, 
        reload=False
    )

Running the FastAPI Server

python api.py

Access the ADK Web UI at http://localhost:9999/dev-ui

Part 3: Creating an MCP Server

The Model Context Protocol (MCP) allows AI models to discover and use tools. Let's expose our tools via MCP.

Installation

pip install mcp

Adding MCP Server Support

Add the following code to api.py:

# MCP Server Implementation
from mcp import types as mcp_types
from mcp.server.lowlevel import Server
from mcp.server.models import InitializationOptions
import mcp.server.stdio
import json
import asyncio
from google.adk.tools.function_tool import FunctionTool
from google.adk.tools.mcp_tool.conversion_utils import adk_to_mcp_tool_type

def create_mcp_server():
    """Creates an MCP server exposing our agent's tools."""
    from multi_tool_agent.agent import get_weather, get_current_time

    # Wrap functions in FunctionTool objects
    weather_tool = FunctionTool(get_weather)
    time_tool = FunctionTool(get_current_time)

    # Create MCP Server
    app = Server("weather-time-mcp-server")

    @app.list_tools()
    async def list_tools() -> list[mcp_types.Tool]:
        """List available tools."""
        # Convert ADK tools to MCP format
        mcp_tools = [
            adk_to_mcp_tool_type(weather_tool),
            adk_to_mcp_tool_type(time_tool)
        ]
        return mcp_tools

    @app.call_tool()
    async def call_tool(name: str, arguments: dict) -> list[mcp_types.TextContent]:
        """Execute a tool call."""
        # Map tool names to functions
        tools = {
            weather_tool.name: weather_tool,
            time_tool.name: time_tool
        }

        if name in tools:
            try:
                # Execute the tool
                result = await tools[name].run_async(
                    args=arguments,
                    tool_context=None,
                )
                return [mcp_types.TextContent(type="text", text=json.dumps(result))]
            except Exception as e:
                return [mcp_types.TextContent(
                    type="text", 
                    text=json.dumps({"error": str(e)})
                )]
        else:
            return [mcp_types.TextContent(
                type="text", 
                text=json.dumps({"error": f"Tool '{name}' not found"})
            )]

    return app

async def run_mcp_server():
    """Run the MCP server over standard I/O."""
    app = create_mcp_server()

    async with mcp.server.stdio.stdio_server() as (read_stream, write_stream):
        await app.run(
            read_stream,
            write_stream,
            InitializationOptions(
                server_name=app.name,
                server_version="0.1.0",
                capabilities=app.get_capabilities(),
            ),
        )

Add Command-Line Argument Support

Update the main section to support both modes:

if __name__ == "__main__":
    # Parse command line arguments
    import argparse
    parser = argparse.ArgumentParser(description="ADK Agent Server")
    parser.add_argument("--mode", choices=["web", "mcp"], default="web",
                      help="Run as web server or MCP server (default: web)")
    args = parser.parse_args()

    if args.mode == "mcp":
        # Run as MCP server
        print("Starting MCP server mode...")
        asyncio.run(run_mcp_server())
    else:
        # Run as web server (default)
        print("Starting Web server mode...")
        uvicorn.run(
            app, 
            host="0.0.0.0", 
            port=9999, 
            reload=False
        )

Testing the MCP Server

Create a simple test file test_mcp_server.py:

import os
import asyncio
import subprocess
import time
from google.adk.tools.mcp_tool import MCPToolset
from mcp.client.stdio import StdioServerParameters

API_SCRIPT_PATH = os.path.join(os.path.dirname(os.path.abspath(__file__)), "api.py")

async def test_mcp_server():
    """Test the MCP server by checking tool availability."""
    # Connect to MCP server
    tools, exit_stack = await MCPToolset.from_server(
        connection_params=StdioServerParameters(
            command='python',
            args=[API_SCRIPT_PATH, '--mode', 'mcp']
        )
    )

    try:
        # List available tools
        tool_names = [tool.name for tool in tools]
        print(f"Found {len(tool_names)} tools: {', '.join(tool_names)}")

        # Verify expected tools are available
        if "get_weather" in tool_names and "get_current_time" in tool_names:
            print("SUCCESS: MCP server is working correctly!")
        else:
            print("WARNING: Not all expected tools were found!")
    finally:
        await exit_stack.aclose()

if __name__ == "__main__":
    asyncio.run(test_mcp_server())

Run the test:

python test_mcp_server.py

Using Your MCP Server with Claude or other AI Assistants

Once your MCP server is running, you can use it with any MCP-compatible AI assistant:

Start your MCP server:

   python api.py --mode mcp

Configure your AI assistant (e.g., Claude) to use this MCP server. For Claude Desktop, you'd point it to your running MCP server.
The AI assistant will be able to:
- Discover the available tools (get_weather and get_current_time)
- Call these tools when appropriate during conversations

Best Practices

Environment Variables: Store API keys and credentials in a .env file
Error Handling: Add proper error handling in both tool implementations
Logging: Add comprehensive logging for debugging purposes
Authentication: Add authentication for production deployments
Testing: Write unit tests for your tools and integration tests for your endpoints

Common Issues and Solutions

Agent Not Found in FastAPI: Make sure AGENT_DIR is set to the parent directory containing your agent subdirectory
MCP Tool Conversion Errors: Ensure your tool functions have proper type hints
Module Import Errors: Check your __init__.py files export the required objects

Conclusion

You now have a flexible codebase that can:

Run as a standalone ADK agent
Serve as a FastAPI web application with a UI
Function as an MCP server for AI assistants

This approach gives you multiple deployment options from the same codebase, making your AI agent more versatile and accessible.

Journey to Serverless on Google Cloud Platform

Timothy Olaleke — Mon, 09 Dec 2019 11:37:30 +0000

Google Cloud’s serverless platform lets you write code your way without worrying about the underlying infrastructure. Deploy functions or apps as source code or as containers. Build full-stack serverless applications with Google Cloud’s storage, databases, machine learning, and more while using your favorite language, runtimes, frameworks, and libraries.

Serverless doesn’t mean there are no servers, instead, it takes the workload of managing a server which removes the needs for handling the configuring, provisioning, load balancing, sharding, scaling, and infrastructure management, so you can focus on building great applications.

Serverless computing (also known as No-Ops) distributes majorly across operational and developer experiences, thus ensuring:

There are no servers to manage or provision
Bills are optimized to what you use
Focus on Code
Scale-up fast
Scale down

Function as a Service (FaaS) and serverless are often used interchangeably, however serverless has more to offer than FaaS.
FaaS platforms take a function from developers, build it into an app, and deploy it in the cloud. *Serverless is much more than just FaaS. *

GCP Serverless Compute Options

Google Cloud provides serverless compute options that can fit into your kind of application. These options span across Event-based applications, HTTP applications and also Containerized applications.

Cloud Functions

Google Cloud Functions is a lightweight compute solution for developers to create single-purpose, stand-alone functions that respond to cloud events without the need to manage a server or runtime environment.
Common Cloud Functions use cases could be Data processing, Webhooks, Lightweight APIs, Mobile backend, IoT

Cloud Functions allows you to trigger your code from Google Cloud Platform, Firebase, and Google Assistant, or call it directly from any web, mobile, or backend application via HTTP.

Cloud Functions supports code written in JavaScript (Node.js), Python, and Go. There are no new languages, tools, or frameworks to learn. All you need to do is bring code — including native libraries you bring to the platform.

Cloud Functions provides a connective layer of logic that lets you write code to connect and extend cloud services. Listen and respond to a file upload to Cloud Storage, a log change, or an incoming message on a Cloud Pub/Sub topic.

Learn more about Cloud Functions.

App Engine

App Engine is a fully managed, serverless platform for developing and hosting web applications at scale. You can choose from several popular languages, libraries, and frameworks to develop your apps, then let App Engine take care of provisioning servers and scaling your app instances based on demand.

Quickly build and deploy applications using many of the popular languages like Java, PHP, Node.js, Python, C#, .Net, Ruby and Go or bring your own language runtimes and frameworks if you choose.

Application Versioning in App Engine allows you easily host different versions of your app, easily create development, test, staging, and production environments.

Traffic Splitting in App Engine enables incoming requests to different app versions, A/B test and do incremental feature rollouts.

App Engine also provides security to your applications by defining access rules with App Engine firewall and leverage managed SSL/TLS certificates by default on your custom domain at no additional cost.

Learn more about App Engine

Cloud Run

Cloud Run is a managed compute platform that automatically scales your stateless containers. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications.

Cloud Run is built on the Knative open-source project, enabling the portability of your workloads across platforms.
Knative offers features like scale-to-zero, autoscaling, in-cluster builds, and eventing framework for cloud-native applications on Kubernetes.

Cloud Run (fully managed) allows you to deploy stateless containers without having to worry about the underlying infrastructure. Your workloads are automatically scaled up or down to zero depending on the traffic to your app. You only pay when your app is running, billed to the nearest 100th millisecond.

Cloud Run for Anthos (on-premises) abstracts away complex Kubernetes concepts, allowing developers to easily leverage the benefits of Kubernetes and serverless together. It provides access to custom machine types, additional networking support, and Cloud Accelerators.

Cloud Run automatically scales up or down from zero to N depending on traffic. It also allows for custom domain mappings and provides SSL for free.

Learn more about Cloud Run

DevOps and Monitoring with serverless

Google Cloud integrate other products into deploying a serverless application and also in monitoring logs.

Deployment to serverless environments such as Cloud Function and App Engine uses Cloud Build in the background and monitoring logs for serverless applications also leverages on Stackdriver.

Cloud Build is a service that lets you easily create continuous integration and delivery (CI/CD) pipelines for your serverless applications.

Stackdriver is a monitoring service that aggregates metrics, logs, and events for your serverless applications running on Google Cloud or on-premises.

DEV Community: Timothy Olaleke

Your AI Coding Agent Deserves Its Own Cloud Machine

Step 0: Get Free Google Cloud Credits

Why a Remote Dev Machine?

The Architecture

Step 1: Create the VM

Step 2: Install Everything on the VM

Step 3: Clone Your Project and Start Services

Step 4: SSH Tunnel to Localhost

Step 5: Run Claude Code in tmux

Step 6: Code from Your Phone with Happy

My Daily Workflow

Cost

Tips

Quick Reference

Run Claude Code on Google Cloud: Use Your GCP Credits for AI Coding, Desktop Control, and More

Run Claude Code on Google Cloud: Use Your GCP Credits for AI Coding, Desktop Control, and More

What You Get

Step 1: Enable Claude in the Model Garden

Step 2: Configure Claude Code

Step 3: Run It

Step 4: Desktop Control on Vertex AI

Pro Tips

Use the global Region

Switch Between Vertex and Direct

Check Your Quotas

TL;DR

Your Browser Has a Remote Control — And Nobody Told You

Your Browser Has a Remote Control — And Nobody Told You

The Three Contenders

Setting It Up (60 Seconds)

Seeing It in Action: agent-browser

Install it:

Fill a form in 4 commands:

Before and after:

The Discovery: Session Sharing

What's happening?

The session sharing table:

How CDP Actually Works (The 2-Minute Version)

Head-to-Head: Features Compared

Playwright MCP (Microsoft)

agent-browser (Vercel Labs)

Raw CDP (DIY)

Using These Tools with AI Coding Agents

With Claude Code (MCP)

With agent-browser (CLI)

With agent-browser --cdp (Authenticated)

Connecting to Electron Apps

The Landscape Is Moving Fast

When to Use What

Use Playwright MCP when:

Use agent-browser when:

Use raw CDP when:

Or combine them:

Get Started Now

The Bottom Line

Give Your AI Agent the Instructions

agent-browser skills

chrome-devtools-mcp skills

Raw CDP skill

Building AI Agents with Google ADK, FastAPI, and MCP

What You'll Learn

Prerequisites

Part 1: Getting Started with Google ADK

Installation

Creating a Basic Agent

Testing Your Agent

Part 2: Integrating with FastAPI

Installation

Creating the FastAPI Wrapper

Running the FastAPI Server

Part 3: Creating an MCP Server

Installation

Adding MCP Server Support

Add Command-Line Argument Support

Testing the MCP Server

Using Your MCP Server with Claude or other AI Assistants

Best Practices

Common Issues and Solutions

Conclusion

Use the `global` Region