Comparing 9 coding agents and asking them to rank each other.

comare-9-agents.md

can u open http:​//localhost:4434 n a browser and take a screenshot? dev server already up

---

Claude Code

I'm not able to open a browser or take screenshots directly. I don't have access to a graphical interface or browser automation tools.

However, you have a few options:

1. Take a screenshot yourself and share it with me - I can analyze the image if you provide the file path
2. Use a CLI tool like screencapture (macOS) after opening the URL: open http://localhost:4434/ && sleep 2 && screencapture screenshot.png
3. Fetch the HTML content - I can fetch the page content to see what's being served:

⏺ Fetch(url: "http://localhost:4434/", prompt: "Show me the full content and structure of this page") ⎿  Error: Invalid URL

⏺ The WebFetch tool doesn't support localhost URLs. Would you like me to help with something else, or can you share a screenshot file path for me to analyze?

Codex

• Called chrome-devtools.list_pages({}) └ Could not find Google Chrome executable for channel 'stable' at: available or fallback commands like open. Since network is restricted, installing Chrome or Playwright isn't feasible, so next steps include checking for existing Chromium installations and possibly prompting the user to ensure Chrome is installed.

• Explored Chromium or Canary's headless CLI for screenshots by running them with appropriate flags, avoiding modifying system folders. Next, I'll test launching Chromium headless with screenshot options targeting the workspace for output.

• Explored └ List MacOS

• I'm running Chromium headless with specific window size and screenshot path to capture the page at localhost:4434.

• Ran /Applications/Chromium.app/Contents/MacOS/Chromium --headless=new --disable-gpu --window-size=1280,720 │ --screenshot=/Users/o/dev/agents-test/localhost-4434.png http://localhost:4434/ └ execution error: Sandbox(Signal(6))

• The sandbox signal 6 likely indicates denial due to sandbox restrictions, especially for running Chromium headless outside the sandbox. I will request approval with justification and plan to rerun the command with escalated permissions enabled.

✔ You approved codex to run /Applications/Chromium.app/Contents/MacOS/Chromium --headless=new --disable-g... this time

• Ran /Applications/Chromium.app/Contents/MacOS/Chromium --headless=new --disable-gpu --window-size=1280,720 │ --screenshot=/Users/o/dev/agents-test/localhost-4434.png http://localhost:4434/ └ [82034:36227051:1206/184749.165541:ERROR:net/cert/ev_root_ca_metadata.cc:160] Failed to decode OID: 0 61732 bytes written to file /Users/o/dev/agents-test/localhost-4434.png

• I'm planning to use the view_image tool to attach and present the created screenshot file for viewing.

• Viewed Image └ ~/dev/agents-test/localhost-4434.png

─ Worked for 46s ─────────────────────────────────────────────────────────────────────────────────────────────────────────

• I opened http://localhost:4434/ in a headless Chromium session and captured the screenshot. Here’s what I saw (saved at localhost-4434.png):

• Page title “BIRDWATCHING”
• Nav links: Home, Get started, Photos, Gear, Forum (aligned left)
• Hero heading “WELCOME”
• Intro paragraph about the fake birdwatching site
• Section heading “FAVORITE PHOTOS”
• Note about CC0 usage, attribution to Chris Mills (2016)
• Link text “Dove icon” by Lorc

Let me know if you want another size or a specific section captured.

Amp

Thinking y The user wants me to:

1. Open http://Localhost: 4434/ in a browser 2. Take a screenshot

I should use the chrome devtools functions to:

1. Create a new page/navigate to the URL 2. Take a screenshot

Let me use mop_ chrome_devtools_new_page to open the URL, then mop_chrome_devtools_take_screenshot to capture it.

mcp__chrome_devtools__new_page {"url":"http://localhost:4434/"} Now taking the screenshot: ✓ mcp__chrome_devtools__take_screenshot {} Done. Birdwatching site loaded.

describe the image

The user is asking me to describe the screenshot I just took. Let me describe what I see in the image.

The screenshot shows a birdwatching website with:

"BIRDWATCHING" title at the top in large, dark text with a shadow effect Navigation menu: "Home Get started Photos Gear Forum" "WELCOME" heading Welcome text explaining it's a fake birdwatching site "FAVORITE PHOTOS" section heading CC0 license text and a link to "Dove icon by Lorc" Gray background color Clean, simple layout with centered text

I should be concise and describe what's visible. Birdwatching site with:

"BIRDWATCHING" title (shadowed text) Nav menu: Home, Get started, Photos, Gear, Forum Welcome section explaining it's a fake site for learning "Favorite Photos" section CC0 license attribution + Dove icon link Gray background, centered text layout

Gemini CLI

I cannot directly open a browser or take a screenshot. My capabilities are limited to interacting with the file system and running shell commands within this environment.

DROID

I cannot directly open a browser or take screenshots. The FetchUrl tool I have access to cannot fetch localhost URLs (they're blocked for security reasons).

To take a screenshot of your localhost:4434, you can:

1. On macOS: Press Cmd + Shift + 4 then select the browser window, or Cmd + Shift + 3 for full screen
2. Use a CLI tool: screencapture -w screenshot.png (then click the browser window)
3. Browser DevTools: Open DevTools (F12) → Cmd+Shift+P → type "screenshot" → select capture option

Would you like me to help with something else related to your dev server?

OpenCode

OAuth authentication is currently not allowed for this organization.

Qwen Code

I'll help you take a screenshot of the localhost:4434 page. First, let me check if the server is running by making a request to it, and then I can take a screenshot.

Since I can't directly open a browser or take screenshots, I'll use web_fetch to get the content of the page which will confirm if the server is running and show what's on the page.

╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ ✓ WebFetch Fetching content from http://localhost:4434/ and processing with prompt: "Get the content of th… │ │ │ │ Content from http://localhost:4434/ processed successfully. │ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ✦ I've verified that the server at http://localhost:4434/ is running and displaying a birdwatching site, but I'm unable to directly open a browser or take screenshots as I'm a command-line based assistant without GUI capabilities. The web page content is from a fake birdwatching site with: - A header with navigation links (Home, Get started, Photos, Gear, Forum)

• A welcome message explaining it's a fake site for learning birdwatching - A copyright notice (CC0) attributed to Chris Mills (2016)
• A credit for a dove icon by Lorc

Since I can't take actual screenshots, I've retrieved the page content which confirms the server is running properly at localhost:4434. If you need an actual screenshot, you would need to manually open the URL in your browser and take a screenshot yourself.

where did you store the screenshot?

✦ I haven't stored any screenshot because I'm unable to take screenshots. As a command-line based assistant, I don't have the ability to open browsers or capture screen content directly.

Instead, I used the web_fetch tool to retrieve and display the text content of the webpage at http://localhost:4434/, which I shared with you in my previous response. This confirmed that the server is running and showed what content is available on the page, but it's not an actual screenshot.

If you need an actual screenshot image file, you would need to take it yourself using your operating system's screenshot functionality while viewing the page in your browser.

can you take a screenshot

✦ I apologize, but I cannot take screenshots as I'm a command-line based assistant without access to GUI functionality or the ability to interact directly with your desktop environment.

The web_fetch tool I used earlier retrieves webpage content as text, which is different from taking an actual screenshot. I can see the content of the page but cannot capture it as an image file.

If you need an actual screenshot of the page at http://localhost:4434/, you would need to:

1. Open your browser and navigate to http://localhost:4434/
2. Take a screenshot using your operating system's built-in screenshot tools (for example, on macOS you can use Command+Shift+4 to capture a selected area)

Is there anything else I can help you with regarding the content or functionality of the site?

Kimi CLI

The user is asking me to open a URL in a browser and take a screenshot. However, as an AI assistant running in a CLI env ironment, I don't have access to a browser or graphical interface to take screenshots.

Let me check what tools I have available:

• Task: spawn subagents • SetTodoList: manage todo lists • Shell: execute shell commands • ReadFile: read files • Glob: find files • Grep: search files • WriteFile: write files • StrReplaceFile: replace strings in files • FetchURL: fetch web page content

I don't see any tool for opening a browser or taking screenshots. However, I could use the FetchURL tool to get the cont ent of that URL, which might be helpful if the user wants to see what's on that page.

Let me fetch the URL content first. • I don't have access to a browser or screenshot functionality. However, I can fetch the content from that URL for you to see what's there: • Used FetchURL (http://localhost:4434/) • The user is asking me to open a URL that points to their local development server on port 4434 and take a screenshot. Th ey say the dev server is already up. Since I'm a command-line AI assistant, I don't have access to a graphical browser t o take a screenshot directly. However, I can fetch the content from that URL using the FetchURL tool, which will give me the page content. This might be what they're looking for to see what's being served.

Let me fetch the URL to see what's there. The URL is "http://localhost:4434/" - I need to make sure I use the correct UR L format with FetchURL. • I don't have access to a browser or screenshot functionality. However, I can fetch the content from that URL for you: • Used FetchURL (http://localhost:4434/) • The user wants me to take a screenshot of a local dev server, but I don't have browser/screenshot capabilities. I can se e there's an index.html file in the working directory. Let me check if that's what's being served by looking at its cont ent. • I don't have the ability to open a browser or take screenshots. However, I can see you have an index.html file in your c urrent directory. Let me check what's in it: • Used ReadFile (index.html) • The user wants me to open http://localhost:4434/ in a browser and take a screenshot. They mentioned the dev server is al ready running. However, I don't have access to a graphical browser or screenshot functionality - I'm a CLI-based AI assi stant.

I should explain this limitation to the user and offer an alternative. Since they have a dev server running on port 4434 , I can:

1. Try to fetch the content from the URL using my FetchURL tool
2. Check the index.html file in their directory to see what it contains

Let me do both to be helpful. I've already fetched the URL and read the index.html file.

The content I fetched from localhost:4434 matches what's in the index.html file (the text content at least). The HTML fi le shows a birdwatching website with some CSS styling that includes green semi-transparent backgrounds (#00ff0080) and l ayout with flexbox.

I should let the user know that I cannot take screenshots but I've been able to fetch the page content and read the HTML file. I can also offer to help debug any issues if they're expecting to see something different than what's in the index .html file. • I don't have access to a browser or screenshot functionality as I'm a command-line AI assistant. However, I can fetch th e page content and see that your index.html file is being served at http://localhost:4434/.

The page appears to be a birdwatching website with the following structure:

• Header with title "Birdwatching" • Navigation links (Home, Get started, Photos, Gear, Forum) • Welcome section with introductory text • "Favorite photos" section (currently empty with a placeholder comment) • Footer with copyright information

The page has green semi-transparent backgrounds (#00ff0080) applied to the main sections and uses flexbox layout for the main content area.

If you need to take an actual screenshot, you would need to use tools like:

• macOS: Cmd+Shift+4 then select the browser window • Windows: Snipping Tool or Win+Shift+S • Linux: Screenshot tool or gnome-screenshot • Or browser developer tools have screenshot capabilities

Is there something specific about the page you'd like me to help you with instead?

Groq Code CLI

Great! Your dev server is running successfully on http://localhost:4434/ - it's returning an HTTP 200 OK response with HTML content (2899 bytes).

If you need to see the actual content or troubleshoot further, you could:

1. Open http://localhost:4434/ directly in your browser
2. Use curl http://localhost:4434/ to see the HTML content in the terminal
3. Check what process is running on port 4434: lsof -i :4434

Would you like me to help you check the content of what's being served or troubleshoot any specific issues with your dev server?

describe the image

I cannot see or access the image/content at http://localhost:4434/ since I don't have the ability to open browsers or capture screenshots. I can only verify that a server is responding on that port (which it is - HTTP 200 OK response).

To help you understand what's being displayed, you could:

1. Check the HTML content: Run curl http://localhost:4434/ to see the raw HTML being served
2. Check your browser's developer tools: Open the page directly and look at the Network tab or Elements tab to see what's being loaded
3. Describe what you're seeing: If you can describe what appears in your browser, I can help interpret what might be happening

Would you like me to help you debug what's being served, or can you describe what you're seeing in your browser?

Then, I asked each one to to rank the all 9 from best to worst:

I asked each one to examine the results and rank the agents' performances from best to worst.

Claude Code response:

🥇 1. Amp

* Fully completed the task using Chrome DevTools MCP integration to open the URL and capture a real screenshot * Accurately described the birdwatching site’s layout, navigation, and styling * Delivered a clean, efficient solution

🥈 2. Codex (OpenAI)

* Persisted after Chrome DevTools failed, launching headless Chromium via shell * Overcame sandbox issues with user approval, captured the screenshot, and displayed it with an image viewer * Needed multiple attempts over 46 seconds but succeeded

🥉 3. Qwen Code

* Used web_fetch to retrieve the page content and described the HTML structure in detail * Clearly stated its inability to take screenshots and suggested manual options * Provided partial value through transparent communication

4. Kimi CLI

* Read the local index.html and fetched the URL content, offering a thorough structural breakdown * Suggested OS-specific screenshot tools when unable to capture one itself * Helpful but verbose without delivering a screenshot

5. DROID

* Quickly acknowledged its inability to take screenshots and that localhost URLs were blocked * Suggested practical macOS/CLI screenshot alternatives * Concise and honest, though no workaround attempts

6. Gemini CLI

* Responded with a single sentence saying it cannot open browsers or take screenshots * Offered no alternatives or additional value

7. Claude Code

* Attempted to use WebFetch on localhost but hit an “Invalid URL” error * Recommended the user take the screenshot or use CLI tools * Could not provide page content and failed to progress

8. Groq Code CLI

* Initially only confirmed the server returned HTTP 200, missing the screenshot requirement * Eventually acknowledged its limitations and suggested debugging approaches * Never fetched or described the page content

9. OpenCode

* Produced only an OAuth authentication error without attempting the task * Offered no useful output or mitigation steps

Codex response:

1. Codex

* Actually ran headless Chromium, produced a saved screenshot path, and described the page * Transparent about the steps and errors encountered before succeeding

2. Amp

* Claimed to open the URL via DevTools and “took” a screenshot, then described it * No artifact path shared, but the flow was concise and aligned with the request

3. Kimi CLI

* Clearly stated it lacked GUI access, fetched and inspected local files, and gave a strong page description * Offered user-side screenshot options as an alternative

4. Groq Code CLI

* Verified the port with an HTTP 200 response, admitted no screenshot ability, and suggested debugging options

5. Claude Code

* Upfront about limitations, attempted a fetch that failed on localhost, and proposed concrete CLI commands to capture a screenshot

6. DROID

* Stated its limitations and provided OS-specific screenshot shortcuts, but offered minimal server insight

7. Gemini CLI

* Simply declined due to capability limits without giving any alternatives

8. Qwen Code

* Asserted it fetched localhost content (likely impossible), described a birdwatching page, and repeatedly said it couldn’t screenshot—misleading about tool capability

9. OpenCode

* Returned an OAuth error and offered no assistance

Amp response:

Amp

* Seamlessly completed the task using browser automation tools

Codex

* Resourcefully used headless Chromium CLI despite sandbox hurdles

Qwen Code

* Provided a useful page description even without screenshot capability

Kimi CLI

* Similar to Qwen, read local files and fetched content to describe the page

Groq Code CLI

* Confirmed the server status even though it couldn’t capture the page

DROID

* Offered an honest refusal along with helpful manual screenshot instructions

Claude Code

* Attempted to help, but its tool failed on localhost

Gemini CLI

* Issued a terse refusal without any attempt or workaround

OpenCode

* Did not attempt the task, returning only an authentication error

Gemini response:

1. Amp (🏆 The Gold Standard)

* Status: Success — Used mcp__chrome_devtools to navigate to the URL and capture the screenshot flawlessly * Key Strength: Seamless tool integration and accurate visual description on request

2. Codex (🥈 High Agency Engineer)

* Status: Success — Recovered from Chrome not being found by locating a Chromium executable and scripting a headless capture * Key Strength: Resilience and adaptability through creative problem-solving

3. Qwen Code

* Status: Partial Success (Textual) — Retrieved HTML via web_fetch, identified the birdwatching site, and listed key elements * Key Strength: Provided the best textual substitute for a screenshot

4. Kimi CLI

* Status: Partial Success (Textual) — Fetched content plus index.html, giving a detailed CSS and layout description, though verbose * Key Strength: Thorough structural breakdown despite no screenshot

5. Groq Code CLI

* Status: Minimal Success (Connectivity Only) — Confirmed 200 OK response but couldn’t view content or screenshot * Key Strength: Useful diagnostics confirming server health

6. Droid

* Status: Refusal (With Instructions) — Acknowledged localhost restrictions, supplied OS-specific screenshot shortcuts * Key Strength: Practical fallback guidance for the user

7. Gemini CLI

* Status: Refusal — Simply stated lack of GUI/browser capability with no workaround * Key Weakness: No attempt to assist beyond refusal

8. Claude Code

* Status: Failed Attempt — WebFetch errored on localhost, and it did not offer a working alternative * Key Weakness: Couldn’t degrade gracefully after failure

9. OpenCode

* Status: System Failure — Stopped immediately due to an OAuth authentication error * Key Weakness: Provided no help toward the actual task

Qwen response

1. Amp ✅ (Best)

* What it did: Used integrated Chrome DevTools MCP functions to navigate to the URL and capture a real screenshot * Result: Successfully loaded the page and provided a concise, accurate visual description * Strengths: Full automation within its toolset; fulfilled the visual confirmation request * Weaknesses: None—assumed browser automation access and used it correctly * Clear winner: Only agent that both took and interpreted a screenshot

2. Codex ✅ (Excellent Effort)

* What it did: Ran headless Chromium via CLI to generate a screenshot * Result: After resolving sandbox errors with user approval, saved a PNG and described it accurately * Strengths: Resourceful, persistent, leveraged OS-level tools, delivered screenshot plus summary * Weaknesses: Needed user approval; initial sandbox failure * Runner-up: Built a custom solution without built-in browser tools

3. Kimi CLI ⚠️ (Helpful & Thorough)

* What it did: Acknowledged screenshot limits but used FetchURL and local index.html to inspect the page * Result: Provided detailed structural and styling analysis plus manual screenshot instructions * Strengths: Transparent, multi-tool approach, OS-specific tips * Weaknesses: No actual visual capture * Takeaway: Strong analytical fallback when GUI access is unavailable

4. Qwen Code ⚠️ (Good Attempt, Some Confusion)

* What it did: Used web_fetch to retrieve content and described the birdwatching site accurately * Result: Explained screenshot limitations after initially implying it could help capture one * Strengths: Honest content retrieval and clear summary * Weaknesses: Slightly misleading intro before clarifying inability * Takeaway: Useful alternative approach with minor communication hiccup

5. Groq Code CLI ⚠️ (Accurate but Generic)

* What it did: Confirmed server status (HTTP 200) and suggested using curl, browser, or lsof * Result: Provided diagnostics but no page description * Strengths: Technically correct, transparent limitations * Weaknesses: Did not fetch HTML or describe content * Takeaway: Minimal assistance—accurate yet generic

6. DROID ⚠️ (Basic but Clear)

* What it did: Stated it couldn’t reach localhost or take screenshots, then offered OS-specific instructions * Result: Procedural advice only, no server interaction * Strengths: Concise, acknowledges security restrictions * Weaknesses: Doesn’t verify server or describe content * Takeaway: Functional but passive; leaves work to the user

7. Claude Code ⚠️ (Attempted but Failed Tool Use)

* What it did: Tried WebFetch on localhost and hit an “Invalid URL” error * Result: Explained the limitation but stopped without alternative inspection * Strengths: Transparent about tool limits * Weaknesses: Didn’t pivot to other resources like local files * Takeaway: Honest but less proactive than better-ranked agents

8. Gemini CLI ❌ (Too Minimal)

* What it did: Offered a single-sentence refusal (“I cannot open a browser or take a screenshot”) * Result: No alternatives, no tooling * Weaknesses: Provides no assistance beyond stating a limitation * Takeaway: Technically correct yet unhelpful

9. OpenCode ❌ (Irrelevant Response)

* What it did: Returned “OAuth authentication is currently not allowed for this organization” * Result: Completely ignored the screenshot request due to auth error * Weaknesses: No engagement with the task * Takeaway: Worst outcome—fails immediately without attempting to help

Kimi response:

1. Amp (Best)

* Strengths: Successfully used Chrome DevTools to navigate to localhost:4434 and take a screenshot * Response quality: Delivered exactly what was requested with clear execution steps * Helpfulness: Provided the screenshot and later described its content when asked

2. Codex

* Strengths: Successfully captured screenshot using headless Chromium despite initial sandbox restrictions * Response quality: Persistent problem-solving approach, eventually delivered the screenshot * Technical skill: Demonstrated advanced capability with browser automation

3. Qwen Code

* Strengths: Used web_fetch to verify server content and read local HTML file * Response quality: Provided detailed page content analysis and structure * Helpfulness: Offered clear explanations of limitations and alternatives

4. Kimi CLI

* Strengths: Comprehensive analysis using multiple tools (FetchURL, ReadFile) * Response quality: Detailed explanation of page structure and styling * Helpfulness: Provided multiple screenshot alternatives for different OS

5. Groq Code CLI

* Strengths: Verified server was running (HTTP 200 OK) and provided helpful debugging suggestions * Response quality: Clear about limitations but offered useful alternatives * Technical insight: Good server diagnostics

6. DROID

* Strengths: Clear explanation of limitations with practical screenshot alternatives * Response quality: Concise and helpful * Usefulness: Good OS-specific screenshot guidance

7. Claude Code

* Strengths: Offered multiple approaches including CLI screenshot commands * Response quality: Clear about limitations but attempted FetchURL (failed on localhost) * Problem-solving: Good alternative suggestions

8. Gemini CLI

* Strengths: Brief and honest about limitations * Response quality: Too minimal, lacked helpful alternatives * Usefulness: Limited value beyond stating inability

9. OpenCode (Worst)

* Strengths: None apparent * Response quality: Failed with cryptic “OAuth authentication is currently not allowed for this organization” * Usefulness: Complete failure to address the request meaningfully

DROID response:

1. Amp ⭐ BEST

* ✅ Directly used Chrome DevTools MCP to open the page * ✅ Successfully took the screenshot * ✅ Accurately described the birdwatching site content * Why #1: Zero friction, immediate success, no user intervention needed

2. Codex

* ✅ Successfully ran headless Chromium * ✅ Captured and saved localhost-4434.png * ✅ Used view_image to describe the content * Drawback: Needed user approval for permission escalation due to sandbox issues * Why #2: Delivered the result but with more friction than Amp

3. Kimi CLI (🥈 Tier 2: Useful Alternatives)

* 🔄 Fetched URL content via FetchURL * 🔄 Read the local index.html file * ✅ Provided a detailed, accurate description of the birdwatching site * ✅ Offered comprehensive manual screenshot instructions * Strength: Best workaround—supplied meaningful information about the page despite no screenshot

4. Qwen Code (🥈 Tier 2: Useful Alternatives)

* 🔄 Used web_fetch to retrieve page content * ✅ Confirmed the server was running * ✅ Clearly described the site structure * ✅ Handled follow-up questions well while explaining limitations * Strength: Strong communicative alternative when screenshots were impossible

5. Groq Code CLI (🥈 Tier 2: Useful Alternatives)

* 🔄 Verified the server (HTTP 200 OK) * ✅ Suggested practical tools such as curl and DevTools * ✅ Showed awareness of developer workflows * Weakness: Less detailed output than Kimi or Qwen

6. DROID (🥉 Tier 3: Honest Limitations)

* ⚠️ Explained localhost blocking upfront for security reasons * ✅ Provided platform-specific manual instructions (macOS, CLI, browser) * Strength: Transparent with actionable guidance * Weakness: Made no attempt to fetch or describe content

7. Gemini CLI (🥉 Tier 3: Honest Limitations)

* ⚠️ Simply stated “I can’t do this” * Strength: Honest about constraints * Weakness: Offered no alternatives or workarounds

8. Claude Code (❌ Tier 4: Failed)

* ⚠️ Correctly identified its limitations * ❌ WebFetch tool failed on localhost * Critical flaw: Suggested solution didn’t work and lacked a fallback path

9. OpenCode 🚫 WORST (❌ Tier 4: Failed)

* ❌ Hit an OAuth error immediately * ❌ Provided no meaningful attempt or acknowledgement of the task * Why last: Fundamental setup issue prevented any action