This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
Slothgram: ONE DEV ONE POST.
You ship something, then open four tabs, rewrite the same update four times, pick hashtags, and publish one platform at a time. Slothgram turns that into one step: write the update once, get a separate version for each destination (X, LinkedIn, DEV.to, GitHub), edit each version, and publish them as independent jobs.
It's for developers, students and open-source contributors who would rather build than post. The "lazy" part is deliberate. You get less repetitive writing, but you still approve every post before it goes anywhere.
The demo runs in your browser in a clearly labeled demo mode. You can write a post, choose destinations, get an editable version per destination with character-limit checks, confirm, and watch simulated publishing, including a failed destination you can retry without touching the ones that succeeded. Nothing is really published, and the page never claims otherwise. The connection indicators are all red because no real platform is connected.
The browser demo adapts text with simple rules. The open-weight model step lives in the backend (see below).
Write once, adapt, and publish to developer communities. Publishing runs on Temporal, so every destination is a durable, retryable, independent job.
slothgram/
frontend/index.html landing page + browser demo (open it in a browser, no build step)
backend/slothgram/ ai.py, workflows.py, activities.py, adapters.py, client.py, worker.py, cli.py
backend/tests/ 24 tests
docker-compose.yml local Temporal server
.env.example, LICENSE (MIT)
| Requirement | How it is done |
|---|---|
| One job per destination | One PublishDestinationWorkflow per destination. One failure never touches another. |
| User must approve first | Workflow waits for the approve signal (7 day timeout, then canceled). |
| Schedule after confirmation | After approval, a durable timer waits until scheduled_at .cancel interrupts it. |
| Retries with backoff | Activity RetryPolicy : 2s start, x2, max 2 min, 5 attempts. Rate limits usenext_retry_delay . |
| No duplicate posts | Idempotency key = hash(user, post, destination, content). Workflow ID is derived from it with REJECT_DUPLICATE . |
Open-weight AI (local inference). The backend sends the post to a model running on your own machine through an Ollama-compatible server. The default is qwen2.5:7b-instruct, and you can switch to another instruct model such as gemma3:4b by changing one setting. The model returns JSON-schema-constrained output: a variant per destination with title, text, hashtags, link handling, an explanation and warnings.
The model only proposes text. Deterministic code checks everything it returns:
The post is sent as delimited untrusted data, so instructions hidden inside it are not followed. The AI module has no publishing credentials and no way to publish. If the server is down or the model isn't installed, you get the exact fix (for example ollama pull qwen2.5:7b-instruct). Malformed output is retried once, then fails with a clear message.
Reliable publishing with Temporal. Each destination is its own durable workflow:
needs_review instead of being retried automatically.
There's also a DEV.to adapter that creates drafts through the official API.
Stack: Python, Temporal, httpx, Pydantic. 24 tests pass, with the workflow tests running against a local Temporal dev server.
Honest status
A tool that reads your unpublished work and writes in your voice shouldn't have to send that text to someone else's server. With an open-weight model on local inference, your drafts stay on your machine, you can swap models without rewriting the app, and there's no account or per-token bill. A closed API would have made the privacy story a promise instead of a design. Temporal being open source also means the publishing engine can be self-hosted and inspected, which matters for software that holds API keys and posts on your behalf.