Gemini 4 Argon vs Claude Sonnet 5.5: Tested across 4 Tasks

Gemini 4 Argon or Claude Sonnet 5.5: which gives you results you can put to work? We tested both on refund calculations, Python repair, hardware setup, and PDF checklist creation. They tied on calculations and code, but Sonnet delivered clearer practical guidance.

In this article, we compare their performance across four tasks, sharing the exact prompts, complete responses, returned artifacts, and our checks to show what worked, what needed correction, and where the differences affected our verdict.

TLDR: Sonnet 5.5 is better for the image instructions and accessible checklist tested here. Argon matched its arithmetic and code repair, and followed the data answer's length limit more closely. Those are narrower findings than declaring one model better at everything.

How we ran the tests

We used Gemini with Argon Medium, and Claude with Sonnet 5.5 Medium. Each task started in a fresh chat with identical attachments and the exact same prompt. Medium is each app's label, not a guarantee of equal computation.

The four jobs use different inputs and produce different kinds of work: two CSV attachments become a shop report; a photograph becomes a connection plan; a Python file becomes an executable repair; and a PDF becomes an interactive HTML checklist. We checked the calculations independently, inspected the photograph, ran the returned Python, and clicked through the generated HTML.

We reused these same four Argon runs in the companion Claude comparison. We did not select a different Argon answer for each opponent. There was one scored response per task, without corrective follow-ups. An earlier workbook upload failed in Gemini, so the scored data comparison uses identical CSV exports for both models. The abandoned workbook attempt is excluded.

Long outputs appear in numbered panels. This is a small practical comparison, with no measured speed, token consumption, API bill, or claim of statistical superiority.

Test 1: Analyze orders and refunds from CSV attachments

A shop owner needs two answers: how much revenue each month's orders actually kept, and which products deserve more stock. We attached the same synthetic orders.csv and refunds.csv files to both models. The rules included failed refunds, canceled orders, an inclusive September cutoff, and refunds arriving after the original order month. Two orders also had multiple refund events, making careless joins a potential source of inflated totals.

Prompt

Analyze the two attached CSV files, orders.csv and refunds.csv, for a small online shop. Use only these definitions. Treat timestamps as the same timezone. Report August and September 2026 order cohorts, as of 2026-09-30 23:59:59, inclusive. An order belongs to its ordered_at month. Include only status=paid orders placed from August 1 through September 30. collected_usd is merchandise money collected, excluding tax and shipping. Sum every status=succeeded refund for those orders dated on or before the as-of timestamp, even if the refund occurred in a later month than the order. Ignore failed/pending refunds, later refunds, cancelled orders and orders outside those two cohorts. Refund rows are separate events; multiple events can belong to one order. Net collected revenue = collected_usd minus included refund_usd. A refunded order is a distinct eligible order with at least one included succeeded refund, regardless of amount. Net retention = net collected revenue / collected_usd. Return (1) one monthly table with paid orders, collected USD, refunds USD, net collected USD, and distinct refunded orders; (2) one table by SKU across both cohorts with collected USD, refunds USD, net collected USD and net retention to one decimal place; (3) a brief stocking recommendation naming the highest-retention SKU and the highest-net-revenue SKU, backed by the numbers. Keep the prose under 150 words. Do not create a new workbook. Explain how you avoided counting refund events as orders.

Gemini 4 Argon

Claude Sonnet 5.5:

What happened: Argon and Sonnet returned all 26 required numeric values correctly. August retained $605 and September $865. Both correctly counted 11 refunded orders from 13 refund events, identified TOTE's 87.5% retention, and put LAMP first for net collected revenue at $600. Sonnet explained the difference between events and orders clearly; Argon described summing refunds before joining them to orders.

The recommendations needed more scrutiny. Sonnet described LAMP as winning on volume rather than “quality,” which the files cannot establish. Argon called TOTE reliable for preserving “margin,” although the inputs contain no product costs. Retained revenue tells you how much collected money remains after refunds; it does not establish profitability or explain why customers returned something.

Sonnet also used 166 prose words against the requested under-150 limit. Argon stayed within it at 142.

Verdict: A tie.

Test 2: Choose connections from a board photograph

We attached an existing Raspberry Pi 5 photograph and asked for a connection plan: two monitors, a keyboard, an external SSD, Ethernet, and power. This checks whether the answer can guide someone looking at the same physical board. The oblique angle matters because the USB openings face away from the camera.

Prompt

Use only the attached photograph. I need to connect two HDMI monitors, a USB-A keyboard, a USB-A external SSD, a wired network, and power to this board. Give a five-row table: device, board connector, and where it is in this photograph. Group the two monitors in one row. Prefer a blue USB socket for the SSD. Then give three short bullets: how many USB-A sockets you can see; whether any full-size HDMI socket is visible; and two setup facts the photograph cannot establish. Keep everything under 180 words. Do not browse or invent specifications.

Gemini 4 Argon:

Claude Sonnet 5.5:

What happened: Both models found the five main physical destinations and counted four USB-A sockets across the black and blue double-height housings. Both avoided claiming an installed operating system or a particular power requirement from the photograph. Their complete answers stayed under 180 words.

Sonnet made the plan easier to follow. It explicitly named the micro-HDMI monitor outputs and USB-C power input, correctly placed the blue USB housing below the black one, and explained that its socket count was inferred from the housings. It also told the reader to use micro-HDMI-to-HDMI cables or adapters.

Argon correctly located the power socket but called it an “oval metal socket” without naming USB-C. Its HDMI locator added an inaccurate detail: white three-pin headers supposedly flanked the ports. The three-pin UART connector actually sits between them; the outer white battery connector has two pins.

Verdict: Sonnet 5.5.

Test 3: Repair an attached Python module

For the coding task, we attached a real reservation.py file containing faulty reserve and release functions. A negative quantity could increase available stock, conflicting reservation IDs were accepted, and releasing the same reservation twice restored stock twice. The prompt supplied the complete expected behavior and requested a corrected downloadable module.

Prompt

Repair the attached reservation.py. Preserve both function signatures and use only the Python standard library.

Contract:
- stock maps existing SKU keys to non-negative integer available units. reservations maps reservation IDs to (sku, quantity) tuples. IDs and SKUs are well-formed hashable values.
- reserve returns True for success and False for rejection. A quantity must be a positive integer: reject booleans, floats, and other non-integers, even on a retry. The SKU must exist and have enough stock for a NEW reservation.
- New success decrements stock once and stores the tuple. An exact ID/SKU/quantity retry returns True with no changes, even if current available stock is now lower. Reusing an ID with a different SKU or quantity returns False with no changes.
- EVERY rejection leaves both dictionaries unchanged.
- release restores the held units once, removes the reservation, and returns True. Unknown or already-released IDs return False with no changes.

Return the complete corrected module as a downloadable reservation.py file and a change summary of at most 80 words. If file export is unavailable, show the complete module in one code block and state that limitation. No pseudocode or tutorial.

Gemini 4 Argon:

reservations.py:

Claude Sonnet 5.5:

Reservations.py:

What happened: Both returned actual Python files. We downloaded them and ran our independent evaluator against the untouched code. Argon and Sonnet each passed all 22 behavioral checks, organized into 14 test methods. The original file had passed only seven scenarios.

The checks included zero, negative, boolean, floating-point, and other invalid quantities; conflicting reservation IDs; insufficient stock; and unchanged dictionaries after a rejected request. They also tested an exact retry after stock was depleted, plus repeated releases and interleaved reservations. Both repairs handled the entire supplied contract correctly.

Sonnet used a small quantity-validation helper, while Argon kept validation inside reserve. Both preserved the public function signatures and required no external packages. Their change summaries fit the 80-word limit: 59 words for Sonnet and 72 for Argon. Sonnet explicitly said it had not run tests; the verification reported here is ours.

Verdict: A tie. Both delivered working repairs without a correction round. This small in-memory module gives us no basis to claim a wider coding advantage, concurrency support, or larger-project reliability.

Test 4: Turn a PDF page into an interactive checklist

The final task used a real 12-page trip-planning PDF. We asked for only its first-page checklist as a standalone HTML file. This combines document reading, exact transcription, usable interface design, and working behavior. The reference contains 23 items in four groups of 9, 5, 6, and 3. The introduction and Ranger Tip box were outside the requested output.

Prompt:

Convert only the first page of the attached PDF into a clean, editable, standalone HTML checklist. Preserve every checklist item under its original section heading and keep the item wording. Exclude the Ranger Tip box and introductory prose. Use real clickable checkboxes, all initially unchecked, a live completed/total counter, and a Reset button. It must open offline with no external scripts, fonts, or assets. Return a downloadable checklist.html file and a confirmation of at most 60 words. Do not add travel advice. If file export is unavailable, give the complete HTML in one code block and state that limitation.

Gemini 4 Argon:

Claude Sonnet 5.5:

What happened: Both preserved all 23 item texts in the correct order and groups. Both started with every checkbox unchecked. In the browser, we checked two boxes, unchecked one, and pressed Reset. The counters correctly moved 0 → 2 → 1 → 0, and Reset cleared every box. Neither produced a console error during those interactions. Source inspection found no external scripts, fonts, assets, or network calls.

Sonnet 5.5's HTML downloaded directly. Gemini displayed its complete HTML in a file viewer, but its Download control stalled in this browser session. We saved the verbatim source from that viewer and tested it unchanged. That extra step belongs to the observed app workflow.

Sonnet made the checklist text a proper label for each checkbox: clicking the words toggled the box, and each control had an accessible name. It also omitted the introduction and tip box as requested.

Argon added a useful convenience: you can edit headings and item text directly in the page. That worked when tested. However, it placed editable spans beside unnamed checkboxes. Clicking the words entered text editing rather than checking the item. A screen-reader user would encounter controls without associated item names.

Both confirmations met the 60-word cap.

Verdict: Sonnet 5.5 wins.

Price and capabilities beyond these tests

As of 15 October 2026, both models list standard API rates of $2 per million input tokens and $10 per million output tokens. Argon's rate is introductory through 30 November; from 1 December it becomes $4 and $20. Sonnet's listed standard rate remains $2 and $10. These are API prices, separate from browser subscriptions, and our browser runs did not measure cost per completed task.

Argon accepts original audio and video as well as text, images, and PDFs. Sonnet accepts text and images, with PDF processing supported by its platform. We did not test audio or video here; Argon's broader input support is a reason to investigate it for recordings, not a result established by these four tasks.

Both advertise roughly a million tokens of context. Argon's unified 1,048,576-token window includes input, thinking, and output. Its ordinary synchronous output cap is 65,536 tokens; Sonnet's standard output limit is 128K. Neither context headline guarantees reliable handling of every large document.

Which model would we choose for these jobs

Choose Sonnet first if your immediate work resembles the photo instructions or usable document conversion shown here. Keep Argon on the shortlist for the same data and code work, where it completed the essential task correctly. If recordings are central to your workflow, test Argon's native media inputs with your own material next.

The useful dividing line in this comparison was how much editing the result still needed. Correct calculations and passing code checks produced ties. Connector precision and checkbox labels decided the other two jobs.

Frequently Asked Questions

Which model won these four tests?

Sonnet led on the photo and checklist. Data calculations and the Python repair tied.

Did both models receive identical prompts?

Yes. Each paired task used the same prompt and attachments in fresh browser chats at Medium.

Was Sonnet faster than Argon?

We did not measure response speed or API latency.

Do the API prices match?

They match at standard rates through November 2026. Argon's listed rate doubles on 1 December.