Skip to content
OpenGPT0
HomeDocs

Architecture

How OpenGPT0 routes each turn through ChatGPT, local evidence, and coding workspaces.

OpenGPT0 is a ChatGPT-browser coding harness. The user works in one OpenGPT0 session, while OpenGPT0 decides what each turn is allowed to see, which local tools it may use, and how the visible ChatGPT answer is projected back into the session.

The Browser provider does not turn ChatGPT into a local shell or filesystem agent. ChatGPT can answer and can request mediated work, but OpenGPT0 owns local file access, code changes, command execution, Git operations, permissions, and audit.

OpenGPT0 HarnessTurn architectureA user prompt enters the OpenGPT0 session, then a HarnessTurn routes it to ChatGPT Runtime, Readonly Evidence, or Coding Workspace.OpenGPT0 Sessionuser transcriptfinal projectionHarnessTurnintentcontext + tool policyChatGPT Runtimebound browser conversationReadonly Evidenceread, search, diff summaryCodingpatch, command, Git, audit

HarnessTurn

Every prompt is admitted to the OpenGPT0 session first. The harness then creates a HarnessTurn for the current turn. It classifies the intent and builds the smallest useful context for that intent.

Examples:

  • ChatGPT runtime probe: “What model are you?” is sent to the current ChatGPT browser conversation. OpenGPT0 does not read repository files and does not rewrite ChatGPT’s self-description.
  • Repository evidence: “Summarize README.md” first runs bounded read-only evidence collection, then sends the current-turn evidence to ChatGPT.
  • Coding work: “Patch this bug” uses read-only evidence plus mediated coding tools. Permission, audit, and Git ownership remain OpenGPT0 responsibilities.

Runtime Boundaries

OpenGPT0 separates the workspaces that cooperate during a turn:

WorkspaceOwnsDoes not own
Main SessionUser transcript, session state, final projectionBrowser DOM control, local shell authority
ChatGPT RuntimePrompt submission, visible answer observation, runtime traceLocal files, shell, Git, cookies outside ChatGPT
Readonly EvidenceBounded repo/file/search evidenceCode mutation
CodingPatches, commands, Git, approval, auditChatGPT page identity or browser state

The ChatGPT Runtime uses the active bound ChatGPT conversation. HarnessTurn controls what OpenGPT0 sends into that conversation for the current turn; it does not erase the ChatGPT webpage’s own conversation memory.

Visible Answer Alignment

For Browser/ChatGPT work, OpenGPT0 treats the ChatGPT webpage as the upstream model source. The answer shown in OpenGPT0 must align with the visible current-turn ChatGPT answer.

Alignment is stricter than “the API returned text”, but it is not byte-for-byte equality. OpenGPT0 must prove that it read the current turn, did not use a stale answer, did not silently fall back to another provider, and did not change the meaning when projecting the answer into the session.

A Browser ChatGPT turnA user prompt is planned by HarnessTurn, optionally uses local evidence or coding tools, then submits to ChatGPT and projects the visible current-turn answer.Promptuser inputHarnessTurnpolicy + intentEvidenceonly if neededCodingapproval + auditChatGPTvisible answerProjectaligned final

How This Differs From Native Tool Agents

Many coding agents run a model and a structured tool protocol inside one runtime. OpenGPT0’s Browser provider is different: ChatGPT is an authenticated web application and model source, while OpenGPT0 remains the local authority.

That difference is why OpenGPT0 keeps the provider route small:

  • ChatGPT answers through the browser conversation.
  • OpenGPT0 mediates local tools and permissions.
  • HarnessTurn decides which evidence is visible for the current turn.
  • The final OpenGPT0 answer is projected from the visible current-turn ChatGPT answer with alignment evidence.