• The number of nodes in the list is in the range [0, 300]
• -100 <= Node.val <= 100
• The list is guaranteed to be sorted in ascending order.

We are handed a linked list whose values are already sorted, and we must throw away repeats so each value survives exactly once — [1, 1, 2] becomes [1, 2]. We only walk forward (the traversal from the previous problem), and we want to do it in place, without building a second list.

If the list were in any order, duplicates could be anywhere — a second 1 might sit ten nodes away from the first. To catch that, you would carry a set of values already seen: at each node, ask "have I seen this value before?"; if yes, splice the node out; if no, record it. A set answers that question in roughly constant time, so this runs in O(N) time — but it spends O(N) extra memory on the set, up to one entry per distinct value.

seen = set()
prev, curr = None, head
while curr:
    if curr.val in seen:
        prev.next = curr.next      # splice out the repeat
    else:
        seen.add(curr.val)
        prev = curr
    curr = curr.next

Now look hard at what that set is buying us. It exists to answer "have I seen this value?" for values that might appear far apart. But the problem swore the list is sorted. In a sorted list, equal values cannot be far apart — they are physically forced to sit in one unbroken run, immediate neighbors of each other. (If two 1s had anything other than a 1 between them, that middle value would be both ≥ 1 and ≤ 1, i.e. also a 1 — so there is no gap.) The set is remembering, at O(N) cost, a fact the ordering already guarantees for free. That is the waste.

Because every group of equal values is one contiguous run, you never have to remember the past. Standing on any node, the only place a duplicate of its value can hide is directly after it. So the entire memory of "what have I seen" collapses to a single comparison: is my current value equal to my neighbor's? That comparison needs no set, no extra space — just the two nodes already in front of you.

Keep one pointer curr. Compare curr.val to curr.next.val. If they are equal, the neighbor is a repeat, so bypass it: point curr.next to curr.next.next, unlinking the duplicate. If they differ, the neighbor is a genuinely new value, so advance curr onto it.

curr = head
while curr and curr.next:
    if curr.val == curr.next.val:
        curr.next = curr.next.next   # drop the duplicate; DO NOT advance
    else:
        curr = curr.next             # new value; safe to step forward
return head

Notice the two duplicate groups were handled with zero memory, and the run of two 3s at the very end still terminated cleanly because the guard checks for a neighbor first.

Same single pass — O(N) time — but the set is gone, so space drops from O(N) to O(1). The whole saving came from reading the precondition: "sorted" quietly promised that equal things are adjacent, which turned a remember-everything problem into a compare-your-neighbor one. Train that reflex: when a problem hands you a sorted (or otherwise ordered) input, ask what that ordering makes adjacent, because adjacency is what lets you replace memory with a local comparison. And notice the exact contract here — we keep one copy of each value. The sibling problem that deletes every node that ever had a duplicate (leaving [1, 2, 3, 3] as just [1, 2]) needs a dummy node before the head and a slightly different guard; that variation is Remove Duplicates from Sorted List II.