Platform

Schedules, models and limits

A schedule decides when work runs. The model decides what does the thinking. Usage tells you what it cost. This page covers all three, and the limits you should plan around.

Schedules

A schedule runs a prompt in a fresh session, either once or on a repeat. It is the simplest way to make an agent do something later without keeping a chat open.

Open ai.wrenchit.net and choose Schedules, then New schedule. A schedule has four parts:

Part	What to set
Prompt	The instruction to run. Write it as if nobody will be there to clarify it, because nobody will.
Project	The project the session starts in. The agent sees that project's files and instructions.
When	Once at a chosen time, or every N minutes, hours or days.
Name	A label for the list. Use the outcome, not the mechanism.

Repeat intervals

Repeats are fixed intervals: every N minutes, hours or days. There are no calendar rules such as “weekdays only”; pick the closest interval and have the prompt check the date if the work should only happen on some days.

What a run does

The engine opens a new session for the prompt in the chosen project.
The agent runs the prompt to completion and reports the result.
The schedule records the run as Scheduled, Running, Done, Failed or Cancelled.
The next run is set from the interval. A failed run does not stop later runs.

Cancel a schedule from its row in the list. Cancelling stops future runs; it does not delete sessions that already ran. Open a past run with Open session to see the transcript.

Schedules are for prompts, coils are for goals. A schedule runs one prompt and stops. A coil keeps a board, plans across runs and can ask you for approval. If the work needs to remember yesterday, use a coil with a schedule rather than a bare schedule.

Coil timing

A coil wakes on the trigger you set in its wizard. The coil list shows the next run and the last run, and marks a coil that has never run.

Wakes by hand. You wake it from the coil card, or its webhook is called. Use this while you are setting the brief.
Every hour, every N hours, daily at a time, or chosen days at a time. A recurring wake for steady work such as a report or a check.
Glancing. A wake that looks for due work, finished background jobs and anything that needs your approval, rather than doing a full task. How often it glances is set per coil; a glance with nothing to do ends quietly.

Each day the coil plans its day at 4 AM as a set of blocks, within quiet hours and a block budget. Reschedule today changes that day's plan without changing the standing brief. Use it when today is different, not when the job has changed.

Coil states

State	Meaning
Asleep	Idle, waiting for the next trigger.
Waking	Starting a run and loading its notes.
Working	Actively on a task.
Glancing	Checking for due work rather than doing a full task.
Needs you	Waiting on you. Open the ask and approve or deny it.
Learned	A run finished and wrote something worth keeping to memory.
Stuck	The last run failed. Open the run to see why.
Off	Disabled. It will not wake on its own.

Models

The model is chosen per session from the model picker. The list is not global: a workspace admin decides which models are enabled, so two accounts can see different choices. If a model you expect is missing, it is a workspace setting, not a client bug.

Model choice affects three things you will notice:

Quality on long tasks. Stronger models hold a multi-step plan together for longer before losing the thread.
Speed. Smaller models answer faster and are usually enough for short edits and lookups.
Cost. Each model has its own rate. The usage panel converts the run into an estimate using those rates.

Switching models mid-project is allowed. The new model sees the conversation and the project files, not the previous model's private reasoning, so restate any constraint that only existed in your head.

Usage and limits

Wrenchit meters usage in credits. A workspace admin sets the dollar value of a credit and the per-model rates; the product converts tokens into credits and shows the result. The coil usage panel reports tokens, the plan and an estimated cost, and labels the cost as an estimate because rates and rounding can change.

These docs do not publish a rate card. Rates are set per workspace and can change without a client release, so the number that applies to you is the one in Console or on your agreement. Check there before you budget a long-running coil.

What counts

Input and output tokens for each model call, including tool results fed back into the conversation.
Background runs. A schedule or heartbeat consumes the same way a chat does; a coil that wakes every hour can cost more than a busy chat.
Retries. A retried run is another run. Fix the cause instead of looping.

Limits you can plan around

Context is finite. Very long sessions get compacted. Older turns may be summarised, so keep decisions in a file or in memory rather than only in chat.
One task at a time per worker. A coil does not parallelise a single task; it orders tasks. Expect multi-step work to take wall-clock time.
Approvals pause work. A live-system change waits for you. That is deliberate; plan for a human in the loop on anything irreversible.
Workspace quotas. Workspace admins set allowances and can cap spend and model access. Ask your admin which limit applies to you; the current allowance is shown in Console.

Choosing a model

If the work is…	Start with…
A rename, a copy edit, a single-file fix	A fast model. Escalate only if it gets the change wrong twice.
A multi-file feature with tests	A stronger model, and give it the test command up front.
Research across many sources	A model with a large context window, plus a written note of what matters.
An always-on coil	The cheapest model that reliably passes the Judge. Measure a week before scaling the schedule.

“Reliably passes the Judge” is the real bar. A cheaper model that needs three retries usually costs more than the stronger one that finishes in one.