gpt-newspaper: Building an AI Newsroom with LangGraph

The personalized-edition problem gpt-newspaper addresses

gpt-newspaper is aimed at readers who want a newspaper assembled around selected subjects rather than a general feed ordered by popularity. A user supplies topics, and the project researches them, writes articles, checks drafts, creates or selects images, lays out pages, and publishes the result as an edition. That makes it a publishing application built around current news research, not a conventional newspaper archive or an offline document generator.

The project is also aimed at developers evaluating LangGraph applications. Its repository includes a FastAPI application, browser interface, Docker configuration, tests, environment template, and `langgraph.json`. The README also describes web, API, CLI, and LangGraph Studio interfaces from one codebase, although the CLI section is truncated and does not provide a usable command in the available documentation.

Every edition depends on external services. Tavily supplies the news search index and article text. A selected LangChain model writes and reviews content. The default illustration path additionally requires OpenAI image generation. An Ollama model can replace the text model, but it does not replace Tavily, and the documentation says source photographs replace generated illustrations when no image key is available. This service boundary should shape the adoption decision more than the newspaper metaphor does.

How the LangGraph newsroom processes a topic

The workflow begins with an assignment editor that converts each topic into targeted searches covering several angles. Those searches fan out through LangGraph's `Send` API. Search workers query Tavily's news index for article text, image candidates, and site favicons. Topics can therefore progress concurrently rather than forcing every edition through a single serial chain.

A curator filters results for topical relevance, ranks the remaining material, and selects an image candidate. The README says the search window begins at `NEWS_TIME_RANGE`, which defaults to `week`. When no suitable news exists in that window, the reporter widens the range from a week to a month and then a year. This is a documented behavior for sparse topics, but it also means a requested edition may contain older reporting than its interface suggests.

The writer receives the retained source material and produces an article, headline, summary, pull quote, and inline citations in the selected language. A critic then checks relevance, source support, citations, and clarity. Rejected drafts return to the writer up to `MAX_REVISIONS`, whose default is `2`. An art director creates slot-sized artwork when image generation is configured, while a designer lays out the article with its citation list, sources, pull quote, and reading time.

Completed stories return to an editor-in-chief, which writes the opening note and composes the front page. A publisher saves the edition under `./outputs` and adds it to the archive. The README says live progress is streamed to the browser, including topics, workflow stages, editor notes, and completed stories. Based on the documented graph, this is a stateful orchestration design with explicit agent responsibilities, not a single prompt asking a model to imitate a newsroom.

Installing gpt-newspaper and printing a first edition

The documented local path requires Python 3.11 or later, a Tavily API key, and a key for the selected model provider. Alternatively, the README permits a local Ollama model. Clone the repository, install its dependencies, and start the application with these documented commands:

git clone https://github.com/rotemweiss57/gpt-newspaper.git
cd gpt-newspaper
pip install -r requirements.txt
python app.py

After startup, open `http://localhost:8000`. Under Model & API keys, enter the required keys, select one or more topics, and press Print my newspaper. The interface should show the newsroom workflow while an edition is being assembled. The README does not document the exact first-page appearance for an empty or failed edition.

The Docker path is shorter when container startup and persistent output storage are preferred:

docker compose up --build

The Compose file maps port `8000` from the host to port `8000` in the container. It reads `.env` when that file exists and maps `./outputs` to `/app/outputs`. No `.env` is required for startup according to the Compose definition, but a Tavily key and a usable text model configuration are still needed to produce a researched edition.

For `uv`, the README provides optional provider extras. This example installs the Anthropic integration:

uv sync --extra anthropic
uv run app.py

The declared extras are `anthropic`, `google`, `ollama`, `groq`, `mistral`, and `all`. The provider integration must match the configured model string. For example, selecting `anthropic:claude-sonnet-5-5` also requires `pip install langchain-anthropic` when using the basic requirements-based setup.

Provider configuration, citations, and output controls

Model selection uses a `provider:model` string passed through LangChain's `init_chat_model` mechanism. The default is `openai:gpt-5.4-mini`, with `OPENAI_API_KEY`. The README lists separate install commands and key variables for Anthropic, Google, Groq, and Ollama. This is a useful replacement mechanism, but it does not make all providers operationally equivalent. Supported integrations, account access, context handling, output structure, availability, and billing remain provider-specific.

gpt-newspaper treats retrieved sources as untrusted data rather than executable instructions. The critic checks factual claims against those sources and the writer is instructed to attach inline citations. That reduces a particular class of prompt-injection risk, but it should not be confused with guaranteed factual accuracy. The documented critic is another model pass, and the project does not claim that approval establishes independent verification.

Several environment variables control editorial and operational behavior. `SEARCHES_PER_TOPIC` defaults to `2`, while `SOURCES_PER_ARTICLE` defaults to `5`. Setting the search count to `1` skips the planner according to the README. `MAX_CONCURRENT_EDITIONS` defaults to `4`, and requests beyond that capacity receive HTTP 429. `ALLOW_MODEL_OVERRIDE` defaults to `true`, so visitors can select a model per edition unless an operator changes that setting.

Illustrations use `IMAGE_MODEL`, which defaults to `openai:gpt-image-2`, and `IMAGE_QUALITY`, which defaults to `medium`. `IMAGE_STYLE` accepts `ink`, `engraving`, `risograph`, or `photos`. The first three commission AI artwork, while `photos` uses source imagery. Generated art must depict a visual metaphor without real people and must be labeled as an AI illustration. Without an OpenAI key for image generation, the documented fallback is to use news photographs from sources.

The project supports 17 languages, including right-to-left layouts, and can print or save a PDF. Generated editions are stored under `./outputs`. Browser-entered keys remain in the browser according to the README, while `.env` supports server-side configuration.

Where gpt-newspaper fails or is the wrong tool

The most visible constraint is the combination of paid or externally hosted dependencies. Tavily is required for the documented search flow, and most hosted model options require their own accounts and keys. Generated illustrations introduce a separate OpenAI requirement unless the configuration falls back to source photographs. Operators therefore need to account for search calls, model tokens, image requests, and concurrent edition capacity rather than treating a generated newspaper as a local zero-cost utility.

The quality boundary is also clear. A personalized edition generated from recent search results is not the same as a staffed news organization with independent reporting contracts. Although the workflow includes a critic and source citations, the critic operates within the same agent system. The README does not document human editorial approval, source licensing guarantees, corrections procedures, or a formal fact-checking standard. Users who require guaranteed reporting accuracy should not treat the edition as an authoritative primary record.

Topic freshness can vary. Automatic widening from one week to one month and then one year helps when current coverage is sparse, but it can produce an edition whose stories do not match a requested recency expectation. Sparse topics may also lead to weak source pools because only `SOURCES_PER_ARTICLE` sources are retained by default.

The repository should not be chosen as a static site generator, RSS reader, or conventional daily-news subscription. It creates a new researched edition through an agent workflow. Users who need deterministic templates without model calls, or who cannot supply external search and model services, should choose a static publishing pipeline instead.

Docker deployment, maintenance, and licensing boundaries

The Docker deployment supports repeatable setup with an optional `.env`, persistent output storage, and a health check against `http://127.0.0.1:8000/api/health`. The image uses Python 3.12, installs `requirements.txt` plus a configurable `EXTRA_PACKAGES`, runs as UID `10001`, and grants that user write access only to `/app/outputs`. This separation limits the application's writable filesystem, although container security still depends on the deployment environment.

The last push was on 2026-10-10, so the repository was recently updated. It is not archived, but it has no GitHub releases. Upgrade planning therefore cannot rely on published GitHub release artifacts or a stated release cadence. The presence of `CHANGELOG.md`, CI configuration, tests, pre-commit configuration, and `uv.lock` helps with repository-based maintenance, but the available documentation does not promise compatibility across unreleased revisions.

The project is presented under the MIT license, and the repository includes a `LICENSE` file. There is a packaging inconsistency worth checking before redistribution: `pyproject.toml` declares `licence = { file = "LICENCE" }`, while the top-level repository entry is `LICENSE`. That mismatch may affect automated license metadata even though the README badge points to `LICENSE`. It is not legal advice; it is a concrete repository consistency issue.

For upgrades, operators must review changes to LangGraph, LangChain, provider integrations, the Docker base image, and output templates. Because there are no GitHub releases, adopting a particular commit and preserving the working configuration is more concrete than assuming that a named stable release exists.

Comparing gpt-newspaper with static and conventional news pipelines

A static publishing pipeline uses curated source files or manual articles, then renders predictable HTML or PDF output without requiring a live search or language model for every edition. That approach is easier to audit, cheaper for repeated generation, and more suitable when layout consistency matters more than personalization. gpt-newspaper deliberately chooses the opposite boundary: it performs fresh research and coordinates multiple agent roles for each requested edition.

A conventional news aggregator is another alternative. It retrieves and displays existing publisher feeds or articles, but it does not normally write a new article, critique it, commission artwork, or compose a front page. gpt-newspaper therefore adds synthesis and presentation while inheriting the source limitations of search results.

The project is most relevant when the desired output is an AI-produced personalized edition and the operator accepts model and service dependencies. It is less appropriate for archival fidelity, legally controlled redistribution, strict deterministic builds, or editorial standards requiring human sign-off. The README documents citations and source selection, but it does not document a license or rights policy for republishing source text and photographs.

Editorial conclusion

gpt-newspaper is suitable for developers experimenting with visible multi-agent publishing, personalized research editions, or LangGraph orchestration. It is a poor fit for users needing a conventional news source, strict editorial independence, or predictable low-cost operation. Before adoption, verify provider availability for the selected `LLM_MODEL`, the need for Tavily, the behavior of illustration generation, and the discrepancy between the documented `LICENSE` file and the `licence = { file = "LICENCE" }` entry in `pyproject.toml`.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rotemweiss57/gpt-newspaper on GitHub