Coasty/

Developer API

Name: Coasty AI Employee
Brand: Coasty
Price: 19 USD
Availability: InStock
Rating: 4.8 (1250 reviews)

OpenAPI llms.txt

Primitives

Low-level stateless screenshot to actions

Predict

Predict, at a glance

Low-level stateless screenshot to actions

POST /v1/predict

Request map4 boundaries

01
Capture
PNG or JPEG screen
02
Predict
next useful action
03
Enforce
server action policy
04
Apply
client executes batch

Predict converts the current screenshot and one micro-goal into a policy-checked action batch while your client owns execution.

POST /v1/predict is the low-level, stateless prediction primitive. Each call is independent: you provide the full context, execute the returned actions, capture the next screenshot, and decide when to call again. Use it when your application must own that loop. For an autonomous goal, start a Submit & forget task. When a manually driven loop needs server-side trajectory memory, reach for sessions instead.

Field	Type	Required	Description
`screenshot`	string	Yes	One static PNG/JPEG as raw base64 or an exact image/png or image/jpeg data URI (100-10,485,760 base64 characters). All images plus JSON share the 15 MiB request-body cap.
`instruction`	string	Yes	Natural-language goal, e.g. "Click the login button".
`model`	"default" \| null	No	Managed alias. Select a specific BYOK model with llm.model.
`screen_width`	int	No	Width in pixels (320-3840). Supply with screen_height, or omit both; then it is measured from the screenshot.
`screen_height`	int	No	Height in pixels (240-2160). Supply with screen_width, or omit both; then it is measured from the screenshot.
`trajectory`	object[]	No	Up to 19 prior screenshot/action steps. Per-step screen dimensions are paired and otherwise decoded from that frame. Compress/downscale prior frames so the whole JSON body stays within 15 MiB.
`max_actions`	int	No	Cap on actions returned per call (default 5).
`tools`	string[]	No	Restrict to a subset of action types, e.g. ["click", "type_text"].
`action_policy`	object	No	Fail-closed post-model enforcement for allowed/blocked actions, blocked keys, window-closing shortcuts, action count, and coordinate bounds. The whole proposed batch is checked before any action is returned.
`include_reasoning`	bool	No	Return the model's reasoning string (default true).
`include_raw_code`	bool	No	When true, returns canonical pyautogui derived from validated actions, never the model's original text. When false, clears top-level raw_code to [] and every action raw_code to an empty string before storage/response.

The response is the standard prediction shape, covered in Response format.

Act → Observe → Verify

Use verification where state can branch or matter: after Save, navigation, modal transitions, irreversible operations, and before task completion. Execute the allowed action, wait for the UI to settle, capture a fresh screenshot, and compare that screenshot with one observable expected state. You do not need an expensive, verbose verification turn after every harmless deterministic keystroke such as a Tab inside a stable form.

Boundary	Recommended check
Save / submit	Confirm the success state, persisted value, or closed editor is visible before advancing.
Navigation / modal	Confirm the expected page, dialog, or focused control is visible before sending the next micro-goal.
Irreversible operation	Use an application-specific assertion or human approval in addition to screenshot verification.
Task completion	Treat status=done as a model claim; accept business completion only after a fresh observation matches the completion condition.
Harmless deterministic key	Usually continue without a separate verify call unless focus or layout is uncertain.

Concise verification prompt

Verify only whether the Group Note was saved.
Expected screen: the Group Note window is closed and the saved note is visible in the patient's Chart.
[done] when: both conditions are visible.
Otherwise return fail and describe the mismatch. Do not click or type.

Keep verification prompts this narrow. Long verification prompts increase latency and model distraction by making the model reconsider the whole workflow. A verification turn is observational: if it proposes a click or key anyway, reject that action client-side and verify from the current screen again.