Poe server bot quick start: Modal examples and first deployment

What the Poe bot starter repository covers

This repository addresses the gap between registering a bot with Poe and implementing the server behavior that receives queries and produces responses. Its intended audience is developers following the linked Poe creator tutorial who want small examples for FastAPI, `fastapi_poe`, and Modal deployment. The repository is a companion to the documentation, not an independent bot platform. The README assumes that Modal has already been configured and points to the Poe quick start for those instructions.

The examples cover several distinct response paths. `EchoBot` repeats a user's query and is the designated first check for the `fastapi_poe` and Modal setup. `PromptBot` asks Claude-3-Haiku to produce haikus through a server-side model call. `WrapperBot` places an OpenAI-compatible API behind the Poe bot interface. Other samples cover Markdown, uploaded images and PDFs, returned images and video, function calling, request inspection, and responses that compare two models.

That range is useful because each example isolates one integration concern. For instance, `VideoBot` concerns attaching files to a response, while `PDFCounterBot` concerns accepting a user-uploaded file. `FunctionCallingBot` demonstrates a function call, but `FunctionCallingLoopBot` goes further by managing a loop and retaining tool details for later queries. The difference matters because a single response-generation sample does not explain attachment handling or stateful tool orchestration.

The repository should not be mistaken for a general application scaffold. Its files are named for individual capabilities, and the README presents them as demonstrations with separate deployment commands. There is no stated persistence layer, administration interface, user account system, billing implementation, or production deployment policy in the repository files.

EchoBot as the first Poe and Modal checkpoint

The shortest path described by the README is `EchoBot`. It receives a user's query and repeats it in the response. That behavior removes any model provider from the first verification step, so a successful result is evidence that the Poe-to-Modal path is at least connected. The README specifically recommends reproducing this bot before building other server bots because it checks both `fastapi_poe` and Modal.

The deployment command is already defined at the file level:

modal deploy echobot.py

This command deploys only `echobot.py`. The README does not provide the preceding account setup, authentication, token export, or Poe bot creation steps, so readers must obtain those from the linked tutorial at `https://creator.poe.com/docs/quick-start`. After deployment, the expected application behavior is simple: send a query to the configured Poe bot and receive the same query back. The README links `https://poe.com/EchoBotDemo` as an implementation of that behavior.

If EchoBot fails, later samples will not isolate whether a problem belongs to the Poe integration, Modal deployment, or a third-party API. This makes EchoBot the correct first checkpoint rather than merely the easiest example. It also gives developers a baseline before dealing with streaming, credentials, model calls, file uploads, or response attachments.

PromptBot, WrapperBot, and model cost paths

The text examples show two different ways to obtain a model response. `PromptBot` calls a Poe server model and uses Claude-3-Haiku with a system prompt that requests haikus. The README says this arrangement demonstrates how the Poe platform can cover the chatbot's inference costs. Its deployment target is:

modal deploy prompt_bot.py

Before using it, the bot settings must be synchronized with the Poe Platform. The README links the server bots functional guide for that update, so running the Modal deployment alone does not complete the setup.

`WrapperBot` takes a different route. It demonstrates wrapping the OpenAI API with the developer's own API key, then deploys `wrapper_bot.py`:

modal deploy wrapper_bot.py

The important distinction is billing and infrastructure ownership. In the PromptBot example, Poe-hosted inference is the stated cost path. In WrapperBot, the developer supplies the provider credential. The repository does not document secret handling for that key, provider retry policy, rate-limit handling, or cost accounting, so this is a reference path rather than a complete provider integration.

`SDXLBot` follows the same provider-wrapper pattern for image generation. It calls Fireworks AI's StableDiffusionXL endpoint, requires the developer's own key, and allows the URL to be changed to another provider or model. This flexibility is useful for understanding the wrapper boundary, but the README does not define a provider interface, response validation, upload limits, or failure handling.

Attachments, Markdown, and request context samples

The repository separates input and output attachment concerns. `PDFCounterBot` enables file upload for users and counts a submitted PDF, according to its description. `VideoBot` attaches a video file to the bot response, while the README notes that other file types are handled in a similar fashion. `ImageResponseBot` renders an image through Markdown. These are separate examples because inbound uploads and outbound files exercise different response capabilities.

`ClothingRecommenderBot` combines both sides of that boundary. It accepts a user-uploaded image, analyzes it with Claude-Sonnet-4.6, recommends a new top, and generates an image of that clothing with Imagen-4. The README presents this as a starting point for handling uploaded and returned attachments. It is more representative of a multi-step bot than EchoBot, but its dependency chain also makes it a less isolated diagnostic.

`CatBot` demonstrates Markdown capabilities, with additional instructions in `catbot.md`. `HTTPRequestBot` accesses HTTP request information, and `LogBot` illustrates the contents of the `QueryRequest` object. These examples are useful when determining what context a handler receives. However, the README does not document logging retention, privacy treatment for request data, authentication, authorization, file size limits, malware scanning, or attachment cleanup. Those security and operational boundaries cannot be inferred from the demos.

The project also includes `PythonRunnerBot`, described as generating code from a query, running it with the `@Python` bot, and attempting to debug it if an issue occurs. The README characterizes it as a starting point for chaining requests across text models. It is a workflow sample, not evidence that arbitrary generated code can be safely hosted without additional controls.

Function calling beyond a single tool invocation

`FunctionCallingBot` and `FunctionCallingLoopBot` should be compared before choosing an architecture for tool-using bots. The first demonstrates the Poe API's function-calling mechanism. The second manages a function-calling loop and preserves function or tool details in the chat so later user queries can use them. This turns a one-step response into a conversation with retained tool context.

Each has its own deployment entry point:

modal deploy function_calling_bot.py
modal deploy function_calling_loop_bot.py

The README requires Poe bot settings to be synchronized before either bot can be used. It links the same server bots functional guide used by PromptBot, VideoBot, PDFCounterBot, and other model-backed examples.

The repository does not specify how long tool details are retained, where that state is stored, whether concurrent conversations are isolated, or what happens after a deployment. The term "chat" in the README should therefore be understood as the demonstrated conversation state, not as a documented production persistence contract. Developers who need resumable sessions or strict tenant isolation would need an explicit storage design that this repository does not provide.

For a narrow tool call, `FunctionCallingBot` is the clearer example. For multi-turn behavior, the loop sample exposes the additional state-management problem. Neither file should be adopted as a complete orchestration framework based on the README alone.

Maintenance, licensing, and adoption costs

The repository is not archived, and its last push was on 2026-10-12. There are no GitHub releases, so the README's deployment commands are not tied to a documented sequence of tagged releases. Upgrade planning must account for the single unpinned dependency in `requirements.txt`:

fastapi-poe

No version constraint is declared there. The formatting configuration in `pyproject.toml` targets Python 3.7 syntax for Black, but the file does not define the runtime Python version used in Modal. The repository therefore does not provide enough version metadata to construct a fully reproducible environment from the repository files alone.

The repository's license is unknown. That is a direct reuse constraint for engineers planning to copy substantial example code into another repository or distribute a derived bot package. This review does not give legal advice, and no license should be inferred from the absence of a visible license entry in the repository information.

There is also no release history to indicate whether examples and the linked Poe tutorial move together. For production use, the main upgrade work is likely to involve checking compatibility among Poe bot settings, `fastapi_poe`, Modal deployment behavior, external model APIs, and any unversioned dependencies. The examples make that path visible, but they do not automate compatibility checks.

Editorial conclusion

Developers who want a concrete Poe bot prototype should begin with EchoBot, while teams needing production persistence, authentication policy, observability, or licensing clarity should not treat this tutorial repository as their application framework. Before adoption, verify that the linked Poe tutorial still matches the deployed `fastapi_poe` behavior, configure every required external credential, and confirm the repository's license before reusing or redistributing the examples.

Frequently asked questions

Official sources

1. Issues
2. poe-platform/server-bot-quick-start on GitHub
3. README