Engineering
Double Hackathon Weekend
· 4 min read
four1: research across machines and providers
Two hackathons over September 26–27 brought together two projects: four1, a network designed to connect research sessions across machines and model providers, and Csim, a foundation for cellular simulation. Both were built with coding agents. Both also needed a reliable way to retain experiment attempts while their application code changed. Ocura OSS supplied the execution ledger in each.
For Sunday’s Own Your Intelligence Hackathon at YC, four1 was designed for cross-machine, cross-provider communication over a shared research network. Node A and Node B can use different agent harnesses and model providers on their owners’ computers, keeping their accounts, runtimes and private histories local. The goal is an automatic research network in which registered sessions can find related work, exchange selected context and request contributions.
Participants register the work they want to share in four1 and pair their nodes through project invitations. four1 authenticates requests with project access grants, giving authorized peers access to registered records and approved context. This provides a common communication layer across providers, with each node retaining control of what it shares and what work it runs.
The code itself provides a starting point. A contributor registers completed work against a repository, commit and exact file. Another node can look up that code and request context associated with the matching session. The contributor’s selected explanation can preserve the original problem, constraints, alternatives considered and evidence behind a decision. A later reviewer can use that creation context to understand why the code took its present form.
Once the contributor approves an excerpt for automatic sharing, their running node can answer subsequent authorized requests without reopening the original chat or asking them to repeat the explanation. The current prototype supports this direct lookup and automatic return of selected context between paired nodes. Fourboard also carries project messages to participating nodes, where owners can select them for further contributions. New agent work follows the owning node’s execution policy.
The broader aim is a research network that grows with each registered session. New investigations can discover prior work, reuse its shared context and request further contributions across harnesses. Today, discovery and approved context retrieval work between explicitly paired, reachable nodes; coordinating new agent work automatically is a further step.
The local demonstration exercised the research exchange across two separate harnesses. An agent on Node A proposed a pulse-and-recovery experiment. A synthetic fixture ran through Ocura OSS, and its verified output went to an agent on Node B for review. The agent on Node A then used the returned critique to revise the proposed experiment with additional controls and calibration checks. Both nodes ran on one computer; testing on separate computers is next.
Ocura OSS supplies the execution evidence within this network. four1’s worker records an experiment, reads verified output and attaches a receipt to the task; the server checks the ledger before marking the experiment complete. four1 connects the selected context, contribution and resulting artifact, while Ocura OSS retains the record of what ran. Together, those records let a reviewer inspect both an experiment’s output and the context used to decide the next step.
Update: the four1 repository has been taken private due to its potential value.
Csim: exploring how cells respond
Saturday’s Healthcare AI Hackathon provided the setting for Csim. Its longer-term aim is to learn how cells respond to their environment and interventions, then use those responses within a larger biological simulation. Shared models that adapt across cell types and eventually individual subjects are a research direction; the current work establishes the simulation and evaluation foundation.
The local playground makes that foundation tangible. You can step one to five virtual cells through a shared environment, vary stimulus and payload delivery, and inspect what changed in each accepted interval. Paired response views compare schedules, while recorded campaigns collect results across multiple conditions. Observed p65 trajectories are displayed separately from synthetic cell-response traces.
Csim’s integrated demo already had to produce traces, check amount balances, hash result artifacts and evaluate numerical outputs. It uses ocura-oss run --json to record the command, outcome and logs, then ocura-oss verify --json to check the saved history. That execution record sits alongside Csim’s own checks.
One preserved attempt shows why that distinction matters: Ocura OSS’s logs verified, but Csim rejected the receipt because source files changed during execution. A later run accepted all 13 demo components and verified 64 logs. Both attempts remained inspectable. These checks support the local implementation; biological calibration and validation remain future work.
What both projects reused
The common implementation work was command recording: arguments, exit status, timing, stdout and stderr, persistent identifiers, and checks for changed logs. Both projects could use the same package interface for that layer. Csim called the CLI; four1 connected a Python worker to its task service. Each application still needed an adapter and its own result checks.
That is a useful reduction in scope when building with agents. The project can specify which workload to run and what its output means while reusing an established record format and verification path. We did not measure hours or tokens saved, but the code shows which responsibilities stayed in the applications and which came from Ocura OSS.
Experiment storage earns its place when those records are used again. In Csim, they preserve a failed attempt and the successful rerun for inspection. In four1, a saved result can travel with its receipt into another harness, alongside the selected context that explains the work. The receiving session has both the result and an inspectable basis for its next contribution.
Ocura OSS records and verifies local execution evidence. The applications decide which artifacts to retain or share, how to interpret results, and what should happen next. Across two different builds, that boundary let the experiment history remain consistent while the surrounding software took shape.