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.
- CLI: Run a task from the command line and receive the agent's response.
- Python SDK: Send messages and manage sessions from Python.
- REST API: Create sessions, read their history, and manage their lifecycle over HTTP.
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.
Install either the full omnigent Python package or just omnigent-client
for the SDK. Both provide the omnigent_client import used below. Use a
package version matching your server version.
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_tokenin your API requests or Python SDK headers asAuthorization: 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_abc123Common options:
| Option | When 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-session | Run 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 / -c | Continue 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.
This example creates a native Claude Code session on an existing server. You'll need a connected runner configured with your repository, credentials, and tools.
import asyncio
from omnigent_client import OmnigentClient
async def main():
async with OmnigentClient(
base_url="http://127.0.0.1:6767",
# For a server requiring a bearer token:
# headers={"Authorization": "Bearer <access_token>"},
) as client:
agent = await client.sessions.resolve_agent("claude-native-ui")
runner_id = await client.sessions.resolve_online_runner(harness=agent.harness)
if runner_id is None:
raise RuntimeError("Connect a runner that supports native Claude Code first")
session = await client.sessions.create_from_agent_id(agent.id, title="Code review")
await client.sessions.bind_runner(session.id, runner_id=runner_id)
print(session.id)
print(f"http://127.0.0.1:6767/c/{session.id}")
asyncio.run(main())Use the printed session ID to send a message in the next step, or open the URL to view the session.
Create a native Claude Code session with curl and jq. Connect the machine
containing your repository and keep this command running while you use the
session:
omni host --server http://127.0.0.1:6767For shared servers, include your authentication credentials in each request,
such as -H "Authorization: Bearer $ACCESS_TOKEN".
| Use case | Example |
|---|---|
| Find an agent | Get the agent ID for native Claude Code: |
| Find a connected host | List host names and IDs: Get the ID of a specific host: |
| Start on a connected host | Use your agent ID, host ID, and repository path. |
| Start in a cloud sandbox | For a configured cloud sandbox host, use
|
| Check whether the session is ready | Check that |
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.
This example sends a message to an existing session. Replace conv_abc123
with its ID. The session must have an online runner with access to the
repository, model credentials, and tools. The SDK does not start a runner for
you.
import asyncio
from omnigent_client import OmnigentClient
async def main():
async with OmnigentClient(base_url="http://127.0.0.1:6767") as client:
await client.sessions.post_event("conv_abc123", {
"type": "message",
"data": {
"role": "user",
"content": [{"type": "input_text", "text": "tell me a joke"}],
},
})
asyncio.run(main())The call returns when the server accepts the message; it does not wait for the agent's reply. Open the session in the Web UI to follow its progress.
Send the first prompt or a follow-up to the same session:
curl --fail-with-body "http://127.0.0.1:6767/v1/sessions/$SESSION_ID/events" \
-H 'Content-Type: application/json' \
-d '{
"type": "message",
"data": {
"role": "user",
"content": [{"type": "input_text", "text": "Review the changes in the latest commit"}]
}
}'The request returns when the server accepts the message, without waiting for the reply. Print the URL to follow the review:
echo "http://127.0.0.1:6767/c/$SESSION_ID"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.
List recent sessions, then read a session's status and messages. Replace
conv_abc123 with the ID you want to inspect.
import asyncio
from omnigent_client import OmnigentClient
async def main():
async with OmnigentClient(base_url="http://127.0.0.1:6767") as client:
sessions = await client.sessions.list(limit=20, sort_by="updated_at")
for session in sessions:
print(session.id, session.title, session.status)
session_id = "conv_abc123"
session = await client.sessions.get(session_id)
print(session.status)
print(await client.sessions.list_items(session_id))
asyncio.run(main())For live events, iterate over client.sessions.stream(session_id). Use
session.status to check the session itself and
await client.sessions.subtree_busy(session_id) to check whether any of its
descendants are busy.
History is paginated. Use the last item's id as after in the next
list_items call to read further. Live events do not replay history; retrieve
the snapshot and history again after reconnecting.
List sessions on a local single-user server:
curl --fail-with-body "http://127.0.0.1:6767/v1/sessions?limit=20&sort_by=updated_at"Filter by agent_name, agent_id, or search_query. Listings exclude archived
sessions and child sessions by default; use include_archived=true or
kind=any when you need them. Both session and history listings are paginated:
when has_more is true, use the returned last_id as the next request's after
cursor.
curl --fail-with-body "http://127.0.0.1:6767/v1/sessions/<session_id>/items"The SSE stream supplies live updates; it does not replay conversation history.
Use the session snapshot and /items to recover state after reconnecting.
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.
These calls run inside the same async with OmnigentClient(...) as client
block used above. Replace session_id with the session you want to manage.
| Action | SDK call |
|---|---|
| Cancel active work | await client.sessions.interrupt(session_id) |
| Fork a conversation | fork = await client.sessions.fork(session_id) |
| Archive and retain history | await client.sessions.set_archived(session_id, archived=True) |
| Restore an archived session | await client.sessions.set_archived(session_id, archived=False) |
A fork's new ID is fork["id"]. Bind a runner before sending it a prompt:
await client.sessions.bind_runner(fork["id"], runner_id=runner_id)Forking copies the full history by default. Pass up_to_response_id to fork
from an earlier response. Use the REST tab to permanently delete a session
and its resources.
Use the SESSION_ID from the earlier examples.
| Use case | Example |
|---|---|
| Cancel active work | Stop the current task without deleting the conversation: |
| Fork a session | Copy the conversation and save the new session's ID in This copies the full history. Add |
| Archive a session | Keep its history while hiding it from default listings: |
| Restore a session | Make an archived session appear in default listings again: |
| Delete a session | Permanently delete the session and its associated resources. Requires owner-level access: |
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 case | Example |
|---|---|
| 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. |
| Make the session public | Grant |
| Inspect current grants | |
| 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 |
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.
| Method | Path | What you can do |
|---|---|---|
POST | /v1/sessions | Create a session |
GET | /v1/sessions | List 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}/fork | Copy conversation history into a new session |
GET | /v1/sessions/{id}/items | Read conversation history |
GET | /v1/sessions/{id}/child_sessions | List child sessions |
GET | /v1/sessions/{id}/stream | Receive live events via SSE |
POST | /v1/sessions/{id}/events | Send a message or interrupt active work |
PUT | /v1/sessions/{id}/permissions | Grant or update user/public access |
GET | /v1/sessions/{id}/permissions | List 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.
| Tool | What it does |
|---|---|
sys_agent_list | Find available agents and their IDs. |
sys_session_create | Create a child session from an existing agent ID or a local agent config, optionally with a first message. |
sys_session_send | Send a follow-up to a child session, or start a named sub-agent declared by the parent agent. |
sys_session_list | Find child sessions and other sessions you can access. |
sys_session_get_info | Check a session's status, agent, and workspace. |
sys_session_get_history | Read a session's recent messages and tool results. |
sys_session_close | Close 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:
| Skill | When to use it |
|---|---|
investigate | Delegate code exploration or debugging, then combine the findings. |
fanout | Split independent implementation tasks across workers, each in its own worktree and PR. |
cross-review | Have a different vendor's agent review an implementation and send blocking findings back for fixes. |
Start Polly in your repository:
omni pollyThen 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:
| Tool | What it does |
|---|---|
sys_scheduled_task_create | Save a prompt, agent, and recurring schedule. |
sys_scheduled_task_list | List your scheduled tasks. |
sys_scheduled_task_update | Change a task's prompt, schedule, or other settings. |
sys_scheduled_task_delete | Remove 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=0The 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.