DEV Community: Shay Key

What ChatGPT Auto-Continue Can — and Cannot — Do

Shay Key — Wed, 28 Oct 2026 15:54:34 +0000

Automatic continuation sounds simple: when an AI response ends, send another prompt asking it to keep going. That can be helpful for long explanations, brainstorming sessions and section-by-section drafts. But it is important to understand the boundary between generating more text and completing a reliable task.

What it can help with

A continuation prompt can reduce repeated manual clicks. A configurable waiting period gives a person time to examine the previous output. A counter and maximum make the loop visible and bounded. These controls are especially useful when a task naturally unfolds across several responses.

ChatSequel is a Chrome extension for ChatGPT that documents user-enabled Auto Continue, per-tab pause/resume/stop controls, a chosen continuation message, a delay setting and a maximum continuation count. The tool is independent of OpenAI and does not use a proprietary model to replace ChatGPT.

What it cannot verify for you

Generating another answer does not prove that the earlier answer was correct. Continuation cannot independently confirm external publications, database migrations or the contents of a file that the assistant has not read. Those tasks need evidence from the relevant system.

Nor does a long chat guarantee that all past content remains available for transfer. When a conversation reaches a length limit, a summary can help establish continuity, but it is necessarily limited to what can be accessed. ChatSequel’s HANDOFF mechanism uses messages available on the ChatGPT page and does not guarantee recovery of unloaded history.

Use a responsible stopping rule

Write down the goal and definition of done. Choose a limit on follow-up turns. Pause when the next action could send a message, publish content, spend money or change production data. Keep project notes and verified source files outside the chat.

The most useful automation is not the one that creates the longest thread. It is the one that saves repetitive effort while leaving the human informed and able to stop.

Disclosure: Prepared with AI writing assistance for Prax9, the developer of ChatSequel. ChatSequel is an independent Chrome extension, not affiliated with or endorsed by OpenAI. This article describes product documentation and suggested workflows, not the results of an independent product test.

Product reference: ChatSequel on the Chrome Web Store.

A Retry-Safe Handoff Contract for Long AI Chats

Shay Key — Sun, 25 Oct 2026 20:11:49 +0000

A Retry-Safe Handoff Contract for Long AI Chats

Long AI-assisted tasks often span more than one interaction. A response may be interrupted, a user may need to start a new conversation, or a tool call may finish while the interface is still waiting. The fragile point is not always the summary itself. It is the transition: what happens if a handoff is sent twice, acknowledged late, or resumed from incomplete context?

A useful design starts by treating a handoff as a small protocol, not as an unstructured paragraph that says “continue where we left off.”

Separate the work state from the transport

A handoff packet should describe only the state needed to resume responsibly. For example:

{
  "schema_version": 1,
  "conversation_id": "example-session",
  "revision": 17,
  "goal": "Complete the deployment review",
  "confirmed_facts": ["Tests passed locally"],
  "decisions": ["No production change without approval"],
  "open_items": [{"id": "T-12", "task": "Verify the live service"}],
  "unknowns": ["Whether the new version is serving traffic"],
  "last_completed_step": "Recorded the dry-run results"
}

The distinction between confirmed_facts and unknowns matters. A newly opened conversation should not silently promote a guess into a fact. Likewise, decisions and restrictions should survive even if older conversational details do not.

Avoid putting passwords, API keys, session cookies, personal identifiers, or confidential source material into the packet. A handoff is still data being copied into another context; minimization and redaction should happen before transfer.

Give the handoff a stable identity

Retries are normal in distributed workflows. Suppose a sender transfers a packet, receives no acknowledgment, and retries. Without a stable ID, the receiver may treat the retry as a new instruction.

A simple demonstration uses a content-derived ID:

import { createHash } from 'node:crypto';

function makePacket(state) {
  const payload = JSON.stringify(state);
  const id = createHash('sha256').update(payload).digest('hex');
  return { id, payload };
}

function acceptPacket(packet, receiptStore) {
  if (receiptStore.has(packet.id)) {
    return { duplicate: true, receipt: receiptStore.get(packet.id) };
  }
  const receipt = { id: packet.id, accepted: true };
  receiptStore.set(packet.id, receipt);
  return { duplicate: false, receipt };
}

const state = { conversation_id: 'example-session', revision: 17 };
const packet = makePacket(state);
const receipts = new Map();
console.log(acceptPacket(packet, receipts).duplicate); // false
console.log(acceptPacket(packet, receipts).duplicate); // true

This is an in-memory illustration, not production-grade exactly-once delivery. A real system needs durable storage, a unique constraint on the handoff ID, and an atomic relationship between recording the receipt and applying any consequential operation. Cross-language systems also need canonical serialization before hashing, because equivalent JSON objects can have different byte representations. A hash is an identifier here, not an authorization token.

Use an explicit state machine

A handoff can move through a few named states:

State	Meaning
`PREPARED`	A packet exists, but the destination has not confirmed receipt.
`ACKNOWLEDGED`	The destination accepted a specific packet ID.
`RESUMED`	Work continued from that acknowledged packet.
`CANCELLED`	The user or system stopped the transition.

A timeout after PREPARED is not evidence of failure; the receiver might have accepted the packet before the acknowledgement was lost. The safe retry uses the same packet ID and first asks the receiver whether it has already been accepted.

A separate state transition should be required before any action with external effects: sending email, updating a database, deploying software, or publishing content. Resuming context is not permission to perform those actions.

Require a resume check

Before continuing, the destination should answer five questions:

Is the packet complete enough to understand the goal and current step?
Are the restrictions and unresolved uncertainties preserved?
Has this packet ID already been processed?
Does any requested action require fresh human authorization?
Can the next step be verified without relying on a claim from an older summary?

If the answer to an important question is unknown, the continuation should say so. “Needs verification” is a valid state; invented certainty is not.

Test failure paths, not just the happy path

At minimum, test duplicate delivery, dropped acknowledgments, stale revisions, malformed packets, missing restrictions, cancellation, and re-opening a conversation after the sender is gone. It is also worth checking that no hidden background action starts solely because a handoff arrives.

For browser-based tools, the user should be able to pause, inspect, copy a backup, and stop a transition. Visibility is not a substitute for permissions, but it makes failures easier to detect and recover from.

The practical takeaway

A summary helps another conversation understand the work. A handoff protocol helps it resume safely. The difference is an explicit record of what is known, what is not known, what has already happened, and which steps still require authorization.

AI disclosure: This article was drafted with generative AI. It must be checked and substantially reviewed by a human who understands the technical material before publication. It is not a report of firsthand testing or production experience.

PRAX9: gerenciador e alternador de proxies gratuito para Chrome

Shay Key — Thu, 30 Jul 2026 18:42:46 +0000

PRAX9: gerenciador e alternador de proxies gratuito para Chrome

Se você trabalha com proxies — para testes, QA, ou porque usa
seus próprios servidores — provavelmente já sentiu como é chato
trocar a configuração de proxy no Chrome toda vez que precisa
mudar de servidor.

Por isso criei o PRAX9, uma extensão gratuita para Chrome que
permite salvar e alternar entre vários servidores proxy com um
único clique.

O que ele faz?

Salva proxies HTTP, HTTPS, SOCKS4 e SOCKS5
Troca entre eles com um clique direto na barra de ferramentas
Permite rotear apenas domínios específicos pelo proxy (em vez de mandar todo o tráfego)
Verifica se um proxy salvo está funcionando antes de você usá-lo

Por que é diferente?

É totalmente gratuito, sem anúncios, sem coleta de dados, e não
exige conta. Construído em Manifest V3, então funciona na versão
atual do Chrome sem depender de scripts em segundo plano
obsoletos.

Pode instalar aqui: Chrome Web Store

Alguém mais já teve esse problema? Quero saber se existe algum
caso de uso de roteamento que eu não considerei.

PRAX9: gestor y selector de proxies gratuito para Chrome

Shay Key — Thu, 30 Jul 2026 18:38:34 +0000

PRAX9: gestor y selector de proxies gratuito para Chrome

Si trabajás con proxies (para testing, QA, o simplemente porque
usás tus propios servidores), seguramente conocés lo tedioso que
es cambiar la configuración de proxy en Chrome cada vez que
necesitás cambiar de servidor.

Por eso hice PRAX9, una extensión gratuita para Chrome que
permite guardar y cambiar entre múltiples servidores proxy con un
solo clic.

¿Qué hace?

Guarda proxies HTTP, HTTPS, SOCKS4 y SOCKS5
Cambia entre ellos con un clic desde la barra de herramientas
Permite enrutar solo dominios específicos a través del proxy (en vez de mandar todo el tráfico)
Verifica si un proxy guardado funciona antes de usarlo

¿Por qué es diferente?

Es completamente gratis, sin anuncios, sin recolección de datos, y
no requiere cuenta. Está construido en Manifest V3, así que
funciona con la versión actual de Chrome sin depender de scripts
en segundo plano obsoletos.

Lo pueden instalar acá: Chrome Web Store

¿Alguien más tuvo que lidiar con este problema? Me interesa saber
si hay algún caso de uso de enrutamiento que no contemplé.