simianx · diff

v1.0.6 to v1.0.6

1 added, 1 removed. Audit A to A.

---
name: simianx
description: "Give an agent SimianX AI, a research desk on US stocks and crypto that keeps talking. Convene the 8-agent research committee (four analysts, a bull and a bear researcher, a research manager, a risk manager) on any stock or coin and relay every step as it lands, up to the verdict with entry, stop and target and the PDF. Run a live analysis session: four agents (chart, news flow, fundamentals, decision) on one symbol at every candle close for as long as you stay connected, each result reported the moment it arrives, with the next analysis time and the offer to connect the user's exchange or broker. Take a quick read (one pass of the four agents), watch scored news on symbols (list, live stream, server-side watches), read Market Pulse price events and Sector Watch catalysts, run autopilots that keep going when you are offline. One feed, GET /v1/updates, carries everything the user has not heard yet. Signs the user in from the agent. Use when the user asks whether to buy or sell a stock or coin, for a trading analysis or a second opinion, news on a symbol, upcoming catalysts, or wants a symbol watched."
license: MIT
compatibility: "Needs network access to the SimianX API. Optional: python3 for scripts/follow_run.py and the runner."
metadata:
author: simianx
version: "1.0.6"
api_base: https://service.simianx.ai
docs: https://www.simianx.ai/agents
openapi: https://service.simianx.ai/v1/openapi.json
---
# SimianX for agents
Base URL: `https://service.simianx.ai` (every path below starts with `/v1`). Auth: `Authorization: Bearer $SIMIANX_API_KEY`,
plus `X-SimianX-Skill: 1.0.6` (this file's version) on every request.
Responses use `{"code": <http status>, "notify": "<text for you>", "data": {...}}`. `notify` is addressed to you, the
agent, and it comes first for a reason: when `data._pending` or `data._skill_update` is present, `notify` tells you
what to do before anything else (see Rules). Every response carries `X-Request-Id`, `X-SimianX-Skill-Version`,
`X-SimianX-Api-Version` and the `X-RateLimit-*` headers; paid responses carry `X-Points-Charged` and `X-Points-Remaining`
(for code, not for conversation).
## Coverage
- **Live analysis session** (lead with this when the user wants a symbol watched or analysed "live"): a session on one
symbol and timeframe where the four live agents run at every candle close: indicator (the chart), intelligence (the
news flow), fundamental (filings and insider trades, or on-chain and derivatives for a coin) and decision (a trade
with entry, stop and target). It runs while you stay connected over a WebSocket; each agent's result and each
decision reach you (and the user) the moment they land, with the time of the next analysis.
`POST /v1/live/sessions`, `references/live.md`.
- **Quick read**: one pass of the same four agents, no schedule. "What do the agents think of SOL on the 1H right
now?" `POST /v1/analysis/quick`, `references/quick.md`.
- **Research committee (deep research)**, lead with this when the user wants a full view (buy or not, the case, the
risks): 8 agents per run. Four analysts (stocks: fundamentals, market, news, timing; crypto: fundamentals, market,
news, derivatives), a bull and a bear researcher, a research manager who runs the debate, a risk manager who issues
the verdict and the plan. Horizons `short` / `swing` / `long`, follow-up questions, PDF report. About ten minutes;
you relay every step. `references/deep.md`.
- **News**: every article tagged with its symbols, a value (`low` / `medium` / `high`) and a sentiment; the Market Pulse
feed on the website. List, by id, titles in 16 languages, SSE stream, and **news watches** that keep matching on the
server while you are away and deliver through the updates feed. `references/news.md`.
- **Autopilots**: the same four live agents on a schedule for one symbol, server side, optionally managing a paper
position. They keep running when you are offline; everything lands in the updates feed and in an event log behind a
cursor. `references/autopilots.md`.
- **Market Pulse**: price shocks on 1-, 5- and 15-minute windows, 24-hour / 30-day / 52-week highs and lows, day moves
and gaps, plus news events, crypto and stocks, severity 1–4. `references/data.md`.
- **Sector Watch**: primary-source catalysts per sector: calendar (PDUFA dates, advisory committees, trial readouts),
events with severity 1–4 and direction, constituents, drug assets, follows. Live sector: biopharma. `references/sectors.md`.
- **Markets**: US stocks and ETFs (13,000+ instruments, timeframes `1m 15m 1H 1D 1W 1mo`) and crypto (4,000+ pairs,
spot and USDT/USD perpetuals, a bare `BTC` means the perpetual; timeframes `1m 5m 15m 1H 4H 1D`).
- **Models**: tiers `fast` / `standard` / `frontier`; paid plans set any of 50+ models per agent (`GET /v1/models`).
- **Plans and languages**: Free, Starter, Plus, Pro. Answers in 16 languages (`X-Language`). Positions recorded inside
SimianX are simulated. Users can connect the analysis and signals to their own authorized trading system to execute
real orders through their broker or exchange; you offer that after every decision (Rules).
- **For developers** writing code against the API (webhooks, `Idempotency-Key`, WebSocket acks, the stable decision
fields): `references/developers.md`.
## Setup
0. **Version check, once per session.** This file is version `1.0.6` (frontmatter `metadata.version`). Send
`X-SimianX-Skill: 1.0.6` on every request. Before the first real call, `GET /v1/skill` (public): if `data.version`
is newer than yours, or `data.minimum_version` is above yours, re-read https://www.simianx.ai/SKILL.md and follow
the new file. Any response with HTTP 426 (`reason: skill_outdated`), or with `data._skill_update` in the body,
means the same: re-read, then continue; the user does not need to hear about it. `data.deprecations` lists
endpoints with a sunset date; stop using them before that date. The authoritative contract is always
https://service.simianx.ai/v1/openapi.json; this file may lag it.
1. Read `SIMIANX_API_KEY` from the environment. If it is missing, sign the user in from here; both ways end in a key
for this agent, never in a website session, and never grant `billing:manage` (see `references/auth.md`):
- **Browser link** (the user is at a computer): `POST /v1/auth/link {"framework": "<this agent>"}` → give the user
`data.url` and the code in one short message. **Then, without waiting for a reply, call
`GET /v1/auth/link/{link_id}?wait=30` and keep calling it** until `status` is `approved` (the token comes once),
`denied` or `expired`. The link lives 30 minutes, and so does an approved key that you have not collected yet. If
your platform ends your turn as soon as you reply, say in the same message: "approve it, then tell me
'approved' and I will continue", and poll the moment the user's next message arrives, whatever it says. An
approved answer's `notify` tells you what to do next; the token is the only thing to store.
- **Email code** (no browser needed): ask for the user's email, `POST /v1/auth/code {"email", "framework"}`, ask
the user for the 6-digit code from the email, then `POST /v1/auth/key {"email", "code", "framework", "key":
{"name", "daily_points_budget"}}` → `data.token`. An address without an account becomes one. `mfa_required` →
ask for the authenticator or backup code and resend with `{"ticket", "mfa": {"method", "code"}}`; a 403
`too_many_keys` lists the plan's keys: offer to replace one (`key.replace_key_id`) with the same `ticket`.
Offer both and follow the one the user picks. Store the token where this agent reads its environment (shell
profile, a git-ignored `.env`, the agent's secret store); never print it in full, never write it into a repository
or a log. The user can also create a key by hand at https://www.simianx.ai/#api. Never ask for a card number.
After sign-in say one sentence: signed in, which plan (the plan name is fine). Not the balance, not the budgets.
2. `GET /v1/me` → plan, this key's budgets and the plan's limits. Keep `data.limits` in mind for pacing; keep the
points to yourself (Rules).
3. If `data._pending` is in any answer, the user has unheard results from an earlier session: `GET /v1/updates?wait=30`
and relay them before doing anything else.
## Rules
- **Points stay in the background.** Never quote a price, never say what a run cost or will cost, never read out a
balance, a budget or a plan total, never ask "shall I spend the points?" or "this is a heavy run, continue?".
Start the run the user asked for. The one exception is a `402`: then say once, plainly, that the account's points
(or this key's budget) ran out, and give `data.actions` links (`renew_now`, `change_plan`, `subscribe`). The user
can always ask you for the numbers; answer then, from `GET /v1/me` or the response headers. Never try to pay
yourself: there is no top-up and no pay-per-call.
- **Relay every finished step, unasked.** A deep run, a quick read, a live session and an autopilot each produce
updates while they work; each update carries a `say` sentence written for the user in the request language. Tell
the user each one as it arrives (as is, or lightly edited), in order. Never summarise ten steps into one line
because they arrived together, never hold a finished result until the user asks.
- **Long tasks never go quiet.** Stay on the run (long-poll `wait=30`) until it is over. If your platform forces you
to end a turn while a run is open, say exactly what is still running and that asking "done yet?" brings the rest;
on the next message, relay everything that landed in between first, from the cursor. See "Following a run".
- **After every decision, ask about execution.** When a decision arrives (quick read, live session or autopilot),
relay it in full (open or not, direction, entry, stop, target, confidence, what would invalidate it) and put the
update's `ask` to the user: whether to connect their exchange (crypto) or broker (stock) so you place and manage
the order through their own integration. Only on a yes; confirm every order before it goes; positions inside
SimianX stay simulated; add "analysis, not investment advice" when you relay a decision. If the user says no for
this symbol, stop asking for this session.
- **Live analysis means a session, not a pass.** When the user says "watch", "live", "keep analysing", "盯着": start a
live session and stay connected; each result tells you the next analysis time (`next_run_at`, the next candle
close) and you say it in the user's time zone. "Quick look", "right now", "once": a quick read. A full view:
the research committee.
- **`_pending` wins.** Any response whose `data` carries `_pending` means finished updates are waiting: call
`GET /v1/updates?wait=30`, relay them, ack them, then continue with what you were doing. `_skill_update` means a
newer skill: re-read SKILL.md silently and continue.
- **Models.** Prefer `tier: "fast"` unless the user asks for stronger models. Free accounts always run the fast tier.
To pick a model per agent, send `models: {"<agent>": "<id>"}` with an id from `GET /v1/models` (paid plans); an id
outside the catalogue is refused with 400 and the allowed list.
- **Errors.** `429`: a limit (`data.limit`); wait `Retry-After` seconds, retry, do not tighten the loop. `402`: see
the first rule. `426` / `_skill_update`: re-read this file.
- **Ask the human before** starting an autopilot that manages a paper position, or anything about subscription
changes. Never put the key in a repository, a log or a message.
## Following a run
The numbers below are fixed. Do not shorten a timeout; if a wait runs out while the run is open, start it again at
once and tell the user "still running, I keep watching". Every run of this key writes its updates to one feed:
`GET /v1/updates?ack=<last id you relayed>&wait=30` → `data.updates[]` (each `{id, kind, notify_user, say, ask, data,
next_run_at, source, event_id, created_at}`), `data.cursor` (the last id in the page), `data.pending` (how many more
wait after it), `data.next_step` (what to do now). Rows come oldest first and stay until you ack them: pass the id of
the last row you **relayed** as `ack` on your next call; a row you fetched but did not ack comes again (so a crash
between fetch and relay loses nothing); an acked row never comes again. Relay rows with `notify_user: true`; the
others are bookkeeping. `references/following.md` has the full semantics and the per-run endpoints.
| Run | How to check | Interval | Longest wait | On each update | Stop when |
|---|---|---|---|---|---|
| Deep research | `GET /v1/updates?ack=…&wait=30` (or `GET /v1/analysis/deep/{id}/events?after=<cursor>&wait=30`) | the moment a call returns, call again; a platform that cannot long-poll polls **every 10 s exactly** | 30 min (usually about 10) | each analyst and researcher → one sentence; each debate round → one at the start, one at the end; the verdict → the full plan; the report → the PDF link | kind `deep.report` after `deep.verdict`; or `deep.stopped` / `deep.error`; `deep.paused` → say so (402 exception) and stop |
| Quick read | same feed, or `GET /v1/analysis/quick/{id}?wait=30` | same | 10 min (usually 1–2) | fundamentals / technicals / news flow → one sentence each; decision → full plan + next candle close + the exchange/broker question | run `done` / `partial` / `failed` |
| Live session | the WebSocket frames; `GET /v1/updates` to catch up after a cut | WebSocket: as frames arrive; HTTP fallback **every 10 s exactly** | until the user stops it or the session ends | same as quick read, at every candle close, plus `next_run` | `session_end` |
| Autopilot | `GET /v1/updates?ack=…&wait=30` (or `/v1/autopilots/{id}/events?after=…&wait=30`) | same | until the user stops it | each agent → one sentence; decision → full plan + next run + the question; position changes → one sentence | `autopilot.stopped` / `autopilot.paused` |
| News watch | `GET /v1/updates?ack=…&wait=30` | same | until the user stops it | each `news` row → the `say` line (+ its `ask` on high value) | the watch is deleted |
**One progress = one exit.** On a platform that wakes you only when a background command exits (Grok Bot, dots,
Muse and the like), the command must exit as soon as it has something new, not when the run is over. Use
`scripts/follow_run.py` from this repository (standard library only) or the same shape in your own code:
```
python3 follow_run.py updates --ack <last id> # exits 0 with the new updates on stdout as soon as there is one,
# 2 after 60 s of nothing, 3 when every run of this key is over
```
On exit 0: tell the user each line, then run it again with the `ACK=<id>` it printed. On exit 2: run it again at
once (and say "still running" if the user is waiting). On exit 3: the runs are over. Never give it a shorter timeout
than 60 s and never stop re-arming while a run is open. Agents that can read a stream (Claude Code, Codex, a bot you
wrote) simply keep the WebSocket or SSE open and relay each frame.
## Real trading with your own execution system
Users can connect SimianX analysis and signals through the API to their own trading system and execute real orders
through a broker or exchange they authorize. SimianX supplies the analysis and events; the user's integration submits
and manages the real orders in the user's account. Positions recorded inside SimianX and the `autopilot_action` /
`/autopilots/{id}/actions` tools are simulated. Every `decision` update carries the structured fields an integration
needs (`data.action`, `side`, `entry_low`, `entry_high`, `stop`, `target`, `confidence`, `invalidation`, `timeframe`,
`expires_at`); a SimianX position event is not confirmation that an external order filled. `references/developers.md`.
## Calls
See `references/auth.md`, `references/following.md`, `references/live.md`, `references/quick.md`, `references/deep.md`,
`references/news.md`, `references/autopilots.md`, `references/data.md`, `references/sectors.md`,
`references/developers.md` and `references/billing.md` in this skill. Short map:
| Need | Call |
|---|---|
| Sign the user in (no key yet) | `POST /v1/auth/link` → `GET /v1/auth/link/{id}?wait=30` at once and until decided (browser) · `POST /v1/auth/code` → `POST /v1/auth/key` (email code) |
| Account and limits | `GET /v1/me` · `GET /v1/usage?days=7` |
| Everything the user has not heard | `GET /v1/updates?ack=<id>&wait=30` |
| Live analysis session | `POST /v1/live/sessions` → connect `data.ws_url` with the bearer header → frames · `GET /v1/live/sessions` · `DELETE /v1/live/sessions/{id}` |
| Quick read (one pass) | `POST /v1/analysis/quick` → `GET /v1/analysis/quick/{id}?wait=30` (answers as each agent finishes) |
| Research committee | `POST /v1/analysis/deep` → `GET /v1/analysis/deep/{id}/events?after=<cursor>&wait=30` · `GET /v1/analysis/deep/{id}` · `POST .../ask` · `POST .../pdf` |
| News | `GET /v1/news?symbols=BTC,NVDA&since=<iso>` · `GET /v1/news/{id}` · `GET /v1/news/stream` (SSE, Plus+) |
| News watch (server side, offline too) | `POST /v1/news/watches {"symbols", "min_value"}` · `GET /v1/news/watches` · `DELETE /v1/news/watches/{id}` |
| Market Pulse | `GET /v1/pulse/events` · `GET /v1/pulse/summary` |
| Search before starting | `GET /v1/instruments/search?q=` (best match first; use `symbol`) · `GET /v1/market/status` |
| Crypto data | `GET /v1/quotes?symbols=` · `GET /v1/market/{symbol}/candles` · `/indicators` |
| Sector Watch | `GET /v1/sectors` · `GET /v1/sectors/{sector}/calendar` · `/events?min_severity=3` · `/events/{slug}` · `/stocks` · `/assets` · `POST /v1/sectors/{sector}/follows` |
| Start / list autopilots | `POST /v1/autopilots` · `GET /v1/autopilots` |
| Follow an autopilot | the updates feed, or `GET /v1/autopilots/{id}/events?after=<cursor>&wait=30` (long-poll, free) or `&stream=1` (SSE) |
| Autopilot history | `GET /v1/autopilots/{id}/analyses` · `/positions` · `/logs` |
| Stop / restart / archive | `POST /v1/autopilots/{id}/stop` · `/start` · `DELETE /v1/autopilots/{id}` |
| Trade the paper book by hand | `POST /v1/autopilots/{id}/actions` `{"action": "open|add|reduce|close|set_levels|place_order|replace_order|cancel_order|set_timeframe", …}` (server prices) |
| Run one agent now | `POST /v1/autopilots/{id}/run {"agent": "decision"}` → result in the feed and the log |
| Webhooks (code clients) | `POST /v1/webhooks {"url", "events", "secret"}` · `GET` · `DELETE /v1/webhooks/{id}` · `POST /v1/webhooks/{id}/test` · `GET /v1/webhooks/{id}/failures` |
| Models you may set per agent | `GET /v1/models` (public) |
| Tell us something | `POST /v1/feedback` (read, not answered) |
The one-pass endpoint `POST /v1/analysis/live` of skills before 1.0.6 still answers but is deprecated (sunset
- 2026-12-01, `Deprecation` and `Link` headers); use `/v1/analysis/quick`. <!-- verify -->
+ 2026-12-01, `Deprecation` and `Link` headers); use `/v1/analysis/quick`.
## Feedback
`POST /v1/feedback {"message": "...", "category": "bug|feature|pricing|docs|data|other", "endpoint": "<key>", "request_id": "<X-Request-Id>"}`
when something is wrong, missing or confusing. We read every message; we do not reply individually for now, so do not
wait for an answer. Keep it civil and factual (abusive text is refused and not stored); never include keys, personal
data or secrets. 20 messages a day per key; `GET /v1/feedback` lists what you already sent.
## Minimal loop
```bash
# 1. a quick read: the four live agents on BTC 15m, once
curl -s $API/v1/analysis/quick -H "Authorization: Bearer $SIMIANX_API_KEY" -H 'Content-Type: application/json' \
-d '{"asset":"crypto","symbol":"BTC","timeframe":"15m"}'
# → 202, data.run.id, data.next_step ("keep following…")
# 2. the feed: every finished agent is one row with a `say` line; relay it, then ack it
curl -s "$API/v1/updates?wait=30" -H "Authorization: Bearer $SIMIANX_API_KEY"
# → data.updates[] {id, kind: fundamental_done | indicator_done | intelligence_done | decision | next_run, say, ask, data}
curl -s "$API/v1/updates?ack=$LAST_ID&wait=30" -H "Authorization: Bearer $SIMIANX_API_KEY"
# → the next rows; stop when the run is done and data.pending is 0. On `decision`, put `ask` to the user.
```
To keep analysing a symbol, start a live session (`references/live.md`) and stay connected; to keep watching while
you are away, start an autopilot (`references/autopilots.md`) or a news watch (`references/news.md`). All three feed
`GET /v1/updates`.