Managing tasks 

Tasks are one-shot prompt templates that combine a configuration with a specific user prompt. They provide reusable AI operations that editors or extensions can execute with a single call.

Task list showing task name, linked configuration, description, and actions

The task list with each task's assigned configuration and action buttons.

Adding a task manually 

  1. Navigate to AI > Authoring > Tasks.
  2. Click Add Task.

  3. Fill in the required fields:

    Name
    Display name (e.g., Summarize Article).
    Configuration
    Select the LLM configuration to use.
    User Prompt
    The prompt template. Use {{input}} for the task's input. PHP callers of Task::buildPrompt() can supply other named variables; placeholders without a supplied value remain unchanged.
  4. Add a description so other admins understand what the task does.
  5. Click Save.

Executing a task 

Inactive tasks stay visible in the administrator catalogue. If none of its non-deleted tasks are active, the catalogue displays an activation warning.

Click Run on any task to open the execution form. It shows the configuration, model, parameters, input field, and prompt template.

Task execution form showing configuration details, input field, and prompt template

The task execution form for "Analyze System Log Errors" with the Ollama provider and Qwen 3 model.

Example tasks:

  • Summarize content — condense long articles.
  • Generate meta descriptions — SEO optimization.
  • Translate text — one-click translation.
  • Extract keywords — pull key terms from content.

The editor module 

Editors do not need backend administrator rights to run tasks: the dedicated AI > AI Tasks module (ADR-131) lists every active task and opens a slim run form — without any of the management affordances of this admin module. Access takes both switches described under Backend user permissions: the module permission on the backend group AND the Execute AI tasks grant. Every run is pre-flighted against the user's own usage budget. Tasks with the table input type are not offered to editors — their database record picker stays admin-only.

The editor-facing AI Tasks module listing runnable tasks grouped by category

The AI Tasks module as an editor sees it: runnable tasks grouped by category, plus the Approvals shortcut for users holding the approval grant.

The editor run form with input area and output panel, without management links

The editor run form: input, execute, output — the configuration is shown as a read-only summary line.

Usage, budget and cost estimate 

Both views of the module show the editor's own AI usage in a Your AI usage panel: requests, tokens and cost, today and this month. The windows and numbers are the ones the budget check compares — today from 00:00, this month from the first day of the month, both in server time — read from the same usage table. An editor sees only their own numbers.

When the editor has an active budget record with at least one limit, each limited value shows "used of limit" and a progress bar; an axis with a limit of 0 reads "no limit". Without such a record (none, switched off, or every limit 0) the panel says that no personal limit is set and still shows the usage. Costs are in USD, as in the Analytics module; the used cost is an estimate and carries a ~.

The run form adds Cost of one run:

  • A price range for one run with the configuration the run uses. The lower value assumes no answer, the upper value an answer of the full length the configuration allows (its maximum tokens). A range needs an input price and an output price on the model and a maximum answer length on the configuration; otherwise the form says that the cost cannot be estimated.
  • For an automatic task the estimate includes the data shown when the page was loaded. For a manual task it covers the task's instructions without the editor's input, and the form says so. Skills and instructions the run adds are not counted, so the real input is higher.
  • Whether the next run passes the budget. The form names the limit, without numbers, in two cases: the run will be refused because a limit is already reached, or the run can start but would exceed a limit at the upper cost estimate. A configuration's daily limit counts the usage of all users of that configuration.

After a run the panel and the verdict are read again, so the numbers include that run.