Dev.to AI 🤖 Ai Mon, 09 Nov 2026 01:43:04 +0000 👁 0 📖 11 min read

How We Took Second at a Hackathon with Codex and 18 Git Worktrees

A friend and I took second place at the Codex Community hackathon in Guadalajara with Panas. Across roughly 47 hours, we used 18 Git worktrees and merged 44 pull requests. The Codex usage I recovered from my machine would cost about $162 USD at standard OpenAI API rates, before credits. The hackathon gave us both API credits and Codex credits.

One merge explains how we worked. Three branches were ready for review. When we brought them together, the registry branch hit a conflict in the shared contracts package. After we resolved it, CI surfaced a provider test that timed out on the Linux runner. The worktrees let the agents make progress in parallel. Review and CI told us whether we could merge that progress.

What we were building

Panas lets an agent find an idle machine, agree on a price, and run an inference job over a peer-to-peer connection. The buyer uses MCP, MCPWire handles the connection, and the provider runs the model in a sandbox. The demo provider served Qwen 2.5 0.5B. Panas source

How we split the work

1. Turn the PRD into a dependency map. We wrote down how buyers discover providers, what makes a machine ready, how a job is bounded, and how payment gets verified. Then we turned those decisions into GitHub issues. After PR #11 set up the workspace, shared types, and CI, provider, transport, and registry could start in parallel. The buyer could scaffold against shared types, with end-to-end verification waiting on those pieces and accounting. PRD · Team plan · Foundation PR

2. Give each agent a branch and a check it can run. The provider had to run inference on a real Mac and stay out of discovery until it was ready. The transport had to complete a peer round trip and survive a disconnect. The registry had to support authenticated discovery against a deployed endpoint. The coordinating session handled changes to shared contracts while the child agents worked in separate checkouts. Provider PR · Transport PR · Registry PR

3. Combine the branches in an integration worktree. Cross-review caught a registry bug where a provider marked unhealthy could reuse old capability evidence. We added a regression test and required fresh evidence after a failure or key rotation. The combined checkout passed 43 tests, along with formatting, lint, type checks, and the build.

4. Merge in order and rerun the checks. After review, I asked Codex to merge the three PRs. Provider and transport went first. Codex resolved the registry conflict, then used the CI failure log to find the provider test timeout. It widened the test's polling window while preserving the concurrency assertions, reran the checks, and merged the registry PR once CI passed.

That workflow ran across 18 worktrees, including feature branches and integration checkouts. In the same window, we opened 21 issues, merged 44 PRs, and recorded 155 commits in the history reachable from main, including 47 merge commits. GitHub PRs · Commit history

Follow one round from delegation to merge

The excerpt starts with my request to split three issues in parallel. Open the tool calls for worktree creation, delegation, the merge conflict, and the CI timeout. Some commands and outputs are abridged.

Panas: the first parallel wave, with tool calls

You

ok, lets merge the foundations PR and start tackling issues #2, #3 and #4 in parallel

Agent

I’ll check and merge the foundation PR, then start issues #2, #3, and #4 with separate agents and worktrees so the implementations can proceed in parallel.

Agent

▸ exec gh pr merge 11 -R carlosrivera/panas --squash --match-head-commit 4f4b3d9c01e...

Input

gh pr merge 11 -R carlosrivera/panas --squash --match-head-commit 4f4b3d9c01e46550c6a4d185efa042ec859f0343

Output

null

Agent

▸ exec git worktree add -b codex/issue-2-provider ~/code/panas-worktrees/provider or...

Input

git worktree add -b codex/issue-2-provider ~/code/panas-worktrees/provider origin/main; git worktree add -b codex/issue-3-transport ~/code/panas-worktrees/transport origin/main; git worktree add -b codex/issue-4-registry ~/code/panas-worktrees/registry origin/main

Output

Preparing worktree (new branch 'codex/issue-2-provider')
Preparing worktree (new branch 'codex/issue-3-transport')
Preparing worktree (new branch 'codex/issue-4-registry')

Agent

▸ followup_task {"target":"team_plan"}

Input

{
  "target": "team_plan"
}

Output

null

Agent

▸ followup_task {"target":"web_foundation"}

Input

{
  "target": "web_foundation"
}

Output

null

Agent

▸ spawn_agent {"task_name":"registry"}

Input

{
  "task_name": "registry"
}

Output

null

Agent

PR #11 is merged, and foundation issue #1 is closed. Three agents are now working from that merged baseline:

#2: macOS capability tests and the persistent inference daemon.
#3: MCPWire process supervision, cleanup, and peer probing.
#4: durable provider registration and agent discovery on Volcano.

I’ll coordinate the shared contracts and review their integration points. The local site remains running.

The provider needs real hardware evidence as well as fixture tests. I’ll set up Ollama in the project’s ignored local directory and fetch the small test model—about 400 MB—so we can validate inference on this Mac without installing a system-wide service.

The three lanes have agreed on capability reports and peer-probe results. The registry agent has provisioned a dedicated Postgres database in the Panas project and is implementing signed provider registration plus authenticated MCP discovery.

Ollama is running on a loopback-only test port and detects this Mac’s Metal GPU. The small model is downloading for the provider’s real inference checks.

All three lanes now have passing component tests. The provider’s real Mac capability test passed with the pinned small model, and it correctly stays undiscoverable until a peer probe verifies connectivity.

During review, I found a deadline gap around the provider’s metadata check. The agent is tightening that bound before opening its PR. The registry is testing against cloud Postgres, and transport is running a real MCPWire peer round trip.

The MCPWire smoke test passed: separate peer processes completed a round trip, disconnecting a peer left the daemon running, and restarting the host produced a new ticket.

The registry’s Postgres integration tests also passed. Its HTTP function is deploying now; next is a discovery call through an official MCP client against that deployed endpoint.

Agent

▸ exec git worktree add -b codex/integration-issues-2-4 ~/code/panas-worktrees/integ...

Input

git worktree add -b codex/integration-issues-2-4 ~/code/panas-worktrees/integration origin/main

Output

Preparing worktree (new branch 'codex/integration-issues-2-4')

Agent

▸ exec git merge --no-edit codex/issue-2-provider; git merge --no-edit codex/issue-3...

Input

git merge --no-edit codex/issue-2-provider; git merge --no-edit codex/issue-3-transport

Output

null

Agent

▸ followup_task {"target":"web_foundation"}

Input

{
  "target": "web_foundation"
}

Output

null

Agent

PRs are open for the provider and transport work. Registry discovery has also passed a call through an official MCP client against the deployed Volcano endpoint, and it rejects unauthenticated requests.

I’m combining the three branches in a local integration worktree to check for shared-schema conflicts and run the full suite. Only the foundation PR has been merged into main; the new PRs will stay open for review.

Agent

▸ exec git merge --no-edit codex/issue-2-provider

Input

git merge --no-edit codex/issue-2-provider

Output

null

Agent

Cross-review found one readiness gap in the registry: a provider could reuse old capability evidence after being marked unhealthy. The agent is fixing that transition and adding a regression test before opening the PR.

The provider and transport PRs have passed CI. The remaining check is to combine all three implementations and run the repository suite.

The local site is still running. I’ve shut down the temporary Ollama test server after the hardware checks; the runtime and small model remain in the project’s ignored local directory for reuse.

The registry fix now distinguishes first-time verification from evidence that was retired after a failure. That lets a fresh provider complete its peer probe while requiring new tests after an unhealthy state or key rotation.

Agent

▸ exec git merge --no-edit codex/issue-4-registry

Input

git merge --no-edit codex/issue-4-registry

Output

CONFLICT (content): Merge conflict in packages/contracts/package.json
Automatic merge failed; fix conflicts and then commit the result.

Agent

▸ exec git checkout --theirs packages/contracts/package.json git add packages/contra...

Input

git checkout --theirs packages/contracts/package.json
git add packages/contracts/package.json
git commit --no-edit
pnpm install --frozen-lockfile
pnpm format:check
pnpm check

Output

null

Agent

▸ exec Poll the integration validation command and check PR #18

Input

Poll the integration validation command and check PR #18

Output

Test Files  7 passed | 2 skipped (9)
Tests  43 passed | 8 skipped (51)

Agent

All three PRs are ready for review and have passed CI. The combined branch also passed formatting, lint, typechecks, the web build, and 43 tests.

Separate checks covered real Mac inference, a real MCPWire peer round trip, seven Postgres integration tests, and discovery through the deployed MCP endpoint. The new PRs remain open; only the foundations are merged into main.

Merged foundation PR #11 and closed issue #1.

The parallel work is implemented in three review-ready PRs:

Issue	Implementation	PR
#2	macOS capability tests and persistent inference daemon	#16
#3	MCPWire lifecycle supervision and peer probes	#17
#4	Durable registry and authenticated MCP discovery	#18

All three passed CI. The combined branch passed 43 tests, typechecks, lint, and build. Separate checks verified real Mac inference, MCPWire peers, Postgres, and deployed MCP discovery.

The new PRs remain unmerged for review. Your local app is still running.

You

merge them

Agent

I’ll check the latest CI results, merge all three PRs, and resolve the shared-contract overlap as needed. Then I’ll update local main and verify it.

Agent

▸ exec gh pr merge 16 -R carlosrivera/panas --squash --match-head-commit f4699a28a2e...

Input

gh pr merge 16 -R carlosrivera/panas --squash --match-head-commit f4699a28a2e1f2172414afd3ce5ec17722fb90b4
gh pr merge 17 -R carlosrivera/panas --squash --match-head-commit 1fcae1465da2129111f31e472561f3820fd14ceb
git fetch origin
gh pr view 18 -R carlosrivera/panas --json mergeable,mergeStateStatus

Output

null

Agent

▸ exec git status --short; git merge --no-edit origin/main

Input

git status --short; git merge --no-edit origin/main

Output

CONFLICT (content): Merge conflict in packages/contracts/package.json
Automatic merge failed; fix conflicts and then commit the result.

Agent

▸ exec git checkout --ours packages/contracts/package.json git add packages/contract...

Input

git checkout --ours packages/contracts/package.json
git add packages/contracts/package.json
git commit --no-edit
pnpm install --frozen-lockfile
pnpm format:check
pnpm check

Output

null

Agent

▸ exec git push origin codex/issue-4-registry gh pr checks 18 -R carlosrivera/panas ...

Input

git push origin codex/issue-4-registry
gh pr checks 18 -R carlosrivera/panas --watch --interval 10

Output

null

Agent

The provider and transport PRs are merged. I resolved the registry PR’s shared-export conflict, and the combined code passed all 43 tests and the repository checks. I’m waiting for CI on that updated registry branch before merging it.

Agent

▸ exec gh run view 40803680384 -R carlosrivera/panas --log-failed

Input

gh run view 40803680384 -R carlosrivera/panas --log-failed

Output

apps/provider/src/provider.test.ts (17 tests | 1 failed)
Error: condition timed out

Agent

CI caught a timing-sensitive provider test: it allowed roughly 200 ms for several durable filesystem writes, and the Linux runner exceeded that budget. I’ll give the test a bounded CI-appropriate wait while keeping its concurrency assertions, then rerun the checks before merging.

Agent

▸ exec Edit apps/provider/src/provider.test.ts. Change the polling bound from 100 at...

Input

Edit apps/provider/src/provider.test.ts. Change the polling bound from 100 attempts at 2 ms to 300 attempts at 10 ms, then rerun the checks.

Output

null

Agent

▸ exec Poll the registry validation command

Input

Poll the registry validation command

Output

Test Files  7 passed | 2 skipped (9)
Tests  43 passed | 8 skipped (51)

Agent

▸ exec git add apps/provider/src/provider.test.ts git commit -m "Allow bounded CI di...

Input

git add apps/provider/src/provider.test.ts
git commit -m "Allow bounded CI disk latency in durable worker tests"
git push origin codex/issue-4-registry

Output

null

Agent

▸ exec gh pr checks 18 -R carlosrivera/panas --watch --interval 10

Input

gh pr checks 18 -R carlosrivera/panas --watch --interval 10

Output

null

Agent

▸ exec gh pr merge 18 -R carlosrivera/panas --squash --match-head-commit [verified h...

Input

gh pr merge 18 -R carlosrivera/panas --squash --match-head-commit [verified head]
git pull --ff-only origin main

Output

null

Agent

▸ exec Poll merge and verification command

Input

Poll merge and verification command

Output

PR 16 MERGED
PR 17 MERGED
PR 18 MERGED

Agent

Merged #16, #17, and #18. Issues #2–#4 are closed.

CI passed with all 43 tests. Local main is updated, and localhost:3333 is still running.

34 of 34 messages

Where the 787 million tokens went

I recovered 16 Codex sessions from my machine. They span the PRD, issue planning, implementation, review, tests, CI and deployment fixes, onboarding, and the hackathon demo and submission. The main session and three child sessions handled most of that activity. The child sessions started with team planning, web foundation, and registry assignments, then took on follow-up work. Their totals describe the whole sessions. The logs don't give me a clean per-task split.

Cached input accounted for about 99% of the recorded token volume. As an agent worked through a branch, later requests could reuse earlier context, including conversation and tool results. That context accounts for most of the token headline and most of the API estimate. OpenAI prompt caching

Recorded usage	Tokens	Estimated API cost
Cached input	777.2 million	$113.47
Uncached input	7.4 million	$18.72
Output	2.5 million	$30.17
Total before credits	787.1 million	About $162

I priced each recovered request using its logged model and the published standard API rates. GPT-6.1 Sol handled most of the work. Two later sessions used GPT-6.1 Terra. The estimate includes higher API rates for the 1,065 requests above 272,000 input tokens. The credits we received are outside this calculation. Sol pricing · Terra pricing

The 16 sessions span 47h 24m from first request to last recorded activity. At least one recorded agent turn was running for 17h 22m. Added across sessions, turns totaled 27h 53m because some ran in parallel. Turn durations include tool execution and waits.

If I ran the same workflow again, I'd keep the integration worktree and decide its checks while writing the PRD. For Panas, one check is what happens when a provider finishes a job but the buyer disconnects before receiving the result. The reconnect has to retrieve the existing result and receipt. A duplicate run or a second charge would mean the pieces failed together, even if each branch passed its own tests.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

← News 🤖 Ai 🏠 Home