Ocalt for AI

(* the model reads the code, changes it, builds it, and ships it *)
FILE READ "/root/app/server.js" SET ?src
AFTER STRING REPLACE ?src ALL "listen(3000" WITH "listen(8080" SET ?fixed
AFTER FILE WRITE ?fixed TO "/root/app/server.js"
AFTER DIRECTIVE "build-01" EXEC "cd /srv/app && npm test" SET ?test
AFTER IF ?test("exit_code") IS EQUAL TO 0
OPEN
  DIRECTIVE "build-01" EXEC "cd /srv/app && npm run deploy" SET ?out
  AFTER SUBDOMAIN ADD "app" AT "/root/app" SET ?site
  AFTER NOTIFICATION "shipped: " & ?site("url")
CLOSE
OR
OPEN
  NOTIFICATION "tests failed, not shipping: " & ?test("stderr")
CLOSE

Turn any model into an engineer with hands

1. Get an API key. accounts.ocalt.com → API. The key is a password substitute for API traffic and is rotatable without changing your password.
2. Give the model the grammar. Every verb, slot and worked example is at ql.ocalt.com. It is one document, and it is the whole language - there is no second SDK to learn.
3. Let it run one script. POST to https://ql.ocalt.com/api with identity, password and q. The response is the output, byte for byte.
4. Point it at real work. The same key that runs one line runs a project: read a repository, write files, run the build, read the errors, fix them, deploy the result - on your machine or your server, not in a sandbox that forgets.
5. Let it keep working while you sleep. STARTING and EVERY put a script on a schedule, so the model’s work carries on without a prompt to start it.
6. Bound it before you widen it. The model can only touch the namespace whose key it holds, and only the machines that account has registered. Give it its own account first.

curl https://ql.ocalt.com/api \
  -d identity=you@example.com \
  -d password=YOUR_API_KEY \
  --data-urlencode 'q=EMIT "the model is connected"'

Wiring it to the coding agent you already use

There is no Ocalt plugin to install, because there is nothing to install. Any assistant that can make an HTTP request can drive OcaltQL, and any assistant that can run a shell command already can. The whole contract is one endpoint and three fields.

POST https://ql.ocalt.com/api
  identity   your account email
  password   your API key from accounts.ocalt.com
  q          the OcaltQL script

the response body is the script's output, byte for byte

Claude Code

Give it the key as an environment variable and pre-approve the one command, so it never stops to ask mid-task. Settings live in .claude/settings.json for the whole project, or .claude/settings.local.json for just you — put the key in the local one, which is the file that is not committed. These are strict JSON: a // comment or a trailing comma makes the file invalid.

// .claude/settings.local.json
{
  "env": {
    "OCALT_IDENTITY": "you@example.com",
    "OCALT_KEY": "your-api-key"
  },
  "permissions": {
    "allow": ["Bash(curl https://ql.ocalt.com/api *)"]
  }
}

Then a line in CLAUDE.md at the root of the project tells it what it now has. It reads that file at the start of every session, so this is the whole integration:

# OcaltQL

This project can run OcaltQL. One script, one request, one result:

    curl -s https://ql.ocalt.com/api \
      -d identity="$OCALT_IDENTITY" \
      -d password="$OCALT_KEY" \
      --data-urlencode 'q=EMIT "connected"'

The grammar is at https://ql.ocalt.com - one document, the whole language.
Use it to read and write files in the namespace, run commands on registered
machines, query databases, send mail and put results online. Statements are
chained with AFTER, AND and OR; blocks are OPEN and CLOSE.

ChatGPT, or any model with function calling

Declare one tool. Not one per capability — one, for the entire platform, because the capability lives in the script rather than in the tool surface.

{
  "name": "ocaltql",
  "description": "Run an OcaltQL script. Returns the script's output. OcaltQL reaches files, machines, databases, mail, media and the web through one grammar; see ql.ocalt.com.",
  "parameters": {
    "type": "object",
    "properties": {
      "q": { "type": "string", "description": "The OcaltQL script to run." }
    },
    "required": ["q"]
  }
}

Your handler adds identity and password and posts the script. The model never sees the key, and the set of things it can do grows without the tool definition ever changing.

Anything else

An editor assistant, a CI job, a cron script, a model running on your own hardware: the same three fields. Export the key once and every one of them is wired.

export OCALT_IDENTITY="you@example.com"
export OCALT_KEY="your-api-key"

ocaltql() {
  curl -s https://ql.ocalt.com/api \
    -d identity="$OCALT_IDENTITY" \
    -d password="$OCALT_KEY" \
    --data-urlencode "q=$1"
}

ocaltql 'FILE LIST "/root" SET ?f AFTER EMIT ?f'

Give it its own account first

A key is bounded by the account that owns it: its namespace, its machines, its quota, and nothing else. Make the agent a member of your business with its own key rather than handing over yours, and you can read exactly what it did, and revoke it on its own, without rotating anything of yours.