You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b86bc8a
Browse filesBrowse the repository at this point in the historyBrowse files
Add scheduled tasks - the deferred "automation" item, scoped honestly
Run a saved prompt against a chosen model on a repeating interval while
the app is open (Settings -> Automation). Each task gets a dedicated
chat session it appends results to, so you get a running log instead
of a new sidebar entry every run.
Deliberately scoped down from a full "scheduled agent": this only runs
while Modelforge is open (setInterval timers in the main process, no
OS-level task registration - closing the app stops it), and it's plain
chat completions, not Agent mode - tool-calling would need porting the
renderer's tool loop into the main process, a materially bigger change
than the rest of this feature.
Implementation:
- scheduled-tasks-store.ts: CRUD persistence, same pattern as the
other *-store.ts modules.
- scheduler.ts: owns the interval timers, reschedules on any
create/update/delete, and runs a task by calling back into main.ts's
existing provider-dispatch logic (extracted into a shared
dispatchChat/completePrompt pair also used by chat:send, rather than
duplicating the ollama/llamacpp/openai/anthropic branching a second
time).
- Settings -> Automation tab: create/enable/disable/run-now/delete,
reusing the same model picker as chat defaults.
Found and fixed a real race while verifying in a live browser session:
creating a task optimistically appended it to local state, but the
initial mount fetch (a separate window.api.scheduledTasks.list() call)
could resolve *after* that append and already include the same task,
producing a visible duplicate. Confirmed via React fiber inspection
that the state array itself held two entries, not just a rendering
artifact, then fixed by re-fetching the list after create instead of
appending optimistically, and confirmed the fix holds even with an
artificially delayed mount fetch designed to force the race.
Copy file name to clipboardExpand all lines: README.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,6 +54,9 @@ Beyond chat, Modelforge includes an **agentic mode** — the model can read/writ
54
54
55
55
**Agent mode** — see the [dedicated section](#agent-mode) below.
56
56
57
+
**Automation**
58
+
-**Scheduled tasks** (Settings → Automation) — run a saved prompt against a chosen model on a repeating interval while the app is open, with results appended to a dedicated chat for that task so you get a running log rather than a new chat every time. This only runs while Modelforge is open (there's no OS-level background service), and doesn't use Agent mode tools — it's plain scheduled chat completions, not a scheduled agent run.
59
+
57
60
**Models & hardware**
58
61
- Model recommendations based on your actual hardware — RAM and VRAM are detected and summed **across all GPUs**, not just the first one, so multi-GPU machines get accurate suggestions.
59
62
-**GPU offload control** — set how many model layers Ollama offloads to GPU (`num_gpu`) per chat, per project, or as a global default; leave it blank to let Ollama decide automatically.
0 commit comments