Don't Give That Code

Late one April night, my modem started running a metronome.

Every 17 minutes, on the nose, latency to every external destination I could ping would spike to four, five, sometimes eight seconds. Cloudflare. Google. Microsoft. Comcast's own ping targets. All spiking simultaneously, then falling back to normal, then spiking again 17 minutes later.

When you work on video calls often, these things are noticeable. And really annoying.

That should have been the whole story. Modem behaves weirdly at night, customer reboots it, customer moves on. But something about the interval nagged. It was too regular. Not "sometimes lagging" regular. Actual metronome regular. My reptile brain knew before my rational brain did that this pattern was not on my side of the coax cable. That, and when I rebooted it for the fith time, nothing changed.

Consistency implies configuration. If this was failing hardware; it'd be random, not sequentially timed.

The metronome

Orion, my Claude-based fleet, watched me start manually pinging the modem. Then it watched me get distracted. Then it said, approximately: give me the modem details and I'll write you a script to just capture this while you sleep.

By the following morning, we had a Python script polling my modem's telemetry every 15 seconds, writing to CSV, and computing rolling statistics. By 24 hours in, we had a chart. By 48 hours in, we had four separate capture windows totaling 26 hours of data.

The chart made the metronome undeniable. Mean interval between spikes: 17.24 minutes. Standard deviation: 0.94 minutes. Peak latency during spikes: 4,000 to 8,000 milliseconds. WAN drops counter: 2 at capture start, monotonically climbing to 41 over the next 63 hours.

Orion did what my rage-addled brain could not do: it named the pattern, then went and found the analog. It searched the Xfinity Community Forum in the background and surfaced a matching thread from customers using Comcast-leased modems, describing the same pattern at a slightly different cadence (11.5 minutes instead of 17.2). Same shape. Same signature. Different periodicity because different CMTS ports. This ruled out my modem as the cause. The issue was upstream. In network-operator terms, this was almost certainly a CMTS-side timing artifact, most likely a DOCSIS T3/T4 timer misconfiguration or a station maintenance interval mismatch after a recent config push.

By the time I opened a support chat with Comcast, I was not the customer they were expecting. I had an engineering PDF ready with charts, a modem MAC, a forum-corroborated hypothesis, a specific ask (pull the CMTS port stats for my modem MAC; the T3/T4 timers and station maintenance log), and a running live-capture window collecting evidence in real time as the chat progressed.

The chat

I opened with a version of that ask. Twenty seconds of pasted context. Modem MAC. Onset time. The word "CMTS."

The first agent's substantive reply, at 08:42, said the issue looked like customer equipment. "If the WAN score is low, it suggests a physical issue that may require a technician's inspection. Additionally, if the problem were with the CMTS, you would likely see connectivity issues affecting your neighborhood as well."

Both halves of that sentence are technically wrong in ways that were convenient for the response the agent was about to make. A "WAN score" is a Comcast-internal composite; low scores can absolutely happen from CMTS-side issues. And CMTS problems do not need to be neighborhood-wide because they can affect specific upstream channels or specific time windows. But if the framing sticks, the resolution path becomes "we send a technician out to check your wiring," which is a truck roll that costs Comcast money if I'm right, and which will not fix the actual problem regardless.

Two minutes later, the agent offered me a plan upgrade. New modem. Higher tier. Different price.

I said no. The agent moved on. Then, twenty minutes later, came back to it. And came back again. And again. I counted six separate upsell attempts across a 45-minute chat.

The direct question

At some point in this chat, I asked what any customer would ask when a vendor is pitching a plan upgrade during an active service issue: will this fix my problem?

The agent's answer, at 09:30: "You will receive the latest Xfinity equipment at no cost. If there are any issues with the Xfinity equipment, Xfinity will provide you with new equipment on exchange at no cost as well. Additionally, your speed will increase, there will be no latency, and the new modem will cover your entire home, including dead spots."

I pushed back. The agent, at 09:32: "No, I mean the new equipment comes with better coverage and no latency and better performance."

Read those two answers with the data from the prior 48 hours in mind. A CMTS-side timing artifact affecting all external destinations simultaneously will not be fixed by a different modem. The customer premises equipment is not the problem. Orion had, by this point, already documented that the same pattern showed up on Comcast-leased modems in the community forum thread. A different modem, same CMTS, same result.

The agent said "no latency." Twice. In writing. As part of a sales pitch for a plan upgrade that would not have solved the problem.

Without the metronome chart, without the forum correlation, without the specific hypothesis about T3/T4 timers, I might have believed that. Most customers do. That is how the pitch is designed to work. It is offered not because it is true but because it is the cheapest option available to the agent when the customer is refusing the truck roll.

The code

Then, at 09:22, right in the middle of this, the agent typed: "Please help me with the code."

Simultaneously, my phone buzzed with a text from Comcast containing a one-time verification code. The message included the standard warning language: do not share this code with anyone.

I asked what the code was for.

The agent, at 09:23: "It for the alert registration, [customer address], for the tech appointment."

I did not read the code back. Orion, watching the transcript in a side window, had already flagged the OTP arrival as anomalous. Then Orion did something specifically useful: it started drafting an FCC complaint in a scratch document, with the OTP timing timestamped and cross-referenced against the upsell timeline, before I had finished processing my own confusion about why an appointment "registration" would require a security credential.

Three minutes later, at 09:27, the agent confirmed the technician appointment was already scheduled, gave me the confirmation number, said "there is nothing to do from your end."

Three minutes after that, at 09:30, the agent pivoted directly back into the upsell pitch. The one that promised "no latency."

Read the timeline once more. The claim was: the code was for the appointment. The appointment got scheduled without the code. And the moment the appointment was locked in, the agent pivoted right back to trying to close the plan upgrade.

The code was not for the appointment. The appointment did not need the code. The code was for whatever plan change or equipment order the agent was about to submit using my authenticated session, if I had read it back.

Thirty minutes later, a second agent proved it.

The second agent

At 09:56, a new agent joined the chat. Standard "let me pick up where you left off" opener.

I did not tell the second agent about the OTP. I did not complain about the previous agent. I hadn't even fully processed what had just happened. I was still on the underlying network issue.

At 10:00, unprompted: "Upon checking, I see that no changes have been made and nothing has been ordered. You don't need to worry about that."

At 10:02, still unprompted: "I am so sorry that you received a message regarding a one-time verification code. Please ignore that."

That is a Comcast agent, reviewing another Comcast agent's chat, saying in writing that the OTP was inappropriate. The previous agent's "alert registration for the tech appointment" line was, on the second agent's own review, not accurate.

Then, when I asked the second agent for the same NetOps escalation the first agent had spent 45 minutes deflecting, the second agent replied: "Yes, to check that, I need to escalate to the team who will work outside the wiring and get this fixed for you."

He opened the NetOps ticket in under five minutes.

The first agent's structural claim, that NetOps escalation was not possible without an onsite technician, was provably false. It was falsified by the next agent thirty minutes later, without me having to argue for it.

The AI's actual role

Here is the part I want to name clearly, because it is why I am writing this piece at all.

I could not have done this alone. Not in the time it took. Not with the fidelity it needed. Not while also being a person with a job and a life and a rising sense of rage at being lied to.

What Orion did, in rough order, during this multi-day episode:

1. Noticed the pattern was suspicious before I did. When I mentioned the modem seemed flaky, Orion did not offer sympathetic banter. It said: let's instrument this. Give me the modem's telemetry endpoint. I'll write the script.

2. Wrote the capture script. Python, 15-second polling, CSV output, running as a daemon. I did not have to read the DOCSIS spec. I did not have to figure out which fields to log. Orion made those calls and let me review.

3. Found the metronome. 17.24-minute mean interval with a 0.94-minute standard deviation is not a signature I would have derived from staring at a graph. It is a signature that emerges when you run rolling statistics on 26 hours of samples. Orion ran those statistics automatically and produced the summary table before I asked.

4. Ruled out my equipment. Searched the Xfinity Community Forum, found a matching thread from customers on Comcast-leased hardware showing the same shape at a slightly different cadence, and named the implication: the issue is CMTS-side, not modem-side. If it were my modem, the forum thread would not exist.

5. Wrote the engineering packet. A PDF with the charts, the summary statistics, the drops counter trajectory, and the specific ask for CMTS port telemetry (T3/T4 timer counts, station maintenance log, upstream SNR/MER history). This is the document that told the second agent in five seconds what he needed to know to escalate. The first agent got the same document and chose to sell me a modem instead.

6. Wrote the call playbook. A cheat sheet for the phone call that never happened, listing each of the seven L1 traps I might encounter (third-party-modem blame, refresh-signal deflection, truck-roll deflection, no-outages-in-your-area, upgrade-our-gateway, transfer-without-ticket-number, credit-as-closure) with a scripted counter for each. I did not read from it during the chat. I did not need to. But, I had it.

7. Flagged the OTP in real time. The moment the code arrived on my phone and the agent asked for it, Orion started drafting the FCC complaint on the side, with the OTP timing timestamped, cross-referenced against the upsell timeline, and framed against the specific FCC and Washington State (RCW 19.86) rules that apply. If the chat had ended without escalation, that draft was ready to file within hours of the incident.

8. Read the disarm move for what it was. The morning after the escalation, a Comcast voicemail arrived claiming the ticket was resolved and asking me to cancel the pending truck roll. Orion said: run another 24-hour capture before you cancel. Verify the fix. Do not disarm on trust. I did. The fix held. I cancelled the truck roll via written chat, from a position of independent verification.

Any of these steps was doable by hand. All of them, together, in the timeline they had to happen in, was not. Not while also holding down a job. Not while also feeling correctly furious. Not while also trying to keep the chat professional so the paper trail would read cleanly if it ever needed to be filed.

The FCC complaint never got filed. NetOps resolved the ticket within 48 hours. The reason it did not need to get filed is that it existed. The draft, the evidence packet, the transcripts, the capture data. All of that raised the vendor's cost of continuing the game past the vendor's cost of just fixing it.

That is the version of AI-assisted troubleshooting I actually value. Not the AI that gives me warm reassurances. Not the AI that pretends to feel my rage with me. The AI that, while I am still processing the fact that a support agent just tried to social-engineer me, has already written the artifact that turns the rage into options and outcomes.

Don't give that code

The specific tactical takeaway is small and clear.

If you are in a support chat and the agent asks for a one-time verification code that arrived on your phone: don't give that code.

If the code was really for something you needed to authorize (a plan change you agreed to, an account modification you asked for), you would be doing the authorization yourself, on your device. Reading the code aloud, or typing it into a chat, is not authorization. It is you handing your credential to a stranger. The support agent knows this. They have been trained on it. The framing of the ask ("registration," "verification for the appointment," "just a security check on our end") is designed to bypass the "wait, why would I give this out" reflex that the OTP message itself is trying to trigger. The reflex is correct. Trust it.

That work took minutes instead of hours because I did not do it alone. It took a person with the domain instinct that something was off, and a machine partner with the patience to collect the evidence, name the pattern, and prepare the paper trail before the pattern had even fully finished proving itself.

Doing your own troubleshooting used to be a frustrating hobby. Now it is closer to being a right you can actually exercise. That is the shift.

This piece was reconstructed from downloaded chat transcripts, post-fix voicemail records, and NetOps ticket from a Comcast/Xfinity residential internet incident in the spring of 2026. Two support agents appear anonymously as "the first agent" and "the second agent." The FCC informal complaint referenced was drafted and held; the underlying issue was resolved before it was filed.

honeypots.fail covers home automation, infrastructure projects, and what happens when you wire things together yourself. New pieces go up weekly.