chatgpt-use

Turn your ChatGPT web subscription into a coding-agent backend — no API key, no Codex billing. Built on chrome-use, same lineage as chatgpt-imagegen and cookie-use.

🧪 Experimental · v0.0.1 released. Browser main line (ask · structured delegation · --model pro · handoff) is live-verified; install with the one-liner below.

Your Plus / Pro plan already includes a chat surface you've paid for. chatgpt-use drives that logged-in web conversation through chrome-use — exactly the way chatgpt-imagegen drives image generation — and wires it into your local machine. The result: a coding agent (Claude Code, Codex, anything) can hand work to ChatGPT, and ChatGPT can read and edit your project files.

The web chat surface is not the API and not the Codex-usage bucket. So the work runs on quota you've already bought — that's the whole point.

Why this exists

	API / `codex exec`	chatgpt-use (web)
Auth	`OPENAI_API_KEY` or Codex login	your normal browser login
Billing	per-token API spend / Codex-usage limit	your flat monthly subscription
File access	you build context plumbing	`read_file` tool — no tunnel
Setup	keys, env, gateways	`chrome-use` + a logged-in tab

If you're already paying for ChatGPT Plus/Pro and also burning API credits or Codex-usage limits from your coding agent, this closes the gap: route the cheap-and-already-paid work to the browser.

Three modes

chatgpt-use is one engine — a chrome-use-driven channel to the ChatGPT web conversation (send a message, wait for the reply, parse it) — exposed three ways depending on who's the brain.

Mode 1 · 副手 / Sidekick — `chatgpt-use ask`

Your harness stays the brain. Claude Code / Codex keeps planning and calling its own tools, and delegates a single sub-task — reasoning, code generation, a review pass — to ChatGPT when it wants a second brain. One round trip, no tool loop.

# one-shot: pipe context in, get an answer back
chatgpt-use ask "Review this diff for race conditions" --file src/server.rs

# or feed it whatever you already gathered
git diff | chatgpt-use ask "Explain what changed and what might break"

The caller decides what context to send — chatgpt-use just relays it and returns ChatGPT's text.
ChatGPT does not touch your machine in this mode.
Borrows the web-driving practices proven in chatgpt-imagegen: profile auto-detection (relay → logged-in profile), composer polling, rate-limit-dialog detection, in-page authenticated fetch, and conversation filing under a ChatGPT Project.

Mode 2 · 大脑 / Brain — `chatgpt-use run`

ChatGPT is the brain; your machine is the hands. A local agent loop — the same shape as Codex or Claude Code — but the model is your web subscription:

chatgpt-use seeds the conversation with a system prompt that defines a tool protocol.
ChatGPT replies with a structured tool call (a JSON object; the parser scans the rendered reply for it, so a bare one-liner or a code block both work).
The local harness executes that tool (read_file, write_file, bash, grep, list_dir, …) and feeds the observation back into the chat.
Loop until ChatGPT declares the task done.

chatgpt-use run "Add a --json flag to the status command and update the tests"

This is why goal "let ChatGPT read my files" needs no tunnel and no exposed file server. File access is the read_file / grep tools: the local harness reads the bytes and hands them into the conversation. ChatGPT never reaches back to your machine — it just asks, and the hands obey.

Mode 3 · 替身 / Drop-in model — `chatgpt-use serve`

Claude Code stays exactly as it is — its agent loop, its tools, its UX — but the model behind it is secretly ChatGPT. chatgpt-use serve exposes a local Anthropic-compatible endpoint (/v1/messages, streaming). Point Claude Code at it:

chatgpt-use serve --port 8787 &
ANTHROPIC_BASE_URL=http://127.0.0.1:8787 ANTHROPIC_AUTH_TOKEN=whatever claude

Now every model call Claude Code makes — the thing that spends Anthropic model tokens — is intercepted, translated into a prompt, driven through your ChatGPT web subscription, and translated back into Anthropic's response shape (including tool_use blocks, so Claude Code's own tools keep working). Claude Code never knows its brain was swapped.

No model tokens. Claude Code's loop runs locally and free; the tokens it would have billed are served by your flat subscription instead.
Reuses Mode 2's text tool-call protocol + parser — but instead of running our own loop, it re-encodes ChatGPT's tool calls as Anthropic tool_use blocks and hands them back to Claude Code, which runs its own tools.
The most ambitious and most fragile mode (see caveats): Claude Code's prompts are large, tool-call fidelity over a text protocol is imperfect, and the web surface rate-limits. Experimental².

All three modes share one engine: Mode 1 is Mode 2 with tools off; Mode 3 is Mode 2's tool protocol re-dressed as an Anthropic API so an existing harness can wear ChatGPT as its model.

How it works

  ┌─────────────────────────────────────────────────────────────────┐
  │  chatgpt-use  (Rust CLI)                                         │
  │                                                                  │
  │   task ─▶ system prompt + tool protocol                          │
  │              │                                                   │
  │              ▼                                                   │
  │      ┌───────────────┐   eval/send/poll   ┌──────────────────┐   │
  │      │  agent loop   │ ─────────────────▶ │  chrome-use      │   │
  │      │  + tool exec  │ ◀───────────────── │  (logged-in tab) │   │
  │      └───────────────┘   parsed reply     └────────┬─────────┘   │
  │              │                                     │             │
  │     read_file/write_file/bash/grep         ChatGPT web chat      │
  │              ▼                              (your subscription)  │
  │        your project files                                       │
  └─────────────────────────────────────────────────────────────────┘

Everything page-side goes through chrome-use eval <js> (run JS in the page, get JSON back). Sending a prompt = fill #prompt-textarea + click send. "Reply done" = poll until the stop/streaming control disappears, watching for the "Too many requests" dialog. All proven in chatgpt-imagegen.

Target architecture: dual-channel by model tier

Live testing + studying three mature projects (see below) converged on one design rule: don't make web ChatGPT role-play tools — route by what each model tier can actually do. Full write-up: docs/architecture.html.

Failure semantics (conversation identity, reconnect mid-generation, ambiguous submit, completion observation, cross-process contention), specified as browser-state → required outcome so other implementations can run them too: docs/failure-semantics-corpus.md.

                         chatgpt-use (local daemon)
                                    │
        ┌───────────────────────────┼────────────────────────────┐
        │                           │                            │
   browser channel             MCP channel                  executor
   (chrome-use)                (local server +              handoff
        │                       public tunnel)                   │
        ▼                           ▼                            ▼
  GPT-5.5 **Pro**            GPT-5.5 Instant/Thinking     Codex / Claude Code
  planner / reviewer         native tool-calling          run the plan locally
  (NO Apps/MCP on Pro →      (real MCP tools, no
   browser is the only       role-play wall)
   way to reach Pro)

Pro can't use Apps/MCP (confirmed: OpenAI Help Center — "Apps … are not available with Pro"). So Pro is reachable only through the browser channel, and is best used as a planner/reviewer that returns a structured delegation packet, not as an autonomous file-editor.
Regular GPT-5.5 can call native MCP tools — so genuine tool autonomy belongs on an MCP channel (a local server exposed via a public tunnel, since ChatGPT runs in the cloud and can't reach localhost), not on a faked browser text-protocol.
Execution stays local. The planner emits a typed packet ({goal, plan[], risks, tests, acceptance, do_not_do, verdict: proceed|revise|blocked}); the executor (Codex / Claude Code) only consumes packets — web ChatGPT never edits files directly.
The value is rate-limit arbitrage: your ChatGPT subscription quota is separate from the Codex/API bucket, so a Pro plan's planning power becomes "free" executor-adjacent capacity.

This is the target; the three modes below are the building blocks we're growing toward it.

Prior art we're borrowing from

Project	What we take
`ChesterRa/cccc` (930★)	dual-transport (browser push + MCP pull); append-only `ledger.jsonl` + single-writer daemon + stateless frontends; actor-bound token (hash-stored); `bootstrap` recovery packet. Also the source of the hard "Pro can't use MCP connectors" finding.
`tt-a1i/hive` (369★)	`<xml-system-reminder>` anchor tags placed at message tail (survive `/compact`); `PROTOCOL.md` fallback anchor; `tasks.md` task graph; session-resume by reading CLI rollout files.
`RPG-478/codex-chatgpt-bridge`	the planner-executor split done right: delegation-packet prompts (sender = a machine, not a human), mode-typed (`plan`/`review`/`debug`/`research`), strict `verdict: proceed\|revise\|blocked` schema with fail-fast parsing; same stable-reply detection we already use.

The honest caveats

This is a clever hack on a surface that was never meant to be an API. We're upfront about it:

No native function-calling on the browser surface. The web chat has no tool-call API (that's API-only), so Mode 2 defines a text protocol in the system prompt.

This caveat used to say the model refuses the text protocol — that live testing across three framings "all got refused", so we shouldn't fight it. That was a misdiagnosis, and it's now fixed. The model was never refusing; two transport bugs meant it never got a fair hearing:
1. a newline typed into the composer is a submit, so the multi-line system prompt was shredded into one chat message per line and ChatGPT only ever saw fragments of the protocol;
2. the reply parser only matched a literal ```json fence, which the rendered text we scrape can never contain — so any tool call it did emit was misread as a plain-text final answer and the loop exited on turn one.
With both fixed, turn 1 emits a tool call on its own (no priming nudge needed) and the loop runs to a correct answer. Still: this is a text protocol over a chat surface, not native function-calling — expect the occasional malformed turn. Native tool-calling remains better on the MCP channel (regular GPT-5.5) when it's available to you.
Pro is browser-only, and --model is currently broken. GPT-5.5 Pro — the strongest planner — cannot use Apps/MCP, so it's reachable only through the browser channel. Selecting it was automated by reverse-engineering the composer's Intelligence level picker (instant / high / pro). ChatGPT has since relabelled that picker to model names (observed 2026-08-31: the button reads 5.6 SolLight), so the selector no longer matches anything and --model cannot be applied. It now errors out rather than silently running on the account default — which is the dangerous failure, since the closed loop (work) must stay on a non-Pro level to keep its connector tools. Run without --model to accept whatever the account is set to. Updating the selector needs a look at the new menu (blocked on a rate limit at time of writing).
Connector goes stale on mcp restart. ChatGPT caches tools/list, so after you restart the server it may not see the tools until a manual Refresh. chatgpt-use refresh automates that click (live-verified against the settings UI); the closed loop is otherwise hands-off.
Instant tool-calling is run-to-run flaky. On the connector, ChatGPT-Instant sometimes hedges instead of calling a tool. work --retries re-nudges on a thin report, and --loop lets a task span many tool steps — but expect the occasional turn that needs a nudge.
Rate limits are real. Driving the one shared logged-in tab, the page rate-limits aggressively, so the channel runs at concurrency 1. Turns queue across processes on an advisory lock (~/.chatgpt-use/channel.lock), taken per turn so a long run/work never starves a one-shot ask. (This README used to claim that already existed; it didn't — two processes sharing a session interleaved inside one composer and merged their prompts.)
It's slower than the API. You're waiting on a browser rendering a chat. Fine for offloading; not for tight latency loops.
Mode 3 is the deep end. A full chat harness's traffic squeezed through a browser chat box: slow, occasionally wrong, and only as good as the tool-call translation. It's a proof-of-concept of "free Claude Code", not a daily driver — yet.
ToS — read this. OpenAI's Terms prohibit programmatically extracting Output and bypassing rate limits. So the honest positioning is not "web ChatGPT as a free API." It's: "use your own logged-in ChatGPT (esp. Pro) as a high-quality planner/reviewer in a local coding workflow; execution stays with Codex / Claude Code / local tools." Stay within your plan's terms; this is a personal productivity bridge, not a resale/automation-at-scale tool.
macOS first (matches chrome-use / cookie-use); other platforms follow chrome-use.

Install

Distribution follows the GitHub-Release route (no npm, no token). Once the first binary ships:

curl -fsSL https://raw.githubusercontent.com/leeguooooo/chatgpt-use/main/install.sh | sh

chatgpt-use requires chrome-use on PATH. If it's missing:

curl -fsSL https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.sh | sh

Then make sure you have a Chrome profile logged in to chatgpt.com (or connect your live Chrome via chrome-use extension connect).

Usage cheatsheet

# Closed loop — dispatch a task; ChatGPT DOES it on the project via its MCP
# connector (read/build/test/logs) and reports back. Needs the connector
# connected + an `mcp --profile full` server running; uses a non-Pro model.
chatgpt-use work "<task>"
#   --retries N    re-nudge if the report is thin / hedging (no real tool output). default 1
#   --loop         multi-turn: ChatGPT ends each report STATUS: DONE|CONTINUE; we auto-
#                  send "continue" until DONE — lets ONE task span many tool steps
#   --max-turns N  cap on loop turns (default 8)
#   --timeout S    per-turn wall-clock; work waits ≥1200s so a build/test can finish

# Re-sync the connector after restarting the mcp server (re-runs tools/list).
chatgpt-use refresh [--connector chatgpt-use] [--url <settings-url>]

# Sidekick — plain question (harness is the brain)
chatgpt-use ask "<question>" [--file <path> ...] [--profile auto|relay|"Profile N"]

# Structured delegation — ChatGPT plans/reviews, returns a verdict packet
chatgpt-use ask "<task>" --mode plan|review|debug|research --file <ctx> [--json] [--model pro]

# Hand the packet to a local executor (dry-run unless --execute)
chatgpt-use ask "<task>" --mode plan --json > plan.json
chatgpt-use handoff plan.json --to codex|claude-code [--cwd <dir>] [--execute]

# One-time setup — generate ~/.chatgpt-use/auth.json (mcp auto-loads it)
chatgpt-use init

# MCP channel — native tools for a regular GPT-5.5 (see MCP setup below)
chatgpt-use mcp --port 8788 [--token <secret>] --cwd <project>
#   tools (read-only): read_file/list_dir/grep + git_status/diff/log/show/blame + list_skills/read_skill
#   tools (full only):  write_file/edit_file/bash
#   --profile read-only (DEFAULT, safe to tunnel) | full (trusted/local only)
#   --permission-mode safe (DEFAULT) | trusted | dangerous   (gates bash + secret-env filter)
#   --bash-timeout S   per-command limit for the bash terminal (full profile; 0=unlimited)
#   --skills-dir <dir> root for list_skills/read_skill (default ~/.claude/skills; "" disables)
#   --auth-mode token (DEFAULT) | oauth                      (OAuth 2.1 + PKCE)
#   paths are workspace-sandboxed: absolute / ".." / symlink-escapes are rejected

# Full terminal for ChatGPT — let it run ANY command, like a shell (cwd + env persist):
chatgpt-use mcp --port 8788 --token "$(openssl rand -hex 16)" --cwd <project> \
  --profile full --permission-mode dangerous
#   ⚠️ 'dangerous' = NO command gating. Anyone with the URL + token gets a real
#      terminal on this machine. Keep the token secret; prefer NOT tunneling it.

# Mode 2 — brain (experimental browser tool loop)
chatgpt-use run "<task>" [--cwd <dir>] [--approve] [--max-steps N]
# Mode 3 — drop-in model (Claude Code keeps its loop; ChatGPT is the model)
chatgpt-use serve --port 8787   # then: ANTHROPIC_BASE_URL=http://127.0.0.1:8787 claude

# shared channel flags
#   --model     instant | medium | high | "extra high" | pro   (Pro is browser-only)
#   --profile   auto (default) | relay | "Profile 3"
#   --session   reuse a chrome-use tab group   --project  file under a ChatGPT Project

MCP channel setup (regular GPT-5.5)

chatgpt-use mcp exposes the project tools (read_file/write_file/list_dir/grep/bash) as a JSON-RPC MCP server so a regular GPT-5.5 can call them natively (Pro can't use MCP). Since ChatGPT is in the cloud, expose the local server through a public HTTPS tunnel, then register it in ChatGPT → Settings → Apps → Add custom connector:

chatgpt-use mcp --port 8788 --token "$(openssl rand -hex 16)" --cwd /path/to/project
cloudflared tunnel --url http://127.0.0.1:8788     # → paste the https URL into ChatGPT
#   connector auth header:  Authorization: Bearer <your token>

⚠️ Default is --profile read-only (read_file/list_dir/grep, paths sandboxed to --cwd), so a tunneled server can't write files or run shell. Only pass --profile full on a trusted, non-exposed setup — there bash/write_file run without approval, so a leaked tunnel URL + token = shell access to --cwd. Always use a random --token, scope --cwd, and prefer ephemeral tunnels. Full step-by-step + security notes: docs/mcp-setup.html.

Give ChatGPT a real terminal

Under --profile full, the bash tool is a persistent shell session, not one-off commands: the working directory and exported environment carry over between calls, so ChatGPT can cd build/ && cmake .. && make, then ./run_tests in the next call, then export RUST_LOG=debug and have it stick — exactly like a terminal. Each command is bounded by --bash-timeout (default 300s; 0 = unlimited) so a hung command can't freeze the server, and a fresh session starts on each server restart.

Command gating depends on --permission-mode:

Mode	What `bash` may run
`safe` (default)	blocks destructive (`rm -rf`…), network (`curl`/`ssh`…), and `$(…)`/backticks; strips secret-looking env
`trusted`	blocks only catastrophic commands; still strips secret env
`dangerous`	no gating at all — a full, unrestricted terminal; full env passed through

So to let ChatGPT "run any command like a terminal", run the server with --profile full --permission-mode dangerous. That is a remote shell on your machine for anyone holding the URL + token — use a strong random --token, scope --cwd, and strongly prefer keeping it local / off any public tunnel. The server prints a loud warning when started this way.

Required one-time setup — turn off the per-call approval prompt. ChatGPT pops an "Allow ChatGPT to use chatgpt-use? Deny / Allow once / Always allow" dialog before every connector tool call. An automated work run can't click it, so the call hangs and never reaches the server (you'll see work stall with no output, and nothing in the server log). Fix it once: in any chat, when the dialog appears click Always allow → Always allow (without confirmation), or set it under Settings → Apps → chatgpt-use → permissions. After that the closed loop is truly hands-off. (This is you granting standing approval to an unrestricted terminal — deliberate by design; the tool will not auto-click that safety prompt for you.)

Diagnosing: the server logs every request — [mcp] → tools/call bash {…} in ~/.chatgpt-use/mcp.log means a call genuinely arrived. If a work run "reports success" but no such line appears, ChatGPT regurgitated cached/project-memory output without actually running the tool — check the log (and, for side-effecting commands, the real filesystem) to be sure.

Let ChatGPT use your local agent skills

If this machine has agent skills (the ~/.claude/skills/<name>/SKILL.md ecosystem — browser automation, email, image generation, Feishu/Lark ops, …), ChatGPT can discover and run them through two connector tools:

Tool	What it does
`list_skills`	lists every skill on the machine (name + one-line description)
`read_skill {name}`	returns that skill's full `SKILL.md` + a listing of its files

The flow is list_skills → read_skill → bash: ChatGPT discovers a skill, reads how to use it, then runs its CLI with the persistent bash terminal. Live-verified across all three skill shapes (the server log confirms the actual tool calls each time):

Skill shape	Example	What ChatGPT did (from the server log)
Prompt-only	`chinese-commit`	given a natural task with no tool names, it auto-triggered `list_skills → read_skill chinese-commit`, then produced a Conventional-Commits message following the skill
CLI wrapper	`chrome-use`	`read_skill` then `bash chrome-use --help`
Bundled script	`lark-slides` (its `xml_text_overlap_lint.py`)	`read_skill` → ran the script, hit a usage error, ran `--help` to learn the flag, self-corrected, then ran it with `--input`; output matched the locally-computed ground truth exactly

Two requirements:

Profile / approval: discovery tools are read-only (available in any profile); actually running a skill needs --profile full (the bash tool) and the one-time "always allow" above.
The skill's CLI must be on the server's PATH. Skills are mostly thin wrappers over a CLI (chrome-use, mailbox, imagegen, the lark-* tools). If the server can't find the binary you'll see command not found — add its dir (e.g. ~/.local/bin, ~/.bun/bin) to the server's PATH (in the launchd plist's EnvironmentVariables, or the shell that launches mcp).

--skills-dir <dir> points discovery at a different root; --skills-dir "" disables it. Note: skills written purely for the Claude Code harness (those that say "use the Read/Edit tool") won't translate — but anything CLI-backed runs fine through bash.

Working long enough · loops · scheduled runs

ChatGPT can sit quiet for minutes while a connector bash build/test runs. work is tuned for that: it waits up to --timeout (≥1200s) per turn and only gives up after ~3 min of total silence (no streaming, no active-tool indicator). So a single work turn already covers a multi-minute build.

For tasks too big for one reply, --loop spans turns: ChatGPT ends each report with STATUS: DONE or STATUS: CONTINUE, and work auto-sends "continue" until it's DONE (or --max-turns):

chatgpt-use work "port every callsite of send() to send_with(), run cargo test after each, until green" \
  --loop --max-turns 12 --retries 2

Scheduled / recurring work — drive work from launchd (macOS) or cron. The job needs the user's Chrome running and logged into ChatGPT (chrome-use relays through the live browser), and the mcp server + tunnel up. A ready template lives at examples/work-nightly.plist:

# nightly "smoke" report at 03:00 — edit the task + path, then:
cp examples/work-nightly.plist ~/Library/LaunchAgents/com.you.chatgpt-use-nightly.plist
launchctl load ~/Library/LaunchAgents/com.you.chatgpt-use-nightly.plist
# every result is appended to ~/.chatgpt-use/ledger.jsonl (kind:"work")

cron equivalent: 0 3 * * * /Users/you/.local/bin/chatgpt-use work "run the test suite and summarize failures" >> ~/.chatgpt-use/nightly.log 2>&1

Roadmap

Kept as open research tracks (not abandoned):

Mode 2 run (autonomous browser tool loop) — the "model often refuses" verdict turned out to be two transport bugs, not model behaviour: typed newlines were submitting the system prompt one line at a time, and the reply parser matched a markdown fence that rendered text never contains. With both fixed the loop runs end-to-end (turn 1 calls a tool unprompted; the one-shot priming nudge is now a rarely-used fallback). Still experimental — it's a text protocol over a chat surface.
Mode 3 serve (Anthropic drop-in) — same wall; PoC only for now.
Optional UI shell (TUI / menubar) for live progress & approval.

Status (honest): Two channels are now live-verified end-to-end against real ChatGPT. Browser channel: ask, structured delegation (ask --mode plan → a valid DelegationPacket), --model pro (switches the level on the page), and handoff all work, filing under the project. MCP channel: a regular GPT-5.5 (Instant) called our local read_file over a named cloudflared tunnel and returned a random probe string — so ChatGPT genuinely runs our tools, no role-play. The only thing still unsolved is Modes 2 & 3 (making web ChatGPT autonomously call tools via a text protocol) — that hits the role-play wall; the MCP channel is the right way to get native tools.

Credits

Stands on the shoulders of chrome-use (browser automation), chatgpt-imagegen (the web-driving playbook), and cookie-use (the CLI-on-chrome-use model).

Idea seeded by @VincentLogic.

License

MIT

The `*-use` family

Small, composable CLIs that give an AI agent hands on one real thing. Same shape everywhere: curl … install.sh | sh to install, npx skills add leeguooooo/<name> to teach your agent, JSON on stdout.

Repo	Gives your agent
chrome-use	A real browser — logged-in sessions, forms, scraping, screenshots
mail-use	Email — read, search, send, triage across Gmail / QQ / 163 / any IMAP
iphone-use	A real iPhone — tap, type, screenshot, pull on-device data
wechat-use	WeChat on macOS — send messages, query contacts and history
discord-use	Discord — messages, channels, forums, webhooks (REST-only, Rust)
cookie-use	Many logged-in accounts per site — capture, switch, apply sessions
profile-use	Your personal profile, safely — fill signup / KYC / checkout forms
bitwarden-use	Bitwarden / Vaultwarden — headless passkey (FIDO2) login
computer-use	The macOS desktop itself
pixcake-use	Read-only PixCake probing — snapshot / diff / SQLite inspection

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
assets		assets
docs		docs
examples		examples
src		src
.gitignore		.gitignore
Cargo.lock		Cargo.lock
Cargo.toml		Cargo.toml
LICENSE		LICENSE
README.md		README.md
SKILL.md		SKILL.md
WORKPROBE.txt		WORKPROBE.txt
install.sh		install.sh

Navigation Menu

Repository files navigation

chatgpt-use

Why this exists

Three modes

Mode 1 · 副手 / Sidekick — `chatgpt-use ask`

Mode 2 · 大脑 / Brain — `chatgpt-use run`

Mode 3 · 替身 / Drop-in model — `chatgpt-use serve`

How it works

Target architecture: dual-channel by model tier

Prior art we're borrowing from

The honest caveats

Install

Usage cheatsheet

MCP channel setup (regular GPT-5.5)

Give ChatGPT a real terminal

Let ChatGPT use your local agent skills

Working long enough · loops · scheduled runs

Roadmap

Credits

License

The `*-use` family

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

chatgpt-use

Why this exists

Three modes

Mode 1 · 副手 / Sidekick — chatgpt-use ask

Mode 2 · 大脑 / Brain — chatgpt-use run

Mode 3 · 替身 / Drop-in model — chatgpt-use serve

How it works

Target architecture: dual-channel by model tier

Prior art we're borrowing from

The honest caveats

Install

Usage cheatsheet

MCP channel setup (regular GPT-5.5)

Give ChatGPT a real terminal

Let ChatGPT use your local agent skills

Working long enough · loops · scheduled runs

Roadmap

Credits

License

The *-use family

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages

Mode 1 · 副手 / Sidekick — `chatgpt-use ask`

Mode 2 · 大脑 / Brain — `chatgpt-use run`

Mode 3 · 替身 / Drop-in model — `chatgpt-use serve`

The `*-use` family