Skip to content

UCCA — Cloudflare Recon Findings

Verdict up front: FITS — WITH CONDITIONS. The whole spine can live in the one UCCA account (e5a98302…, verified "Admin@ucca.online's Account"). Three conditions, none a blocker: (1) an AI-scoped token for the §5 live-neuron confirmation; (2) AU data residency is best-effort (location hint), not a contractual guarantee on Cloudflare — the one real finding for the legal ledger; (3) the container invocation pattern is queue-drained, not request-scoped. Recommendation in §6; decision reserved to Tim.

§1 — Containers fit: FITS

Instance types (CF Containers, live 2026-07-02):

Type vCPU Memory Disk
lite (=dev) 1/16 256 MiB 2 GB
basic 1/4 1 GiB 4 GB
standard-1 (=standard) 1/2 4 GiB 8 GB
standard-2 1 6 GiB 12 GB
standard-3 2 8 GiB 16 GB
standard-4 4 12 GiB 20 GB

Account caps: 6 TiB memory / 1,500 vCPU / 30 TB disk concurrent; 50 GB total image storage/account; image size ≤ the instance's disk cap.

  • 1.1 Sizing — fits comfortably. Decisive fact: the reasoner does not run a model locally — it calls LLM APIs (Anthropic / Workers AI). So local memory/CPU is modest: a Python process orchestrating HTTP calls. Static footprint is tiny (generator/ 456K, engine/ 152K, 8 deps). basic (1 GiB) is likely enough; standard-1 (4 GiB) is ample headroom. Not memory-bound — it's wait-bound on the LLM. Runtime memory/CPU under load is unmeasured (needs one instrumented run); everything else says fits.
  • 1.2 Image size — trivial. Python base (~150 MB) + anthropic/httpx/gen deps → low hundreds of MB, far under the 8–20 GB disk/image cap and the 50 GB account store.
  • 1.3 Job duration vs lifecycle — the real design point. A real course job is 25 LLM calls, minutes of wall-clock, most of it LLM wait (measured from the on-disk cost ledger). Against a ~10-min idle shutdown, request-scoped containers are wrong. Recommend: Queue → long-lived container draining the queue (or container-per-job with keepAlive held across LLM waits, explicit destroy on completion). Not Workers-per-job (LLM waits blow the Worker CPU model).
  • 1.4 Fossil import — already actioned. The generator imports contextualisation from worlds/ (generate_complete_course.py:46). Containerising is the rebuild. Sized and folded into UCCA-INPUT-PATH-BUILD-BRIEF-01 Step 5 (re-source mechanism → content stays payload-side → sever). Bounded, not its own step.
  • 1.5 Egress. Container must reach R2 (bindings or S3 API), D1, the keys worker, and external LLM APIs (direct-wire). All reachable; container-side bindings work with the usual caveat that some Worker-only bindings need the Workers-side proxy. Confirm binding parity on the first build.

§2 — Cost profile (LLM dominates; the cap is the ceiling)

LLM line — concrete, from the real ledger (one full course = 25 calls, 19,605 in / 19,668 out tokens):

Model (per course) $/course Neurons (Workers AI)
GLM-5.2 (test phase) ~$0.11 ~10,362
Sonnet-4 frontier (sensitivity) ~$0.35 n/a (direct API)

Note: one course ≈ 10,362 neurons ≈ the entire 10,000/day free allocation. So ~1 free course/day; the mechanics-test phase is close to free at single-digit volume.

Scenario shape (concurrency cap = 2 proposed; the cap is the ceiling):

Scenario Jobs LLM/mo (GLM-5.2) Infra/mo (CF, order-of-mag)
Dev ~5/wk (~20/mo) ~$2 (mostly free-tier) ~$5 (Workers Paid base)
Client-one steady ≈ dev-scale (per relay 2026-07-02: RTOpacks volumes low, test-phase their side too; real figure to follow when they operationalise) ~$0.11/job small
Ten clients client-one ×10 ×10 small
  • (a) CF consumption, cap=2: the cap bounds container active-compute to 2 × standard-1 running flat-out — a fixed monthly ceiling regardless of demand spikes (consumption-with-a-cap = fixed-with-a-ceiling). Workers/Queues/D1/R2 at these volumes are cents-to-low-dollars. Exact CF infra rates (Workers $/M req + CPU-ms, Queues $/M ops, D1 rows, R2 GB + ops, Container vCPU/GiB-sec) not re-pulled this pass — LLM dominates by an order of magnitude regardless; confirm on the pricing page before any deck.
  • (b) Fixed external comparator: a Fly.io machine or Cloud Run min-instance (~$5–25/mo) buys a always-on box but adds honest ops overhead: patching, uptime, secrets-on-the-box, and an edge→external network hop that the all-CF path avoids. Not recommended unless CF Containers prove a fit problem.
  • LLM is the dominant line either way — the cost story is "price per course × courses," not infra.

Credit mechanics (footnotes, from the brief): startup credits valid 1 year from approval (clock starts on approval, not usage — application deferred until ground broken); R2 covered to $10k; Workers AI to $50k; AI Gateway NOT covered — reinforces the direct-wire policy (§4).

  • 3.1 Containers. Regional + jurisdictional placement constraints exist (shipped 2026-04-05). But Oceania (OC) is a limited-capacity region — it cannot be used exclusively without including another region or contacting support/Enterprise for dedicated access. So AU-pinned container placement is configurable but constrained, not a clean guarantee at our tier.
  • 3.2 R2. Location hints include oc (Oceania) and apac — best-effort placement for performance. But jurisdictions (residency guarantees) = only eu and fedramp. There is NO Australia/APAC jurisdiction. → R2 in Australia is a location hint, not a residency contract. This is the one finding that matters for the DPA.
  • 3.3 Workers AI hosting (GLM-5.2). GLM-5.2 on Workers AI runs CF-hosted open weights — so inference happens on Cloudflare's GPUs, not Z.ai's cloud. Using the CF-hosted model therefore avoids the "Z.ai cloud API is subject to Chinese law" data-exposure (payloads go to CF, not to Z.ai). Caveat: the GPU region is CF's global network, not pinnable to AU — so it dodges the China exposure but is not an AU-residency guarantee. Test phase is synthetic payloads only → nothing blocks; this feeds STRATEGY-01's legal ledger (DPA wording, cross-border/residency).

Net for the legal ledger: Cloudflare gives AU performance placement (location hints) but not AU data residency as a contractual jurisdiction. If a client's DPA needs guaranteed AU residency, that's an Enterprise-paper conversation or a non-CF store for that data — flag, not a build blocker.

Residency ruling (Tim, 2026-07-02) — bake in, build nothing visible: - Placement is explicit config, defaulted now — the build sets R2 location hint and container region as declared config (default oc/apac), not implicit "nearest request." Cheap to set now; expensive to retrofit. - Artefact/provenance addressing is tolerant of multiple storage loci — R2 keys and the §4.3 provenance corpus_citation/artefact pointers carry a storage-locus dimension, so a future second store (another region, or a non-CF residency store for one client) needs no addressing rework. Design-in now; expose nothing. - Client-selectable residency → v1.1 / UCCA-INTAKE-01 candidate, alongside client-facing thinking-tiers. NOT built, NOT surfaced on the frozen v1.0.

§4 — LLM adapter layer (audit + interface spec)

  • 4.1 Existing client — audited. Uses the official Anthropic SDK (from anthropic import Anthropic), pinned anthropic==0.75.0. Latest on PyPI is 0.116.0 (2026-07-02) — the pin is badly behind (~40+ minor releases). Modernise the plumbing in the adapter; preserve the pattern. The cost-request pattern is the right instinct and already built: a COGNITIVE COST LEDGER (backend/cognitive_cost/cognitive_cost.jsonl + per-run ai/cognitive_cost.jsonl) writes one append-only JSONL record per call — provider, model, unit_id, request_id, input_tokens, output_tokens, repo-pinned pricing, cost_usd, cumulative_after_usd, ts_utc. That is the §4.2 usage-capture requirement, on disk today.
  • Protect on migration: the JSONL → D1 migration must preserve append-only. The ledger is provenance-adjacent and future client-billing data — it must not become an updatable table. Insert-only (or an event table), never UPDATE/DELETE.
  • 4.2 Adapter interface spec (spec only; builds with the input path): provider-agnostic call surface; per-call model selection; usage capture built in (the ledger fields above) → first-party D1 store, engine-owned (future billing). Direct-wire policy: no AI Gateway (the 5% fee buys nothing we must not already build; provenance needs unmediated calls — no silent cache/retry/reroute between reasoner and model). Workers AI models go via the binding (that's the host, not middleware). Two switchers: engine-internal model selection built now (audit what admin.ucca.online's backend must expose); client-facing thinking-tiers touch the job contract → file as a v1.1 / UCCA-INTAKE-01 candidate, NOT built, NOT leaked into the frozen v1.0 surface.
  • 4.3 Anthropic-compatible fallback — cheap. Because the code already uses from anthropic import Anthropic, standing up GLM-5.2 via Z.ai's Anthropic-compatible endpoint is a base-URL + key swap against the existing client — the adapter's first two providers (Anthropic direct + GLM-5.2 direct-wire) are near-free to wire.

§5 — GLM-5.2 ground truth

  • 5.1 Price — NOW PUBLISHED (the brief's "absent from the pricing table" is stale as of 2026-07-02; it's on the page): input $1.40/M tokens (127,273 neurons/M) · cached input $0.26/M (23,636/M) · output $4.40/M (400,000/M). This confirms the suspected Z.ai parity ($1.40/$4.40) — no longer unverified. Workers AI: $0.011 / 1,000 neurons.
  • 5.2 Context & modes. CF caps context at 262,144 tokens (vs the model's native 1M); two reasoning modes. Irrelevant to today's payload sizes — recorded per the brief. Which modes are exposed through the binding: confirm on first use.
  • 5.3 Free daily allocation — confirmed 10,000 neurons/day. Real draw: one course ≈ 10,362 neurons → ~one free course per day; the mechanics-test phase is ~free at single-digit volume.
  • Live-call status — CONFIRMED (2026-07-02). UCCA account verified ("Admin@ucca.online's Account", e5a98302). With the new AI-scoped deploy token in place, the GLM-5.2 inference call now returns HTTP 200 — success:true, model:@cf/zai-org/glm-5.2, usage: 17 prompt / 16 completion (id b7757724957a4b7f80017d6812bfc336, cf-ray a1505172f801adf8). That trivial call drew ~8.6 neurons (17×127,273 + 16×400,000 per M). The model, the wire format, and the published rates are all confirmed live. The dashboard neuron-draw read is now an optional belt-and-suspenders cross-check, not a gate. (Earlier 401 was the pre-update token lacking Workers AI scope — resolved.)

§6 — Recommendation (decision reserved to Tim)

Put the whole spine in the one UCCA account on Cloudflare: gate (Worker) → Queue → reasoner (Container, standard-1, queue-drained) → D1 (job state + the cost ledger, append-only) → R2 (artefacts) → keys worker (signing) → LLM via a provider-agnostic adapter (Anthropic direct + GLM-5.2 direct-wire, no AI Gateway). It fits, it's cheap (LLM-dominated at ~$0.11/course test), and it keeps provenance unmediated. The one caveat to carry into every client conversation: Cloudflare gives AU placement (location hints) but not AU residency as a jurisdiction — a legal-ledger item, not a build blocker.

If Tim rules for this runtime, it should be drafted as a Class B ADR (binds on ruling, mints when a proof job runs on the chosen runtime — dovetails with ADR-0002's proof event).

Open, flagged (not resolved here)

  • §5 live call → CONFIRMED 2026-07-02 (AI-scoped deploy token; HTTP 200). Dashboard neuron read is an optional cross-check, not open work.
  • §2 exact CF infra rates → confirm on the pricing page before any deck (LLM dominates regardless).
  • Client-one steady-state → ≈ dev-scale per relay 2026-07-02 (RTOpacks test-phase); real jobs/month to follow when they operationalise.
  • v1.1 / UCCA-INTAKE-01 candidates surfaced: client-facing thinking-tiers (§4.2); client-selectable residency (§3). Neither built; neither touches the frozen v1.0.

Sources (live 2026-07-02): Workers AI pricing · GLM-5.2 model · Containers limits · Containers placement · R2 data location · anthropic on PyPI. Repo evidence: the on-disk cognitive-cost ledger and requirements.txt. Live GLM call: cf-ray a15019be5acac152 (401, token scope).