# gpt-ai-assistant: a LINE bot that puts the OpenAI API behind a chat app

> This is a Node.js webhook server that connects the LINE Messaging API to the OpenAI API, so you can talk to your own assistant from the LINE mobile app. It deploys to Vercel or Docker, and the configuration lives in environment variables.

**memochou1993/gpt-ai-assistant** — OpenAI + LINE + Vercel = GPT AI Assistant

- Repository: https://github.com/memochou1993/gpt-ai-assistant
- Website: https://memochou1993.github.io/gpt-ai-assistant-docs/
- Stars: 7,740 · Forks: 9,536
- Language: JavaScript
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/memochou1993-gpt-ai-assistant

## What gpt-ai-assistant actually solves for LINE users

The problem is narrow but real. OpenAI gives you an API, not a chat client. If you want an assistant you can message from a phone, you need a messaging platform with a bot API, a server that receives its webhooks, and glue that translates between the two payload formats. gpt-ai-assistant is that glue, written in JavaScript and packaged as an Express application.

The target user is someone who already uses LINE and wants a personal assistant inside it, not a general-purpose chatbot framework. The README is explicit about the shape of the thing: "GPT AI Assistant is an application that is implemented using the OpenAI API and LINE Messaging API. Through the installation process, you can start chatting with your own AI assistant using the LINE mobile app." There is no web UI, no dashboard, and no admin panel in the repository layout. Configuration happens through environment variables, and conversation happens in LINE.

That constraint is also the design. The project does not try to be a platform. It is a single webhook endpoint with a set of commands layered on top, which is why the dependency list is short: axios, dotenv, express, form-data, gpt-3-encoder and opencc-js.

## The request path from a LINE message to an OpenAI completion

The repository layout tells you most of the architecture. There is an api/ directory holding the entry point (api/index.js, per the package.json scripts), a middleware/ directory for request handling, a services/ directory for outbound calls, a storage/ directory, a config/ directory, and a constants/ directory. The two services that matter are the OpenAI client and the LINE client, and the middleware sits between the incoming webhook and those services.

The flow is the standard webhook pattern. LINE posts an event to your endpoint, the middleware verifies and parses it, the application builds a prompt from prior messages, sends it to the OpenAI API, and posts the reply back through the LINE Messaging API. The presence of gpt-3-encoder in the dependency list is the tell that prompt length is managed locally: the code tokenizes text before sending it, which is what the APP_MAX_PROMPT_TOKENS and APP_MAX_PROMPT_MESSAGES variables control. opencc-js handles Chinese character conversion, which fits a project whose documentation ships in Chinese and English.

The rest of the environment variables describe the assistant's identity and limits rather than its plumbing. BOT_NAME, BOT_TONE, BOT_INIT_PROMPT, HUMAN_NAME and HUMAN_INIT_PROMPT shape the persona. APP_MAX_GROUPS and APP_MAX_USERS cap how many conversations the bot will take on. BOT_DEACTIVATED is a kill switch, and ERROR_MESSAGE_DISABLED suppresses error replies. These are all read from the environment, so behavior changes require a redeploy rather than a code change.

## Installing gpt-ai-assistant and sending a first message

The repository supports two deployment routes. The Dockerfile builds on node:18-alpine, copies the working tree, runs npm ci --only=production, and starts with npm start. The docker-compose.yaml defines a single service named app with container_name gpt-ai-assistant, restart: always, and a port mapping built from ${APP_PORT} on both sides. Vercel is the other route, indicated by vercel.json and the VERCEL_* variables in .env.example.

The environment file is the starting point. The example file lists every key the application reads, and most of them are empty, so you fill in credentials yourself.

```bash
APP_DEBUG=true
APP_URL=
APP_PORT=3000
APP_LANG=
APP_WEBHOOK_PATH=
APP_API_TIMEOUT=
```

The two credentials the application cannot run without are the LINE channel pair and the OpenAI key. The LINE values come from your LINE Developers channel; the OpenAI value comes from your OpenAI account.

```bash
LINE_CHANNEL_ACCESS_TOKEN=
LINE_CHANNEL_SECRET=
OPENAI_API_KEY=
```

For a local run, the dev script uses nodemon against api/index.js. For a container run, compose reads the same environment file and maps the port through.

```bash
npm run dev
```

```bash
docker compose up
```

After the service is up and reachable, register the public URL plus your webhook path in the LINE Developers console, then add the bot as a friend in the LINE app and send it a message. The README states the intended outcome plainly: you chat with your own assistant through the LINE mobile app. If nothing comes back, check the LINE channel token and secret first, since a failed webhook verification produces no visible reply.

## Where gpt-ai-assistant stops being the right tool

The biggest limitation is stated by the project itself. The README carries a note pointing readers to a successor: "fermi is the spiritual successor to this project", described as a self-hostable, chat-based LINE assistant built on Supabase and OpenRouter. A maintainer writing that into the README is a signal about where future work goes. The last push to this repository was on 2026-06-08, and the most recent release listed is v4.9.1 from 2024-07-09, so the release cadence is not what it was.

The second limitation is coupling. Everything runs through LINE. If your users are on WhatsApp, Slack, Telegram or a web page, this project gives you nothing reusable beyond the prompt-building logic, and that logic is not published as a separate package. You would be forking the services and middleware directories.

Third, the configuration model is environment variables only. There is no per-user settings store exposed in the repository layout beyond the storage/ directory, and no documented admin interface. Changing the bot's tone or init prompt means editing the environment file and redeploying. For a personal assistant that is fine. For a shared deployment with non-technical operators it is awkward.

Finally, the OpenAI integration is completion-shaped. The variable names include OPENAI_COMPLETION_MODEL, OPENAI_COMPLETION_TEMPERATURE and OPENAI_COMPLETION_MAX_TOKENS, alongside OPENAI_IMAGE_GENERATION_MODEL and OPENAI_VISION_MODEL. Whether a given current model name works with these keys is not answered by the README, and that is exactly the kind of thing that breaks silently when a provider deprecates an endpoint.

## How it differs from calling the OpenAI API from your own client

The obvious alternative is to skip the bot entirely and call the OpenAI API from a script or a desktop client you control. The difference in approach is who owns the conversation state and the delivery channel. A direct client keeps everything on your machine: no webhook, no public URL, no LINE channel, no shared secret to leak. gpt-ai-assistant trades that for reach, because the conversation lives in a messaging app you already have open.

A second alternative is a general bot framework that supports multiple messaging platforms behind one abstraction. Those frameworks let you add a LINE adapter alongside Slack and Telegram. The trade here is the reverse: you gain channel flexibility and lose the tight, opinionated fit with LINE's payload format, plus you inherit a larger dependency tree. gpt-ai-assistant's dependency list is six runtime packages, which is small enough to read in an afternoon.

There is also the successor project the README names, fermi, built on Supabase and OpenRouter. That is a different stack decision: Supabase for storage and OpenRouter as the model gateway. If you want to avoid being tied to one model vendor's API shape, that routing layer is the meaningful difference, and it is the option the maintainer points at.

## Maintenance cost, licence and what to watch on upgrade

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the whole of the licence implication here; anything beyond it depends on your own legal review, and the repository's LICENSE file is the authoritative text.

Upgrade cost is dominated by two things that are outside the project's control. The first is the OpenAI API surface. Because model selection is an environment variable rather than a pinned constant, an upgrade that changes model availability is a configuration edit, not a code change, which is convenient until the request shape itself changes. The second is the LINE Messaging API. Webhook verification and reply token handling are the parts most likely to need attention, and they live in middleware/ and services/.

The project's own versioning is straightforward: package.json declares version 4.9.1 and the releases page carries v4.9.1, v4.9.0 and v4.8.4 from July 2024. The CHANGELOG.md at the repository root and the release notes are where detailed changes are documented, per the README. There is no documented migration guide for jumping between major versions, so read the release notes before moving.

One practical upgrade note: the Dockerfile runs npm ci --only=production against a committed package-lock.json. That means container builds are reproducible, but also that dependency updates require regenerating the lockfile rather than relying on a floating range.

## Conclusion

Adopt it if you already live in LINE and want a personal assistant reachable from that app, and you are willing to manage OpenAI and LINE credentials plus a webhook. Do not adopt it if you need a stable, versioned API surface: the package version is 4.9.1, the newest release listed is v4.9.1 from 2024-07-09, and the repository itself points to a successor project. Before committing, verify that the OpenAI model names you intend to use are accepted by the OPENAI_COMPLETION_MODEL key, and confirm the webhook path and port against your own deployment target.

## FAQ

### Does gpt-ai-assistant require a paid OpenAI account?

The application reads OPENAI_API_KEY from the environment and calls the OpenAI API, so it needs a working API key from your OpenAI account. The README does not describe any free tier or bundled credit, and billing terms are set by OpenAI rather than by this project.

### Can I run gpt-ai-assistant without Vercel?

Yes. The repository ships a Dockerfile based on node:18-alpine and a docker-compose.yaml with a single app service, so a container deployment is a supported path. Vercel is the other route, indicated by vercel.json and the VERCEL_* environment variables.

### How do I change the assistant's personality in gpt-ai-assistant?

Set BOT_NAME, BOT_TONE and BOT_INIT_PROMPT in your environment file, along with HUMAN_NAME and HUMAN_INIT_PROMPT for the user side. The example file lists all of these keys, and they are read at startup, so a redeploy applies the change.

### Is gpt-ai-assistant still being developed?

The last push to the repository was on 2026-06-08, and the newest release listed is v4.9.1 from 2024-07-09. The README also points readers to a successor project, fermi, described there as the spiritual successor.

## Sources

- [License: MIT](https://github.com/memochou1993/gpt-ai-assistant/blob/main/LICENSE)
- [memochou1993/gpt-ai-assistant on GitHub](https://github.com/memochou1993/gpt-ai-assistant)
- [Project website](https://memochou1993.github.io/gpt-ai-assistant-docs/)
- [README](https://github.com/memochou1993/gpt-ai-assistant/blob/main/README.md)
- [Releases](https://github.com/memochou1993/gpt-ai-assistant/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/memochou1993-gpt-ai-assistant