Programmatic Usage

Integrate Omnigent into your scripts, applications, and CI pipelines. Start agent sessions, send them work, and return to the same conversations for follow-up tasks. You can also open saved sessions in the Web UI to review their progress and results.

Before you start

Install Omnigent and configure the model credentials your agent needs. The examples use a local single-user server at http://127.0.0.1:6767. For a shared server, replace that URL and configure authentication before sending requests.

See Shared Server for deployment setup. Local single-user servers do not require per-request credentials.

Authentication for a shared server

Shared servers support both user authentication and optional machine tokens. The credentials you use depend on the server's authentication setup:

  • Accounts or SSO: Use your signed-in user's session cookie or CLI login bearer token for API requests. These support scheduled tasks as well as sessions, subject to your user's permissions.

    omni login "<server-url>"

    This prompts for your username and password for built-in accounts, or opens a browser for SSO. It saves credentials for subsequent CLI commands; it does not print a token for use in curl.

    For built-in accounts, you can also request a token directly:

    ACCESS_TOKEN=$(curl --fail-with-body "<server-url>/auth/login" \
      -H 'Content-Type: application/json' \
      -d '{"username": "<username>", "password": "<password>"}' \
      | jq -er '.token')

    Use it in API requests with -H "Authorization: Bearer $ACCESS_TOKEN". This username/password endpoint does not apply to SSO.

  • Authentication proxy: Connect through the proxy, which supplies your identity to Omnigent. Follow your proxy provider's authentication method; Omnigent does not issue a token for this mode.

  • Machine tokens: For unattended scripts, an administrator can enable machine access and provide a client ID and secret. These tokens support agent, host, runner, and session APIs, but cannot access scheduled tasks.

    curl --fail-with-body "<server-url>/oauth/token" \
      --data-urlencode grant_type=client_credentials \
      --data-urlencode "client_id=<client-id>" \
      --data-urlencode "client_secret=<client-secret>"

    Include the returned access_token in your API requests or Python SDK headers as Authorization: Bearer <access_token>. Tokens expire after one hour by default; run the same command to get a new one.

Start a session

From your repository, run an agent with -p to send a prompt, print its response, and exit. Use your agent directory or YAML file in place of ./my-agent/:

omni run ./my-agent/ -p "Review the changes in the latest commit"

Omnigent starts a local server and runner automatically. Sessions are saved by default; their URL appears on stderr when they start. Open it to follow progress in the Web UI:

Omnigent session: http://127.0.0.1:6767/c/conv_abc123

Common options:

OptionWhen to use it
-p "<prompt>" / --prompt "<prompt>"Run a task without an interactive chat; the response goes to stdout.
--server "<server-url>"Save the session on a shared server. The agent definition is uploaded, and tools still run on the machine invoking the CLI.
--no-sessionRun a disposable local task with no history to view or resume afterward.
--model "<model>"Override the agent's model. See Models & Credentials.
--harness "<harness>"Override the agent's harness. See Harnesses for supported configurations.
--continue / -cContinue the most recent conversation for the same agent.
--resume "<conversation_id>"Continue a specific conversation using the ID from its session URL.

These examples use an agent YAML or directory through omni run; native terminal harnesses have their own CLI behavior. To run tools on another machine or in a cloud sandbox, use the REST API's host options.

Send a message or continue a conversation

Use the session ID from the previous step to send a message to that session. Saved sessions can also be opened in the Web UI.

Use --continue (or -c) to send a follow-up prompt to the most recent conversation for the same agent:

omni run ./my-agent/ --continue -p "Now check whether the tests cover those changes"

To continue a specific conversation, use its ID:

omni run ./my-agent/ --resume "<conversation_id>" -p "Explain the first finding"

Use --resume when your automation runs multiple conversations and needs to target a specific one. Use the ID from the CLI's session URL, or look it up with GET /v1/sessions.

Find sessions and follow their progress

The CLI prints the session URL to stderr at startup and the collected assistant text to stdout when the run finishes. Open that URL to see the conversation and its progress.

Use the Python or REST tab to list saved sessions, retrieve history, or monitor an agent from your application.

Fork, archive, or stop work

To fork into an interactive session:

omni run ./my-agent/ --fork "<conversation_id>"

--fork cannot be combined with -p. For scripted forks, archiving, or cancellation, use the Python or REST tab.

Share a session

Use the permissions API to share a session on a reachable shared server. Your credentials need manage or owner access to the session, and the server's sharing settings must allow the requested access.

The examples use bearer-token authentication:

SERVER_URL="<server-url>"
SESSION_ID="<session-id>"
ACCESS_TOKEN="<access-token>"

For a specific user, level is 1 for read access, 2 to also send messages and interact with the session, or 3 to also manage sharing. Public access is always read-only (level: 1).

Use caseExample
Share with a specific user

Use the recipient's user ID on this server, such as their account username or SSO email. Repeating this request updates their existing access level.

curl --fail-with-body -X PUT "$SERVER_URL/v1/sessions/$SESSION_ID/permissions" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"user_id": "<user-id>", "level": 1}'
Make the session public

Grant __public__ read access so anyone who can sign in to the server can view the session through its URL, without an individual grant. The server must have public sharing enabled; this does not bypass sign-in.

curl --fail-with-body -X PUT "$SERVER_URL/v1/sessions/$SESSION_ID/permissions" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"user_id": "__public__", "level": 1}'
Inspect current grants
curl --fail-with-body "$SERVER_URL/v1/sessions/$SESSION_ID/permissions" \
  -H "Authorization: Bearer $ACCESS_TOKEN" | jq
Remove public access

Revoke the public grant; specific users' grants remain. To revoke a specific user instead, use their URL-encoded user ID in place of __public__.

curl --fail-with-body -X DELETE \
  "$SERVER_URL/v1/sessions/$SESSION_ID/permissions/__public__" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Send the recipient the session URL. A specific user must sign in with the identity you granted access to:

echo "$SERVER_URL/c/$SESSION_ID"

You can also let an agent share sessions through sys_session_share. Set agent_session_sharing: non-public in its agent configuration to allow sharing with users, or agent_session_sharing: public to also allow public grants. The tool accepts user_id, level ("read", "edit", or "manage"), and an optional session_id that defaults to the calling session. The caller's permissions and server sharing settings still apply.

API endpoints reference

The server exposes these session endpoints. Replace {id} with a session ID.

MethodPathWhat you can do
POST/v1/sessionsCreate a session
GET/v1/sessionsList and filter sessions
GET/v1/sessions/{id}Read session details and status
PATCH/v1/sessions/{id}Rename, configure, archive, or unarchive
DELETE/v1/sessions/{id}Delete a session and its associated resources
POST/v1/sessions/{id}/forkCopy conversation history into a new session
GET/v1/sessions/{id}/itemsRead conversation history
GET/v1/sessions/{id}/child_sessionsList child sessions
GET/v1/sessions/{id}/streamReceive live events via SSE
POST/v1/sessions/{id}/eventsSend a message or interrupt active work
PUT/v1/sessions/{id}/permissionsGrant or update user/public access
GET/v1/sessions/{id}/permissionsList permission grants
DELETE/v1/sessions/{id}/permissions/{user_id}Revoke a permission grant

See the API Reference for more details on these and other endpoints.

Automation features

Let an agent manage other sessions

You can ask an agent to delegate work to another Omnigent agent. It uses built-in session tools to create a child conversation, send instructions, and read the results. These are tools the agent calls during a session; you don't need to write an API client to use them.

ToolWhat it does
sys_agent_listFind available agents and their IDs.
sys_session_createCreate a child session from an existing agent ID or a local agent config, optionally with a first message.
sys_session_sendSend a follow-up to a child session, or start a named sub-agent declared by the parent agent.
sys_session_listFind child sessions and other sessions you can access.
sys_session_get_infoCheck a session's status, agent, and workspace.
sys_session_get_historyRead a session's recent messages and tool results.
sys_session_closeClose a finished child session while retaining its history.

For example, send this prompt in an Omnigent session:

Find the native Claude Code agent and create a child session titled
"Review tests". Ask it to review the test coverage in this repository without
editing files. Read its findings and summarize the missing coverage for me.

The agent can use sys_agent_list to find the agent, then call sys_session_create with arguments like these:

{
  "agent_id": "<agent_id from sys_agent_list>",
  "title": "Review tests",
  "message": "Review the test coverage in this repository. Report missing coverage without editing files."
}

The returned conversation_id identifies the child. To continue its work, ask:

Ask the "Review tests" child session to prioritize its findings by risk.

sys_session_send can write only to the calling session's direct children. For agents with named sub-agents, reusing the same agent and title continues that child conversation; a different title starts a separate one. Child sessions appear in the Web UI, where you can follow their progress.

Use bundled skills for multi-agent workflows

Skills are reusable instructions that guide how an agent uses its tools. The skills available depend on the agent you run. For example, Polly bundles these coding workflows:

SkillWhen to use it
investigateDelegate code exploration or debugging, then combine the findings.
fanoutSplit independent implementation tasks across workers, each in its own worktree and PR.
cross-reviewHave a different vendor's agent review an implementation and send blocking findings back for fixes.

Start Polly in your repository:

omni polly

Then name the skill in your prompt:

Use the investigate skill to trace how this repository authenticates API
requests. Have separate agents examine the server routes and client code,
then summarize the flow with file references. Do not edit files.

For a change that is ready for review:

Use cross-review to review PR #123 against its stated requirements.

Polly needs the worker harnesses and their credentials configured. The skills coordinate the work; the workers still need access to the repository and models. See Prompts & Skills to add your own workflows in an agent's skills/ directory or the project's .agents/skills/ directory.

Schedule recurring agent runs

Ask an agent to create a scheduled task when you want the same work repeated. Omnigent provides four built-in tools:

ToolWhat it does
sys_scheduled_task_createSave a prompt, agent, and recurring schedule.
sys_scheduled_task_listList your scheduled tasks.
sys_scheduled_task_updateChange a task's prompt, schedule, or other settings.
sys_scheduled_task_deleteRemove a task so it no longer runs.

For example, replace the host name and repository path in this prompt:

Create a scheduled task named "Weekday code review". Every weekday at 9am
Asia/Singapore, run native Claude Code on host "my-host" in
/home/ci/my-repository. Ask it to review the latest commit and report findings
without editing files. Look up the agent and host IDs first.

The schedule uses this recurrence rule with timezone: "Asia/Singapore":

FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=9;BYMINUTE=0

The chosen host must be online when the task fires, and the agent needs credentials and tool permissions suitable for unattended work.

You can later ask, "Move Weekday code review to 10am," or "Delete Weekday code review." The agent uses the list and update or delete tools to make the change.

See Scheduled Tasks for the full configuration. Scripts can also manage tasks through /v1/scheduled-tasks; machine client-credentials tokens do not grant access to that endpoint.