Control & Config

Every API request carries a script in q. It can carry more than that. These parameters decide how long the script may run, how far a loop may go, how patient a network call should be, and how much it is allowed to hold — sensible without them, and yours to change when the defaults do not suit the job.

How a limit is decided

You ask for a value; your tier decides the ceiling; the lower of the two applies. Asking for more than your tier allows is not an error — you get your tier’s ceiling and the response tells you what you actually got. A script written against a generous limit still runs on a small plan; it just runs within that plan.

Asking for More Time

curl -X POST https://ql.ocalt.com/api \
  -d "identity=you@example.com" \
  -d "password=your_api_key" \
  -d "execution_time=900" \
  --data-urlencode 'q=SELECT ROWS FROM DB "warehouse" TABLE "movements" SET ?all
AFTER COUNT ?all SET ?n
AFTER EMIT ?n'

Time and Repetition

Parameter	Default	What it governs
`execution_time`	300	Seconds the whole script may run. Always seconds — never minutes, never a suffix
`loopmax`	1000000000	Iterations any one `WHILE` or `FOREACH` may take before it is stopped
`depth_max`	64	How deeply blocks and operations may nest inside each other
`on_timeout`	`error`	`error` fails the request; `partial` returns whatever was emitted before the cut

loopmax is not there to slow you down — a billion iterations is far more than any real job needs. It is there so that a loop whose exit condition is never met stops on its own instead of consuming your execution time and telling you nothing. When it trips, the error names the line, which is usually enough to see the mistake.

Network

Parameter	Default	What it governs
`fetch_timeout`	30	Seconds any single `FETCH` or outbound request may wait
`fetch_max`	100	Outbound requests one script may make in total
`fetch_redirects`	5	Redirects followed before a fetch gives up

A slow third party should not cost you your whole execution time. fetch_timeout is per request, so a script making twenty calls with a thirty-second timeout can still spend ten minutes waiting — which is why execution_time governs the total and always wins.

Memory and Size

Memory is not a separate allowance to reason about. Your namespace may use as much memory as it has mounted storage — if you have 50 GB of storage, a script may hold 50 GB. The free tier is the one exception, fixed at 1 GB.

That single rule decides everything downstream, because the things people usually ask about separately are all the same question:

Limit	Equal to
`memory_max`	Your mounted storage. 1 GB on Free
Maximum POST size	The same figure — a request you cannot hold is a request you cannot process
Maximum file upload	The same figure, and it must also fit in your remaining storage
`output_max`	32 MB, or your memory limit if that is smaller

Why memory follows storage. A namespace that can store fifty gigabytes will one day want to read a large part of it at once — a video to transcode, a dataset to sort, an image to composite. Tying the two together means the question “can I process what I can keep?” always answers yes, and there is one number to understand instead of two.

An upload is checked twice: against your memory limit when it arrives, and against your remaining storage before it is written. A 4 GB upload on a plan with 4 GB of memory and 200 MB of space left is refused for the second reason, not the first.

Behaviour

Parameter	Default	What it does
`dry_run`	off	Parse and validate the script. Nothing executes, nothing is written, no quota is spent
`explain`	off	Return how the script was understood — every verb, its arguments and how they chained
`trace`	off	Return a line-by-line record of what ran and how long each statement took

Checking a Script Without Running It

curl -X POST https://ql.ocalt.com/api \
  -d "identity=you@example.com" -d "password=your_api_key" \
  -d "dry_run=1" \
  --data-urlencode 'q=DELETE ROWS FROM DB "shopdb" TABLE "orders" WHERE "id" IS LESS THAN 100'

(* Returns whether it parses and what it would do. The rows are untouched. *)

dry_run is what an editor, a deployment check or a code review runs. It answers “is this valid, and what does it touch?” without the answer costing anything or changing anything.

Seeing What You Got

Ask for the limits in force and the response tells you, already clamped to your tier. Useful when a script behaves differently on two plans and you want to know why.

The Limits This Request Ran Under

curl -X POST https://ql.ocalt.com/api \
  -d "identity=you@example.com" -d "password=your_api_key" \
  -d "config=1" -d "q=EMIT 1"

(* {"execution_time":300,"loopmax":1000000000,"memory_max":"1GB",
    "fetch_timeout":30,"fetch_max":100,"tier":"free"} *)

Full Parameter Reference

Parameter	Default	Unit
`q`	—	The script. Required
`identity`	—	Your username or email. Required
`password`	—	Your API key. Required
`execution_time`	300	seconds
`loopmax`	1000000000	iterations
`depth_max`	64	levels
`fetch_timeout`	30	seconds
`fetch_max`	100	requests
`fetch_redirects`	5	hops
`memory_max`	your storage	bytes, or 1GB on Free
`output_max`	33554432	bytes
`on_timeout`	`error`	`error` or `partial`
`dry_run`	0	0 or 1
`explain`	0	0 or 1
`trace`	0	0 or 1
`config`	0	0 or 1 — report the limits in force

These are request parameters, not verbs. A script cannot raise its own ceiling from inside itself — that would make a limit something a runaway script could remove. See Quotas & Pricing for what each tier allows.