Cubicle

The whole Cubicle API as data: the studio's eight-state machine and what each gate asks, every tool with the tier that opens it (and whether it is open to the caller), and the flows. Call it first when asked what Cubicle can do.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

The caller's Cubicle account: their tier (free, Cubicle Operators holder, pro-50, max premium-99), their plan and until when, and every capability with whether it is open and which tier opens it. Call it before telling a trader what they can or cannot do.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

The Cubicle plans (price per 30 days, what each includes) and exactly how to pay on Robinhood Chain in USDG: the treasury, the token, and — when the subscription vault is live — the two wallet transactions (approve, subscribe) that renew automatically every 30 days. Nothing here moves money: the trader signs in their own wallet.

{
  "type": "object",
  "properties": {
    "plan": {
      "type": "string",
      "description": "a plan id (pro-50 or premium-99) to prepare the payment steps for",
      "enum": [
        "pro-50",
        "premium-99"
      ]
    },
    "wallet": {
      "type": "string",
      "description": "the 0x address of the wallet that will pay — needed for the renewing subscription, which is authorized for that wallet only"
    }
  },
  "additionalProperties": false
}

Claim a plan you paid for on chain: give the payment's transaction hash and the paying wallet's EIP-191 signature over the exact message the plans tool returns ("Cubicle plan claim\nagent: <your agent id>\ntx: <tx hash>"). The door reads the transfer to the treasury itself and opens the plan for this principal; only the wallet that paid can claim it. Needs your Cubicle key.

{
  "type": "object",
  "properties": {
    "tx_hash": {
      "type": "string",
      "description": "the payment transaction's hash (0x + 64 hex)"
    },
    "payer_signature_hex": {
      "type": "string",
      "description": "the paying wallet's EIP-191 signature (0x + 130 hex) over the claim message"
    },
    "chain": {
      "type": "string",
      "description": "the chain the payment was made on (Cubicle takes plans on Robinhood Chain only)",
      "enum": [
        "robinhood"
      ]
    }
  },
  "required": [
    "tx_hash",
    "payer_signature_hex"
  ],
  "additionalProperties": false
}

The trading LLM models on the Taifoon venue a trader can study and, on the max plan, follow: each with its status (trading or stopped, derived from its last trade), markets, fills, realized PnL and win rate — all read from the venue, never from a model's words. Simulated market-maker and flow actors are never listed.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

One trading model's record from the venue's first-in-first-out paired closes: realized PnL, maximum drawdown, win rate, per market, and the window. Always say what the record is not: a forecast, or what a follower would have made.

{
  "type": "object",
  "properties": {
    "model": {
      "type": "string",
      "description": "the model's attribution, from the models tool (starts with llm-)"
    }
  },
  "required": [
    "model"
  ],
  "additionalProperties": false
}

Quote following a trading model (max plan): checks the model is live and followable, validates the follower's sizing (fixed_notional usd, or proportional bps of their balance) and caps (max_notional_usd, max_open_positions, max_daily_loss_usd, markets the model trades), and shows what one mirror would be at the given balance. Creates nothing and moves nothing.

{
  "type": "object",
  "properties": {
    "model": {
      "type": "string",
      "description": "the model's attribution from the models tool"
    },
    "sizing": {
      "type": "object",
      "description": "{\"kind\":\"fixed_notional\",\"usd\":50} or {\"kind\":\"proportional\",\"bps\":200}"
    },
    "caps": {
      "type": "object",
      "description": "{\"max_notional_usd\":100,\"max_open_positions\":3,\"max_daily_loss_usd\":40,\"markets\":[\"BTC\"]}"
    },
    "balance_usd": {
      "type": "number",
      "description": "the follower's balance, to show a mirror's size (optional)"
    }
  },
  "required": [
    "model",
    "sizing",
    "caps"
  ],
  "additionalProperties": false
}

The strategies anyone can rent to run a Cubicle spot vault (today: accumulate, which buys a fixed amount of ETH or BTC on an interval up to a budget and never sells): what each does, its parameters, the venues and assets, the limits the vault itself enforces, the fee, how to rent it, and its honest status (not live with real funds yet).

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

A live quote for one accumulate buy on Robinhood Chain: what a USD amount of USDG buys of ETH or BTC on the best Uniswap route right now, the tape's price, the cost against the tape in bps, and whether the vault's own price rule (at most 1% worse than the tape) would accept it. A static call: nothing is signed or sent.

{
  "type": "object",
  "properties": {
    "asset": {
      "type": "string",
      "description": "the asset",
      "enum": [
        "ETH",
        "BTC"
      ]
    },
    "usd": {
      "type": "number",
      "description": "USD of USDG to spend"
    }
  },
  "required": [
    "asset",
    "usd"
  ],
  "additionalProperties": false
}

The caller's trading vaults, read from the chain: each with whether its funds are devnet (test money) or mainnet (real), what is in it, what is free, what is set aside as margin, the mandate and who administers it.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

The wallet steps for a Cubicle vault as UNSIGNED transactions and EIP-712 typed data for the owner's own wallet. Open: call without vault for the transaction that opens it. Fund and hire: call again with the new vault's address (from my_vaults) for allow + deposit and the mandate to sign. Withdraw: withdraw_shares queues shares, then claim_shares pays what the vault's free funds cover to the owner. Chain 4663 is Robinhood Chain (real USDG, invite-only beta, at most 1,000 USDG deposits per vault, not externally audited); 36927 is the devnet (test money). Signs and sends nothing.

{
  "type": "object",
  "properties": {
    "owner": {
      "type": "string",
      "description": "the 0x address of the wallet that owns (or will own) the vault"
    },
    "chain": {
      "type": "number",
      "enum": [
        4663,
        36927
      ],
      "description": "4663 Robinhood Chain (real money) or 36927 the devnet (test money); defaults to the devnet"
    },
    "vault": {
      "type": "string",
      "description": "the vault's 0x address (every call after the first)"
    },
    "kind": {
      "type": "string",
      "description": "what the account is for: spot (trades on Uniswap today) or futures (margin; settles when the venue sends statements)",
      "enum": [
        "spot",
        "futures",
        "funding"
      ]
    },
    "name": {
      "type": "string",
      "description": "a name for the vault"
    },
    "deposit_usd": {
      "type": "number",
      "description": "USD of the stable to deposit (second call)"
    },
    "administrator": {
      "type": "string",
      "description": "who administers the vault under the mandate (second call), e.g. llm-nemotron-dual"
    },
    "margin_usd": {
      "type": "number",
      "description": "margin vaults only: the most the mandate may ever lose (second call)"
    },
    "market": {
      "type": "string",
      "description": "spot administrators only: the market it buys",
      "enum": [
        "ETH",
        "BTC"
      ]
    },
    "withdraw_shares": {
      "type": "string",
      "description": "withdrawal step one: whole shares to queue (read balanceOf(owner) on the vault)"
    },
    "claim_shares": {
      "type": "string",
      "description": "withdrawal step two: whole shares to claim (read claimableRedeemRequest(0, owner) on the vault)"
    }
  },
  "required": [
    "owner"
  ],
  "additionalProperties": false
}

Read a trading idea the way the studio does: the deterministic reader fills the 7 parts (markets, trigger, direction, stand aside, stop, target, session) from the trader's OWN words and says which required parts are still missing. Use it before restating or forging a rule; never fill a part the trader did not say.

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "description": "everything the trader has said about the rule, in their words"
    }
  },
  "required": [
    "text"
  ],
  "additionalProperties": false
}

Move the trader's rule through the studio's state machine when forge is refused: score_parts (Jev scores clarity — needs the trader's own TypeSafe key), accept_parts (the trader accepts the rule as read, without a Jev score), choose_coverage with choice approximate (build from the gates the tape can measure) or stop, reset (start over). Ask the trader before accepting or choosing for them; the studio decides every gate, this only performs the move they chose.

{
  "type": "object",
  "properties": {
    "move": {
      "type": "string",
      "description": "the move",
      "enum": [
        "score_parts",
        "accept_parts",
        "choose_coverage",
        "reset"
      ]
    },
    "choice": {
      "type": "string",
      "description": "for choose_coverage: approximate or stop",
      "enum": [
        "approximate",
        "stop"
      ]
    }
  },
  "required": [
    "move"
  ],
  "additionalProperties": false
}

The studio machine's FORGED move: compiles the trader's strategy from the gates the tape can measure. The studio refuses it unless the strategy has passed READ, CLARIFIED and EXPRESSIBLE — when refused, tell the trader the move the studio is waiting for (it is in the result).

{
  "type": "object",
  "properties": {
    "intent": {
      "type": "string",
      "description": "the rule in the trader's words, every part included"
    }
  },
  "required": [
    "intent"
  ],
  "additionalProperties": false
}

Grade a forge with Jev (RUBRIC_v1): code checks the facts first, then Jev answers whether the code does what the trader said. Spends one of the trader's Jev decisions (trial, plan or their own key). It judges fidelity to their words, never profitability.

{
  "type": "object",
  "properties": {
    "seed_hash": {
      "type": "string",
      "description": "the seed hash forge returned"
    }
  },
  "required": [
    "seed_hash"
  ],
  "additionalProperties": false
}

Walk a forged machine over the real tape with the canonical stepper (the last week by default): how many trades it took, the R, and a comparison with a random null. Call it after a forge when the trader wants to know whether the rule actually fires. A rehearsal is evidence about the past, never a forecast.

{
  "type": "object",
  "properties": {
    "seed_hash": {
      "type": "string",
      "description": "the seed hash forge returned"
    },
    "market": {
      "type": "string",
      "description": "the market to walk, defaults to the one the trader named",
      "enum": [
        "NQ",
        "ES",
        "YM",
        "BTC",
        "ETH",
        "SOL"
      ]
    }
  },
  "required": [
    "seed_hash"
  ],
  "additionalProperties": false
}

Read real candles from the Taifoon tape for one market. Use it to ground an answer in what the market actually did in a past window — never to predict. NQ is not continuous (weekend halt, 21:00 UTC daily break). A past window is SEALED: its bars never change, so cache it. The same tape is open over plain HTTP with no key: GET https://clob.taifoon.dev/tape/v1/candles/{market}/{tf}?from=&to= with unix SECONDS and a User-Agent that names you (OpenAPI: https://www.taifoon.io/clob/openapi.yaml). It is the tape the coordination layer's conformance check replays, so what you read here is what the judge reads.

{
  "type": "object",
  "properties": {
    "market": {
      "type": "string",
      "description": "the market",
      "enum": [
        "NQ",
        "ES",
        "YM",
        "BTC",
        "ETH",
        "SOL"
      ]
    },
    "tf": {
      "type": "string",
      "description": "timeframe (the time machine serves these; build a 15-minute range from 1m or 5m bars)",
      "enum": [
        "15s",
        "1m",
        "5m",
        "1h"
      ]
    },
    "from": {
      "type": "string",
      "description": "window start, ISO-8601 UTC"
    },
    "to": {
      "type": "string",
      "description": "window end, ISO-8601 UTC, in the past"
    }
  },
  "required": [
    "market",
    "tf",
    "from",
    "to"
  ],
  "additionalProperties": false
}

The envelope the forecast sidecar had issued for one market and timeframe by a given time: a MAGNITUDE band (how far price may travel over the next 24 bars, as two prices and a width in ATR), the odds of a move of 0.5, 1 and 2 ATR within 6, 12 and 24 bars, and its measured calibration (ece, n, band coverage). It carries NO direction — there is no side, no median, and the band is symmetric about the last close by construction; say so, and never turn it into 'up' or 'down'. When calibration reads unmeasured or uncalibrated the deck does not draw it and you should say the band is not yet trusted. Facts only, computed in code; nothing here is a recommendation.

{
  "type": "object",
  "properties": {
    "market": {
      "type": "string",
      "description": "the market",
      "enum": [
        "NQ",
        "ES",
        "YM",
        "BTC",
        "ETH",
        "SOL"
      ]
    },
    "tf": {
      "type": "string",
      "description": "timeframe the sidecar forecasts",
      "enum": [
        "5m",
        "1h"
      ]
    },
    "at": {
      "type": "string",
      "description": "ISO-8601 UTC time the envelope must have been issued by (defaults to now); for a replay, the logical clock"
    }
  },
  "required": [
    "market",
    "tf"
  ],
  "additionalProperties": false
}

What the deck's chart would show for one market, timeframe and window, as ONE JSON object computed in code: the bars (count, first and last, the last candle), the indicators drawn, the trader's own marked levels and zones (theirs — they may be used as levels the trader gave), the envelope under its draw gate and its facts, and the fact sheet of the window (open, close, high, low, range, change, volume, session). Use it instead of reading pixels: every number is measured, not read. Past windows only; at most 600 bars.

{
  "type": "object",
  "properties": {
    "market": {
      "type": "string",
      "description": "the market",
      "enum": [
        "NQ",
        "ES",
        "YM",
        "BTC",
        "ETH",
        "SOL"
      ]
    },
    "tf": {
      "type": "string",
      "description": "timeframe",
      "enum": [
        "15s",
        "1m",
        "5m",
        "1h"
      ]
    },
    "from": {
      "type": "string",
      "description": "window start, ISO-8601 UTC"
    },
    "to": {
      "type": "string",
      "description": "window end, ISO-8601 UTC, in the past (the logical clock for a replay)"
    },
    "indicators": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "indicator ids to include, e.g. [\"ema20\",\"vwap\",\"envelope\"]; defaults to ema20 and envelope"
    }
  },
  "required": [
    "market",
    "tf",
    "from",
    "to"
  ],
  "additionalProperties": false
}

The deck's own chart plate for one market, timeframe and window, rendered server-side from the same geometry the screen uses (bars, indicators, the envelope cone when its calibration permits) as a PNG you can look at, together with the chart_state JSON for the same window. The picture is for shape; the numbers are in the JSON — quote those, never read them off the image. Past windows only; at most 600 bars.

{
  "type": "object",
  "properties": {
    "market": {
      "type": "string",
      "description": "the market",
      "enum": [
        "NQ",
        "ES",
        "YM",
        "BTC",
        "ETH",
        "SOL"
      ]
    },
    "tf": {
      "type": "string",
      "description": "timeframe",
      "enum": [
        "15s",
        "1m",
        "5m",
        "1h"
      ]
    },
    "from": {
      "type": "string",
      "description": "window start, ISO-8601 UTC"
    },
    "to": {
      "type": "string",
      "description": "window end, ISO-8601 UTC, in the past"
    },
    "indicators": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "indicator ids to draw; defaults to ema20 and envelope"
    }
  },
  "required": [
    "market",
    "tf",
    "from",
    "to"
  ],
  "additionalProperties": false
}

Look at a chart the trader attached (the id is in the studio state). Read what is on it — instrument, timeframe, levels, the pattern they point at — and say plainly that numbers read off a picture are READ, not measured; check the ones that matter against the tape.

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "the attached image's id"
    }
  },
  "required": [
    "id"
  ],
  "additionalProperties": false
}

List the Cubicle skill bank: every skill's name, family, grade and status (runnable / stub / concluded). A stub is a promise, not a capability — say so when you cite one.

{
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

Read one skill's method (its SKILL.md) — only the methodology and engineering skills are readable; strategy, lens, pillar and copy skills are sealed and will be refused.

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "the skill's name as the skills tool lists it"
    }
  },
  "required": [
    "name"
  ],
  "additionalProperties": false
}