← ComputeCafe
Global Hackathon Tour · H2 2026

How the stack works

ComputeCafe's venue pages come from the venue-scout pipeline — SF and LA as hand-driven runs, the multi-city rollout as autonomous agents on the stack below. This is the infrastructure, contracts, and honesty rules that make the output trustworthy, with what runs today marked apart from what's the rollout target.

The seven layers

Each layer does one job well; together they replace manual venue research with an auditable, fetch-verified pipeline. The request flow today, operator-driven from one machine, is: Claude Code (harness) → Kimi Relay (router) → Nebius Token Factory (host) → Kimi K3 (model), with Tavily tools and Tenki sandboxes around the edges. The rollout target (plan §6) moves the same stages into a slimmer OpenAI-compatible agent loop running inside Tenki sandboxes.

Harness
🧰 Claude Code
Anthropic · agent harness / CLI
Anthropic's agent harness is what actually runs each city ComputeCafe scout: it drives the subagent fan-out (one agent per neighborhood × venue type), the tool loop, skills, permissioning, and the long-horizon research session. Everything on this page happens inside Claude Code.
The harness running this pipeline; subagents, skills, and the tool loop are Claude Code primitives.
Router
🔄 Kimi Relay
klaude · local CLI wrapper
A local wrapper (the klaude command) that points Claude Code at Kimi K3 inference endpoints instead of Anthropic's API. It injects the Tavily MCP tools per-session and forwards auth to Nebius Token Factory — the bridge between the harness and the open-weight model.
Self-described by klaude --help as "Kimi Relay ▸ Routing Claude Code → Nebius Token Factory."
Model
🧠 Kimi K3
Moonshot AI · open-weight frontier
The reasoning engine inside every agent. Up to 1-million-token context means a whole city's neighborhood research, venue fetches, and link verification fit in one coherent session without aggressive summarization.
Model confirmed in-session as nebius-kimi-k3; Kimi API docs list kimi-k3[1m].
Host
☁️ Nebius Token Factory
Inference platform · OpenAI-compatible API
Token Factory hosts Kimi K3 behind an OpenAI-compatible endpoint. It handles streaming, billing, and rate-limiting — with Kimi credits part of the tour's partner program, so per-city agent runs stay cheap.
Reached through the Kimi Relay router; documented in the multi-city research plan.
Search & Verify
🔍 Tavily
Web search + extraction · MCP tools
Tavily search finds neighborhoods and venue candidates; Tavily extract fetches each venue's events page to confirm it actually covers private events and isn't a 404. Every tool call is logged line-by-line.
Injected per session; 103 tool calls across the Toronto dry-run pilot alone. Evidence log ↗
Runtime
🛡️ Tenki
Disposable Linux sandboxes · per-city VMs
Tenki provides clean, killable, parallelizable VMs for autonomous city runs. The dry-run used local subagents for speed; Tenki is the target runtime for wave-deploying 3–5 cities in parallel as we approach the Sep 1 APJ deadline.
Target platform per the multi-city research plan §3.
Review
✅ Adversarial QA
Fresh-context re-check · target: Tenki sandbox
A fresh agent with no research context adversarially re-checks sampled "dedicated events page" claims, then a review card (top picks, closures, low-confidence flags) goes to a human for the sign-off that precedes any public page flip. In the dry run this card was built by the orchestrating session; a fresh-context reviewer in a Tenki VM is the rollout target.
QA stage per the multi-city research plan §4 (stage 6); the Toronto pilot review card shows the deliverable shape.

What research actually looks like

  1. Frame: Tavily searches for where recent tech events in the city actually clustered — not where a blog says they should, but where TechTO, AI Tinkerers, and Elevate satellite events were held.
  2. Discover: One agent per neighborhood × type (cafes, coworking, event spaces) — parallel, so no single context drowns. Each agent returns candidate venues with fetched URLs.
  3. Verify: The core gate. Every candidate's events page is fetched. If it 404s or doesn't mention private events, the venue is dropped — not silently, but logged. Closures go to a "Gone" footnote.
  4. Photos: From pages already extracted, agents pick one wide interior/patio shot per venue. If a site blocks images or the shot is a logo, the template shows a clean monogram placeholder instead.
  5. Build: A deterministic Python script assembles the city page from the config + the explorer template — no LLM in this step, nothing to hallucinate.
  6. QA: validate_config.py enforces the schema and data-honesty rules (required fields, verified links, bolded capacities, photo-caption alts). A review card flags what a human must confirm.

Honesty rules we enforce in code

These are not aspirational — they're checked by scripts, not by promises.