DEV Community: Rai Ansar

Rounding race splits so they still add up to the goal time

Rai Ansar — Fri, 06 Nov 2026 06:44:39 +0000

A split table for a race looks like plain division. Take the goal time, divide it by the distance, and print one row per checkpoint. Runners read those rows off a paper pace band or a watch in the middle of a race, so every row has to be a whole number of seconds. Rounding is where the plain version goes wrong.

Rounding each segment

Take a 4:00:00 marathon. The distance is 42.195 km, so with a checkpoint every kilometre you get 42 full kilometres and a last segment of 0.195 km. The obvious code works out each segment's time and rounds it:

const total = 4 * 3600; // 14,400 s
const distance = 42.195; // km
const points = [...Array(42)].map((_, i) => i + 1).concat(distance);

let previous = 0;
const segments = points.map((point) => {
  const seconds = Math.round((total * (point - previous)) / distance);
  previous = point;
  return seconds;
});

segments.reduce((a, b) => a + b, 0); // 14,389

A full kilometre at that pace takes 341.27 seconds, which rounds down to 5:41. Lose 0.27 seconds 42 times and the table for a 4:00:00 race ends at 3:59:49, 11 seconds short.

The error can go either way. At a 3:30:00 goal the same code rounds every kilometre up and the table ends at 3:30:16. Fewer checkpoints means less drift, yet the 4-hour table still ends at 3:59:54 with mile checkpoints and at 3:59:57 with one every 5 km.

The elapsed column is worse than the total. It is the number a runner compares with the race clock, and with kilometre splits it drifts up to about 11.5 seconds away from the exact plan before the last segment.

Round the elapsed time, then subtract

The fix is to round the running total instead of each piece. Work out the exact elapsed time at each checkpoint, round that, and make each segment the difference between two rounded elapsed times.

function allocate(weights: number[], total: number) {
  const sum = weights.reduce((a, b) => a + b, 0);
  const segments: number[] = [];
  let cumulative = 0;
  let previous = 0;
  weights.forEach((weight, i) => {
    cumulative += weight;
    const remaining = weights.length - 1 - i;
    let elapsed =
      i === weights.length - 1 ? total : Math.round((total * cumulative) / sum);
    // keep every segment at least 1 s long
    elapsed = Math.min(Math.max(elapsed, previous + 1), total - remaining);
    segments.push(elapsed - previous);
    previous = elapsed;
  });
  return segments;
}

The weights here are segment lengths in kilometres. Every elapsed time lands within half a second of the exact plan. The last one is set to the goal itself, so the table always finishes on the goal time.

The segments now alternate. For the 4:00:00 marathon with kilometre splits, each kilometre is 5:41 or 5:42. With a checkpoint every 5 km, the segments are 0:28:26 or 0:28:27, the final 2.195 km takes 0:12:29, and the 9 rows add up to exactly 4:00:00.

The clamp line covers a corner case. A goal of a few seconds over many checkpoints could round two elapsed times to the same second, which would print a 0-second segment. The clamp gives every segment at least one second, and the calculator rejects a goal shorter than the number of checkpoints before it gets here.

Keep the last partial segment

A marathon is 26.2188 miles, and some calculators round it to 26.2. At 4:00:00 that's 9:09.6 per mile, which shows as 9:10. The true figure is 9:09.2, which shows as 9:09. When I checked the top 5 US and UK results for "marathon split calculator" on 24 September 2026, two of them left out the final 0.2188 miles altogether and one used 26.2 miles.

On an even 4:00:00 plan, mile 26 comes at 3:58:00, so the final 0.2188 miles takes two minutes. The checkpoint list has to end on the real distance:

const MILE_KM = 1.609344; // exact, by definition

function checkpoints(distanceKm: number, stepKm: number) {
  const points: number[] = [];
  for (let i = 1; i * stepKm < distanceKm - 1e-9; i++) points.push(i * stepKm);
  points.push(distanceKm);
  return points;
}

The loop stops before the finish and then adds the exact distance, so the last segment is whatever is left over: 0.195 km, 2.195 km or 0.2188 miles, depending on the spacing. The small tolerance stops float noise from adding a second checkpoint on top of the finish.

Pacing shapes reuse the same rounding

Because allocate takes weights rather than distances, pacing shapes need very little extra code. For a negative split, the pace multiplier runs in a straight line from 1.02 at the start to 0.98 at the finish, and each segment's weight is its length times the multiplier at its midpoint:

const SLOPE = 0.02;
const multiplier = (fraction: number) => 1 + SLOPE * (1 - 2 * fraction);

let previous = 0;
const weights = points.map((point) => {
  const midpoint = (previous + point) / 2;
  const weight = (point - previous) * multiplier(midpoint / distance);
  previous = point;
  return weight;
});

The value of a straight line at the midpoint of a segment times its length is the exact integral over that segment, so the shape doesn't depend on where the checkpoints fall. Split a 4:00:00 marathon into halves and the negative plan gives 2:01:12 and 1:58:48, a 50.5% and 49.5% split. A positive split swaps the two. Every plan still finishes on 4:00:00, because it is the same allocation underneath.

The printed pace band on the site takes its rows from the same plan. If you want to see the output, the marathon split calculator on Race Pace Planner shows the even, negative and positive tables side by side for any goal time, with a Segment column and an Elapsed column built this way.

Payroll math has dates in it: modelling Ireland's October PRSI change

Rai Ansar — Wed, 28 Oct 2026 08:34:23 +0000

Most take-home pay calculators I've read share one shortcut: they turn every deduction into an annual rate and multiply. For Irish pay in 2026 that shortcut gives the wrong answer, because one of the three deductions changes rate partway through the year.

I hit this while building Irishtakehome, a take-home calculator for Irish salaries. This post walks through the model with one worked example: a single employee on €45,000, paid weekly, with no pension. All rates below are the 2026 rules as of 15 October 2026.

Three charges, three bases

Irish payroll takes three separate charges out of a salary, and each one is worked out on a different base.

Income tax (PAYE) is banded, then reduced by credits. A single person pays 20% on the first €44,000 of taxable pay and 40% on the rest. The personal tax credit (€2,000) and the employee tax credit (€2,000) come off the tax itself, not off the pay.

20% of €44,000      = €8,800
40% of €1,000       =   €400
less credits        = −€4,000
PAYE                = €5,200

USC (Universal Social Charge) has its own bands:

Slice of income	Rate
First €12,012	0.5%
Next €16,688 (up to €28,700)	2%
Next €41,344 (up to €70,044)	3%
Balance over €70,044	8%

On €45,000 that's €60.06 + €333.76 + €489.00 = €882.82.

USC also has a threshold that behaves differently from a band. Income of €13,000 or less pays no USC at all, but once you go over it, USC applies to all of your income from the first euro. If you write this as a marginal band, people just above €13,000 get the wrong figure.

PRSI (social insurance, Class A employee) is charged per pay period, on the whole of that period's pay. Weekly pay from €38 to €352 pays nothing. Above €352, the rate is:

4.2% of the whole week's pay for pay dates up to 30 September 2026
4.35% of the whole week's pay for pay dates from 1 October 2026

Between €352.01 and €424 a week a credit of up to €12 reduces the charge. I've left that band out of the code below to keep it short; our example pays €865.38 a week, well above it.

Why an annual rate is wrong here

If you treat PRSI as one rate for the year you get one of these:

flat 4.2%  on €45,000 = €1,890.00   (too low)
flat 4.35% on €45,000 = €1,957.50   (too high)

The real figure depends on how many pay dates fall on each side of 1 October. PRSI is worked out on each pay period, so the rate that applies is the one in force on the pay date. Here is the model I ended up with:

from datetime import date, timedelta
from decimal import Decimal, ROUND_HALF_UP

CENT = Decimal("0.01")
RATE_CHANGE = date(2026, 10, 1)

def weekly_prsi(weekly_pay: Decimal, pay_date: date) -> Decimal:
    if weekly_pay <= Decimal("352"):
        return Decimal("0")  # nil band (the credit band from €352.01 to €424 is left out here)
    rate = Decimal("0.042") if pay_date < RATE_CHANGE else Decimal("0.0435")
    return (weekly_pay * rate).quantize(CENT, ROUND_HALF_UP)

salary = Decimal("45000")
weekly = salary / 52
first_pay = date(2026, 1, 2)          # 52 Friday pay dates in 2026
pays = [first_pay + timedelta(weeks=i) for i in range(52)]

total = sum(weekly_prsi(weekly, d) for d in pays)
before = sum(1 for d in pays if d < RATE_CHANGE)
print(f"pays at 4.2%: {before}, at 4.35%: {52 - before}")
print(f"PRSI for the year: €{total}")

Output:

pays at 4.2%: 39, at 4.35%: 13
PRSI for the year: €1906.97

Thirty-nine Friday pays fall before 1 October and thirteen after. Each week's charge is rounded to the cent on its own, as it is on a payslip, so the year comes to €1,906.97, between the two flat figures. The last thirteen payslips of the year each take a little more PRSI than the first thirty-nine, and a model with one annual rate can't show that.

Putting it together

Salary              €45,000.00
PAYE                −€5,200.00
USC                   −€882.82
PRSI                −€1,906.97
Take-home pay       €37,010.21   (82% kept)

The pension trap

The other place a single rate lets you down is pension contributions. A contribution taken from pay by an employer's approved scheme lowers the pay PAYE is worked out on. It doesn't lower the pay USC and PRSI are charged on. So if your model subtracts the pension from gross pay once and then runs all three charges on the result, it overstates the saving.

In code, that means keeping two bases instead of one:

paye_base = gross - pension_contribution
usc_base = gross
prsi_base = gross

Tax relief on the pension also has an age-related cap (15% to 40% of earnings, with earnings counted up to €115,000), so the PAYE base can't drop without limit either.

What I'd tell anyone writing payroll code

Store rates with an effective date, and look them up by pay date.
Round per pay period, the way a payslip does, then add up.
Keep a separate base for each charge. They stop matching as soon as a pension contribution comes in.
Treat cliff thresholds like USC's €13,000 as their own rule, not as a band.

If you want to check your own numbers against these rules, the worked example above is the calculator's default case, and every figure in this post comes from it. Has anyone here modelled a mid-year rate change in another country's payroll? I'd like to hear how you handled the pay-date rule.

Test your redirect map with bash and curl before you move a site

Rai Ansar — Sun, 25 Oct 2026 06:43:23 +0000

The DNS change is usually the calm part of a site move. The trouble shows up later: someone rebuilds the server config and half the redirect rules don't come back, or a rule left over from the old CMS stacks on top of a new one and every old URL now takes two hops to land.

I've done more than 700 site migrations, and the habit that saved me most often is a dull one. The redirect map lives in the repo as a CSV, and a small script tests it against the live site, the same way a test suite tests code. If the map can be re-run, a broken rule shows up in seconds instead of in Search Console three weeks later.

The map is one row per old URL

These are the columns I use:

old_url,new_url,status,match_type,clicks_12m,referring_domains,notes
https://old.example.com/about-us,https://www.example.com/about/,301,exact,380,12,Path renamed
https://old.example.com/blog/tag/widgets,https://www.example.com/blog/,301,merge,12,0,Thin tag page folded into the blog index
https://old.example.com/old-promo-2017,,410,removed,0,0,Expired offer. No equivalent page; do not send to home

status is 301 or 308 for pages that moved or were merged, and 410 or 404 for pages that are gone. match_type says whether the row is an exact match, a pattern rule, a merge or a removal. Pattern rows get expanded to real URLs before testing, because you can't curl a regex.

The two traffic columns come from Search Console and your backlink tool, and they decide which rows you check by hand first. A broken redirect on a page with 4,000 clicks a year hurts more than one on a dead tag page.

What the test asserts

For every 301 or 308 row, three things have to be true:

The first response is a permanent redirect. Google treats 301 and 308 as permanent and says they don't lose PageRank. A 302 or 307 tells it to keep showing the old URL in results.
The chain ends on new_url, and that page answers 200.
It takes one hop.

For 410 and 404 rows, the old URL has to answer with that code and must not redirect anywhere.

The one-hop rule is stricter than Google needs. Googlebot follows up to 10 redirects, but Google's own advice is to send people straight to the final URL. Two hops usually means an old rule and a new rule are both firing, and that is cheap to fix while you're still on staging.

The script

It needs only bash and curl.

#!/usr/bin/env bash
# check-redirects.sh: test a redirect map against a live site.
# Usage: ./check-redirects.sh redirect-map.csv
set -u
file="${1:?usage: $0 redirect-map.csv}"
pass=0; fail=0
while IFS=, read -r old new status _rest; do
  [ "$old" = "old_url" ] && continue
  [ -z "$old" ] && continue
  status="${status//$'\r'/}"; new="${new//$'\r'/}"
  first=$(curl -s -o /dev/null --max-time 20 --proto '=http,https' -w '%{http_code}' "$old")
  problems=""
  case "$status" in
    301|308)
      read -r last hops final < <(curl -s -o /dev/null -L --max-redirs 10 --max-time 30 --proto '=http,https' --proto-redir '=http,https' \
        -w '%{http_code} %{num_redirects} %{url_effective}\n' "$old")
      case "$first" in 301|308) ;; *) problems="$problems first-response=$first(want $status);";; esac
      [ "$last" = "200" ] || problems="$problems final-status=$last;"
      [ "$final" = "$new" ] || problems="$problems lands-on=$final(want $new);"
      [ "${hops:-0}" -le 1 ] || problems="$problems hops=$hops;"
      ;;
    410|404)
      [ "$first" = "$status" ] || problems="$problems status=$first(want $status);"
      ;;
    *) problems="unknown status column: $status;" ;;
  esac
  if [ -z "$problems" ]; then pass=$((pass+1)); echo "PASS $old"; else fail=$((fail+1)); echo "FAIL $old $problems"; fi
done < "$file"
echo "---"; echo "passed $pass, failed $fail"
[ "$fail" -eq 0 ]

Two curl calls per row. The first one doesn't follow redirects, so it sees exactly what the server answers. The second follows the chain with -L and reports the final status, the number of hops and the URL it ended on. A 308 passes a 301 row and the other way round, since both are permanent. Because the script exits 1 when any row fails, you can drop it into a CI job as it is.

A run against a test set

To show each failure, I built three rows on httpbin.org's redirect endpoint. The first is a correct 301, the second answers 302 where the map wants a 301, and the third is a 301 that lands on another 301 before it gets to the destination.

old_url,new_url,status,match_type
https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fget&status_code=301,https://httpbin.org/get,301,exact
https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fget&status_code=302,https://httpbin.org/get,301,exact
https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fredirect-to%3Furl%3Dhttps%253A%252F%252Fhttpbin.org%252Fget%26status_code%3D301&status_code=301,https://httpbin.org/get,301,exact

The run on 25 October 2026:

PASS https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fget&status_code=301
FAIL https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fget&status_code=302  first-response=302(want 301);
FAIL https://httpbin.org/redirect-to?url=https%3A%2F%2Fhttpbin.org%2Fredirect-to%3Furl%3Dhttps%253A%252F%252Fhttpbin.org%252Fget%26status_code%3D301&status_code=301  hops=2;
---
passed 1, failed 2

It took about 7 seconds and exited with code 1.

On a real move, the failures map to fixes like these:

first-response=302 means a temporary redirect somewhere in the config. Framework helpers often default to it. Express's res.redirect() sends a 302 unless you pass a status.
hops=2 usually means a legacy rule and a new rule are chained. If /a already went to /b and the new map sends /b to /c, map /a straight to /c.
lands-on= means the rule points somewhere other than the map says. Often it's the home page, which is the worst catch-all: Google can treat many unrelated URLs redirected to one page as soft 404s.

Keep it next to the config

Commit the CSV and the script beside the server or CDN config that holds the rules. Run the script once against staging before launch, again right after the DNS change, and again whenever someone touches the redirect config. The next person who rebuilds that config will find a test that tells them what they broke.

The rest of the migration process, all 40 checks from the first crawl to switching off the old server, with both files to download, is on MigrateWeb.

Padding a JPEG signature up to a 10 KB minimum without changing a pixel

Rai Ansar — Thu, 22 Oct 2026 06:41:31 +0000

I build a browser tool that resizes photos and signatures for Indian exam and job application forms. Most of the work is the obvious kind: a form says "under 20 KB", so you shrink the file until it fits. The case that caught me out was the opposite one, where a signature comes out too small for the form to accept.

Several notices set the signature as a window. IBPS RRB XV (Officers and Office Assistants), RCF Assistant Officer (Secretarial) and India Exim Bank SRD 2026 all ask for 140 × 60 px and 10 to 20 KB. TNPSC One Time Registration asks for 230 × 75 px, also 10 to 20 KB. So there is a floor as well as a ceiling, and the pixel size is fixed.

Quality 100 is not enough

My first assumption was that a file under the minimum just needs a higher JPEG quality. That works until quality is already at 100.

A signature is dark ink on white paper. At 140 × 60 there are only 8,400 pixels, and most of the 8 × 8 blocks the encoder works on are flat white. Those compress to almost nothing. On our sample signature, the IBPS size came to 6.2 KB at quality 100, and the TNPSC size to 8.4 KB. The encoder has nothing left to spend bytes on, so the minimum is out of reach from the quality setting alone.

The pixel count is also fixed by the notice, so scaling up is not an option. Adding noise or a border would get the bytes up, but it changes what the person checking the form sees. I wanted the file bigger without touching a single pixel.

Padding with comment segments

A JPEG is a sequence of marker segments. FF FE is a comment (COM) segment: two marker bytes, a two-byte length, then whatever you like. Decoders skip it. So the fix is to add comment segments until the file reaches the minimum, and leave the image data alone.

The padding goes just before the FF D9 end-of-image marker, so the file still ends the way a JPEG should. A segment's length field is 16 bits, so a large gap needs more than one segment. This is close to what ships:

export const padJpeg = (bytes: Uint8Array, targetBytes: number): Uint8Array => {
  if (bytes.length >= targetBytes) return bytes;
  if (bytes.at(-2) !== 0xff || bytes.at(-1) !== 0xd9) throw new Error("Invalid JPEG output");

  let output = bytes;
  let remaining = targetBytes - bytes.length;
  while (remaining > 0) {
    const segmentBytes = Math.min(remaining, 65_537);
    if (segmentBytes < 4) {
      // A segment needs 4 bytes of header; overshoot slightly instead.
      remaining += 4;
      continue;
    }
    const segment = new Uint8Array(segmentBytes);
    segment[0] = 0xff;
    segment[1] = 0xfe;
    const declaredLength = segmentBytes - 2; // the length counts itself, not the marker
    segment[2] = (declaredLength >>> 8) & 0xff;
    segment[3] = declaredLength & 0xff;

    const combined = new Uint8Array(output.length + segment.length);
    combined.set(output.subarray(0, -2));
    combined.set(segment, output.length - 2);
    combined.set(output.subarray(-2), output.length - 2 + segment.length);
    output = combined;
    remaining -= segmentBytes;
  }
  return output;
};

The tests check that the output reaches the target size and still ends with FF D9, and that a file without FF D9 at the end is refused rather than padded into something broken.

Which KB?

The other half of the problem is that "10 to 20 KB" does not say how many bytes a KB is. Some upload screens count 1,024 bytes and some count 1,000. A file of 20,300 bytes is under 20 KB on one reading and over it on the other.

So the tool sets the maximum under the smaller reading and the minimum under the larger one:

// A maximum of `kb` KB, met under both the 1000- and the 1024-byte reading.
export const kbCeilingBytes = (kb: number) => Math.floor(kb * 1000);
// A minimum of `kb` KB, met under both readings.
export const kbFloorBytes = (kb: number) => Math.ceil(kb * 1024);

For 10 to 20 KB that gives a target of 10,240 to 20,000 bytes. A file in that range passes whichever way the portal counts. When a window is too narrow to satisfy both readings (exactly 50 KB, say), it falls back to 1,024 bytes per KB and the code records that it did.

The search before the padding

Padding is the last step. First the tool encodes the image at the exact pixel size and binary-searches the quality for the largest file that still fits under the maximum. It uses canvas.toBlob with JPEG output, which takes quality on a 0.01 grid, so about seven halvings settle it. If the best fit is under the minimum, it pads. If padding would push it over the maximum, it throws an error rather than hand back a file the form will reject.

What came out

I ran the presets in Chrome 153 on 25 September 2026 on a generated test image of a signature photographed on a phone, 3024 × 1512 px and 892 KB:

Preset	Output	Quality	Padding added
IBPS, 140 × 60 px	10.0 KB	100	3.8 KB
TNPSC, 230 × 75 px	10.0 KB	100	1.6 KB
SSC, 472 × 157 px	18.9 KB	99	none

The SSC preset needs no padding because it has about nine times the pixels of the IBPS one. SSC CHSL and CPO 2026 give the signature as roughly 6.0 × 2.0 cm with no DPI, so the preset converts that at an assumed 200 DPI. That assumption is the weakest part of the setup, so the SSC page on the site spells it out.

Everything runs in the browser and nothing is uploaded, which matters when the file is someone's signature. If you want to try the floor case yourself, the tool is at FormAssets. Pick the IBPS preset, give it a clean signature, and it will tell you how many bytes it had to add.

A 200 response and a broken page: what screenshot monitoring taught me

Rai Ansar — Sat, 17 Oct 2026 23:27:52 +0000

An uptime check answers one question: did the server respond? Visitors ask a different one: can I use this page? After a few years of looking after client sites, the gap between those two answers was the thing I hit most often. A CSS deploy left a blank white screen. A WordPress plugin update broke checkout. An SSL certificate expired while the uptime dashboard still showed green.

I am Rai Ansar, a developer and DevOps engineer in Islamabad. I have worked on websites and servers since May 2019, and I built Visual Sentinel to close that gap. Here is what the visual part taught me.

The diff is the easy part

The core of a visual monitor fits in a few lines. This is a minimal sketch with Playwright, not our production code:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1366, height: 900 } });
await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({
  path: 'current.png',
  fullPage: true,
  mask: [page.locator('.ad-slot'), page.locator('time')],
});
await browser.close();

Compare current.png with a stored baseline pixel by pixel and you have a change detector. Left like this it will also alert on pages that change on every load, which leads to the lessons below.

Lesson 1: the baseline is the last confirmed good capture

If you compare against the previous screenshot, a broken page becomes the new normal after one run. Compare each capture against the most recent confirmed baseline instead. Keeping the screenshot history then tells you when the break was introduced.

Lesson 2: the threshold decides whether anyone trusts the alert

Ads, timestamps and rotating banners change on every load. Each monitor has a mismatch threshold, 5% by default, calculated over the whole rendered page. A tightly designed landing page or a checkout flow can go lower. A news homepage needs a higher number. For elements that always move, exclude them by CSS selector rather than raising the threshold for the whole page, because a high threshold hides real breakage.

Lesson 3: a change is evidence, not a verdict

On bdifferent.ie, a real customer site (recorded July 2026, shared with permission), 62.23% of the homepage changed while the uptime check still reported that the page loads. That is an easy case. Many diffs are a new hero image or a seasonal banner. The alert should carry a before and after capture so a person can decide in a few seconds. We treat a visual change as evidence to review and never as an automatic outage.

Lesson 4: pixels and text answer different questions

A screenshot tells you the page looks different. It does not tell you the price changed from one number to another. For that we run a separate content check: it extracts text from CSS selectors you define in the fetched source HTML and alerts when it changes. It does not run page JavaScript, so a price rendered client-side needs the visual check instead. Knowing which check covers which case saved me from promising more than either one does.

Lesson 5: capture frequency is a cost decision

Rendering a full page in Chromium costs more than a ping. On our Solo plan visual captures run every 30 minutes, and on Starter and above every 15 minutes, while uptime checks are much cheaper and run more often. A deploy regression is visible on the next capture, so a short interval matters most on sites that ship often.

Lesson 6: group the alerts

When three sites on the same server go down together, three separate 3 a.m. alerts help nobody. Visual Sentinel links sites to a server and sends one grouped incident when they fail together, with the likely shared cause.

What I would build first if I started again

Start with the screenshot, the baseline and the threshold. Add the content check once someone asks about a specific price or sentence. Add server grouping when you run more than one site per machine.

If you want to see the visual side on a live page, Visual Sentinel's visual monitoring shows a captured diff with the last good version beside the current one. Your first check is free when you add a site.

ChatGPT vs Claude vs Gemini (March 2026): The Definitive AI Comparison

Rai Ansar — Tue, 10 Mar 2026 03:39:48 +0000

Three platforms. Three radically different philosophies. And in March 2026, the gap between ChatGPT, Claude, and Gemini has never been more interesting — or more confusing for anyone trying to pick one.

OpenAI just shipped GPT-5.4 with native computer use and a 1M-token context window. Anthropic's Claude Opus 4.6 sits at #1 on the LMSYS Chatbot Arena. Google's Gemini 3.1 Pro quietly posted a 94.3% on GPQA Diamond, the highest score any model has achieved on PhD-level science questions. Meanwhile, the real battleground has shifted to coding agents: Claude Code, GPT Codex, and Gemini CLI are fighting for every developer's terminal.

I've spent the past two weeks stress-testing all three across coding projects, research tasks, creative writing, and daily workflows. Here's what actually matters.

Last Updated: March 2026

Quick Verdict: Best AI for Each Use Case

Use Case	Winner	Why
Coding & Development	Claude (Opus 4.6 + Claude Code)	#1 on SWE-bench (80.8%), Claude Code CLI dominates
Research & Analysis	Gemini 3.1 Pro	1M native context, 94.3% GPQA Diamond
Creative Writing	Claude Opus 4.6	Most natural prose, best voice consistency
Agentic Workflows	ChatGPT (GPT-5.4)	Native computer use, multi-step automation
Best Value	Gemini	Free tier with Flash, $19.99/mo for Pro
Enterprise/Teams	ChatGPT	Most mature ecosystem, Codex for async work

The Latest Models: March 2026

ChatGPT: GPT-5.4 Changes the Game

GPT-5.4, released March 5, 2026, brings native computer use — it can interpret screenshots, operate browsers, and issue keyboard/mouse commands. Key upgrades:

1M token context window (API) — up from 272K
Computer use built-in — first mainline model with native screen interaction
GPT-5.3-Codex capabilities merged — industry-leading code gen baked in
GDPval score of 83% — matches or exceeds professionals across 44 occupations

Claude: Opus 4.6 Takes the Crown

Claude Opus 4.6 holds #1 on LMSYS Chatbot Arena with 1504 Elo — real users preferring Claude over every other model in blind tests.

80.8% on SWE-bench Verified — top-tier for real-world software engineering
200K context window (1M beta) with 128K max output tokens
Adaptive thinking — dynamically decides reasoning depth
Compaction — automatic context summarization for infinite conversations

The sleeper hit is Claude Sonnet 4.6 at 79.6% SWE-bench — one-fifth the cost of Opus and preferred over the previous Opus 4.5 in 59% of comparisons.

Gemini: 3.1 Pro Is a Quiet Beast

94.3% on GPQA Diamond — highest PhD-level science score ever
80.6% on SWE-bench Verified — tied with Claude Opus 4.6
77.1% on ARC-AGI-2 — more than double Gemini 3 Pro's 31.1%
Native 1M token context — no beta flag, no waitlist
Multimodal — text, images, 8.4 hrs audio, 1 hr video, 900-page PDFs

Head-to-Head Comparison

Feature	ChatGPT (GPT-5.4)	Claude (Opus 4.6)	Gemini (3.1 Pro)
Context Window	1M (API) / 272K (Chat)	200K (1M beta)	1M native
Max Output	~32K tokens	128K tokens	65K tokens
LMSYS Rank	Top 10	#1 (1504 Elo)	#2 (1500 Elo)
SWE-bench	77.2%	80.8%	80.6%
GPQA Diamond	92.8%	91.3%	94.3%
ARC-AGI-2	73.3%	75.2%	77.1%
Image Gen	DALL-E 4	None	Nano Banana 2
Computer Use	Native	Via API	Limited
Coding Agent	GPT Codex	Claude Code CLI	Gemini CLI

Coding Showdown: Claude Code vs GPT Codex vs Gemini CLI

The real competition is in the terminal.

Claude Code: The Developer's First Choice

Claude Code hit $2.5 billion ARR — over half of Anthropic's enterprise revenue (more on AI coding tools).

It runs in your terminal, reads your entire project, writes code, runs tests, handles git, and debugs failures:

Parallel subagents — up to 7 simultaneous operations
MCP integration — Google Drive, Jira, Slack, custom tooling
Full terminal access — builds, tests, git, any CLI operation
VS Code and JetBrains extensions

GPT Codex: Async Powerhouse

Codex is a senior engineer you delegate to. It works autonomously in cloud sandboxes:

Runs 1-30 minutes on complex tasks with real-time progress
Cloud sandboxes with test harnesses, linters, type checkers
Interactive mode with GPT-5.4 — steer mid-task
Parallel worktrees — multiple agents on different project parts

The Power Move: Use Both Together

The workflow gaining traction:

Claude Code generates — faster real-time coding, deep local context
GPT Codex reviews — autonomous code review in cloud sandbox
Claude Code iterates — rapid fixes from Codex feedback

Teams report 30-40% more issues caught than either tool alone.

Gemini CLI: Present but Not Ready

Free tier with 1,000 requests/day is generous, but:

Sequential execution only — no parallel tasks
Frequent 429 rate limit errors
Less refined agentic behavior

For professional work, Claude Code and GPT Codex are in a different league.

Pricing

Plan	ChatGPT	Claude	Gemini
Free	GPT-4o	Sonnet 4.6	Flash, 1K req/day
Standard	$20/mo	$20/mo	$19.99/mo
Power	$200/mo	$100-200/mo	$249.99/mo

API (per million tokens)

Model	Input	Output
GPT-5.4	~$2.50	~$10.00
Claude Opus 4.6	$5.00	$25.00
Claude Sonnet 4.6	$3.00	$15.00
Gemini 3.1 Pro	$2.00	$12.00

Which Should You Choose?

ChatGPT → agentic automation, async coding delegation, enterprise teams

Claude → daily coding (Claude Code is unmatched), best writing quality, complex nuanced tasks

Gemini → massive documents (1M context), best free tier, PhD-level reasoning

My Daily Setup

Claude Code (Pro $20/mo) — primary coding tool
ChatGPT Pro ($200/mo) — Codex for async delegation
Gemini AI Pro ($19.99/mo) — research, Google integration

Pick just one? Claude Pro at $20/mo. Best value per dollar.

FAQ

Is ChatGPT still the best AI in 2026?
Most popular, but Claude holds #1 on LMSYS Arena and Gemini leads reasoning benchmarks.

Is Claude better than ChatGPT for coding?
Yes — 80.8% vs 77.2% SWE-bench, and Claude Code CLI has $2.5B ARR.

Can I use Claude Code and GPT Codex together?
Absolutely. Implementation + review. 30-40% more issues caught.

Which has the largest context window?
GPT-5.4 and Gemini: 1M tokens. Gemini's is natively available everywhere.

Originally published on AIToolRanked. More comparisons: ElevenLabs review | Best AI for coding | Grok vs ChatGPT