What I built
Slothlist turns a messy task dump into one gentle first step, a few small moves, and permission to let the rest wait. It asks how much energy you have and how much time you can spend, then formats a compact plan around those limits.
The idea is deliberately small: when a to-do list feels heavy, reduce the effort needed to decide what to do next.
How it works
The browser sends the task text, energy level, time budget, and optional memory preference to a Python server running on your own machine. The server calls Backboard's Threads Messages API and asks for a structured JSON plan. The default route is OpenRouter with Qwen2.5 7B Instruct.
The Backboard API key stays in a local, Git-ignored .env file and is read by the server. It is never placed in the browser JavaScript.
A simplified version of the server-side request looks like this:
payload = {
"content": content,
"system_prompt": SYSTEM_PROMPT,
"llm_provider": MODEL_PROVIDER,
"model_name": MODEL_NAME,
"json_output": True,
"memory": "Auto" if remember_preferences else "off",
"stream": False,
}
request = urllib.request.Request(
BACKBOARD_URL,
data=json.dumps(payload).encode(),
headers={
"X-API-Key": BACKBOARD_API_KEY,
"Content-Type": "application/json",
},
method="POST",
)
The optional preference-memory checkbox is off by default. Each plan uses a hosted Backboard thread, and task text is sent to Backboard when a plan is requested. That means the current version needs an internet connection and does not keep task content entirely on the laptop.
Why open-weight AI matters here
The default model is an open-weight Qwen model. That gives this little planner room to change: I can try another compatible model route, compare outputs, and tune the prompt without tying the product idea to one closed model family.
Open weights do not make this particular setup private or offline by themselves. Backboard handles the API call and hosted threads, so the data flow is cloud-based. The current benefit is model choice and the ability to change the model behind the planner; a local inference mode would be a separate future step.
What I learned
Keeping the API key on the server is a small but important boundary. The browser only sees the plan response, while the server owns the credential and makes the authenticated request.
I also learned to distinguish a configured key from a working integration. The interface and API bridge are in place, but my local demo still needs a successful end-to-end Backboard response before I can claim the planning flow is verified. I’m sharing that limitation clearly instead of presenting a screenshot of the interface as proof that inference succeeded.
Try it
Slothlist 🦥
Let the pile wait a little. Slothlist turns a messy task dump into one gentle first step, a few small moves, and permission to let the rest wait.
Slothlist sends plans to the Backboard API. The API key is read only by the local Python server and is never sent to the browser. Backboard creates a hosted thread for each plan. Optional Backboard memory is off by default; turn it on in the UI to let Backboard save and retrieve planning preferences across plans.
The default model route is OpenRouter's Qwen2.5 7B Instruct, an open-weight model. This project uses both Backboard's API and open-weight AI. It is not an offline or local-inference app: task text is transmitted to Backboard and routed to the configured model provider.
Run it with Backboard
- Create an API key in the Backboard dashboard's Settings → API Keys section at app.backboard.io. See…
The project is a small Python and vanilla JavaScript app. To run it, add a Backboard key to
.env, start server.py, and open the local address printed by the server. The README has the setup steps. Never commit .env or paste the key into frontend code.
This is my entry for the Slow and Steady theme: a tool that tries to make starting one task feel a little less demanding.
What would you want a low-energy task planner to do for you: make the first step smaller, help decide what can wait, or help you stop for the day?
Top comments (0)