How much can you build on an 11-hour flight?

August 27, 2026 7 min read

On Thursday, 13 August 2026, I took British Airways BA287 from London Heathrow to San Francisco. I also treated the flight as a bounded software session.

The short answer is that I got a lot done, but “11 hours of work” would be wrong. The flight was scheduled for 11 hours 10 minutes. My agent telemetry covers 8 hours 38 minutes, and a conservative interaction estimate comes to 5 hours 46 minutes. During that time, 27 pull requests merged across five repositories. A sixth repository got its initial commit.

That output depended on working internet, prepared repositories, authenticated tools, and several agents running in parallel. It is not a claim that anyone can board a long-haul flight and produce 27 PRs by typing faster.

The build list

I did not preserve a separate pre-flight checklist. The earliest named sessions and Linear-backed branches give me this reconstructed queue:

Ship a group of Mission Control usage, alerting, and dashboard improvements.
Build the first usable slices of a Premier League betting research platform.
Add ranking and synthesis experiments to Model Prompt Tests.
Finish packaging and prioritization work in the agent skills plugin.
Publish or finish several bshp articles and content changes.
Get a LinkedIn optimization CLI into a repository.

That distinction matters. This is the queue the durable records show, not a plan I can prove was written before boarding.

Flight and measurement window

BA287 was scheduled to leave LHR Terminal 5 at 14:30 BST and reach SFO’s International Terminal at 17:40 PDT. Public flight trackers disagree about the operational timestamps. FlightAware’s history lists 15:07 BST and 17:24 PDT. Plane Finder lists 14:38 BST and 17:40 PDT. Those services may be recording different events, such as gate movement and takeoff. I use the FlightAware pair for an airborne duration of 10 hours 17 minutes, while keeping the scheduled 11 hours 10 minutes as the trip’s advertised block.

Mission Control first recorded in-window agent activity at 2026-08-13T14:42:59Z, or 15:42:59 BST. The last substantive event was at 2026-08-13T23:21:42Z, or 16:21:42 PDT. That is an 8 hour 38 minute activity envelope, starting about 36 minutes after FlightAware’s departure timestamp and ending about an hour before its arrival timestamp.

An envelope is not focused work. Agents ran in parallel and continued while I was not touching the keyboard. I grouped recorded user-request events into work blocks, splitting on gaps longer than 15 minutes. Those blocks total 5 hours 46 minutes. It is an estimate from interaction logs, not a stopwatch reading.

What Mission Control recorded

I queried the Mission Control SQLite database on the Fedora / Strix Halo hub for the exact UTC window. I did not use the partial database on the laptop. I excluded Codex wait polling after the last substantive agent event from the work envelope.

Source	Sessions	Activity facts	Input	Output	Cache read	Cache write	Failures
Grok	27	7,217	8,179,072	1,084,110	279,396,224	0	74
Claude Code	6	628	1,672	230,003	30,193,848	2,041,128	0
OpenCode	8	380	21,900	6,055	2,019,250	0	6
Codex	1	22	0	0	0	0	0
Recorded total	42	8,247	8,202,644	1,320,168	311,609,322	2,041,128	80

“Activity facts” is Mission Control’s collector count. It includes messages, tool calls, and usage events. It is not a count of prompts, API requests, or independent tasks. Session counts can also include sessions that began before the flight and produced activity inside the window.

The token-bearing model rows were:

Model	Sessions	Input	Output	Cache read	Cache write
`grok-4.6-build`	23	6,997,972	1,003,963	252,998,656	0
`grok-4.5-build`	3	1,181,100	80,147	26,397,568	0
`claude-sonnet-5`	6	1,672	230,003	30,193,848	2,041,128
local Qwen 3.6 via OpenCode	8	21,900	6,055	2,019,250	0

Codex recorded one substantive session but no token events in this extract. I am treating that as a collection gap, not zero use. The failure column has the opposite problem: different collectors do not classify failures consistently, so it is useful for locating recorded errors but not comparing agent reliability.

Local inference was real, but not offline

The Fedora hub recorded 180 local inference requests during the exact work window:

Model	Requests	Prompt	Completion	Failed
Qwen 3.6 35B	174	1,156,169	28,215	0
Gemma 4 26B	6	8,572	3,853	0

The models ran on Strix Halo, not on the laptop tray table. From the aircraft, reaching that machine still depended on the in-flight connection and the private network path. “Local model” describes who owned the hardware. It does not mean the work was available offline in the cabin.

The same caveat applies to most completed work. GitHub pushes and merges, Linear state changes, hosted Grok and Claude requests, remote browser checks, and the Fedora model server all required connectivity. The repositories and agent clients were already present on the laptop, and several sessions had started before the measurement window, but the logs do not preserve a clean inventory of what was cloned, cached, or authenticated before boarding.

What shipped

Git history inside the measurement window contains 66 unique commits across the six repositories below. That figure includes feature commits, fixes, and squash merge commits, so it is evidence of the work trail rather than a productivity score.

Repository	Durable result	Merged PRs
Mission Control	Forecast cleanup, Consumption refactor, quota hardening, plan alerts, Grok plan collection, dashboard attention summary, exports, Runtime filters, and normalized usage windows	9
Betting intelligence platform	Repository bootstrap, fixtures, Polymarket discovery, bookmaker odds, historical results, a Poisson model, and an execution-aware value engine	7
Model Prompt Tests	Council notes, peer ranking, judge calibration, and chairman synthesis	4
bshp	Project screenshots and dates, Grok Imagine write-up, practical prompt-test article, and July usage report	4
Agent skills plugin	MCP metadata consistency, release packaging, and a Linear prioritization skill	3
LinkedIn Optimizer	Initial CLI commit	0
Total		27

The PR counts come from merge commits on the repositories’ main histories, not from counting every branch commit as shipped. The result was not 27 unrelated ideas invented in the air. Much of it was a prepared queue moving through implementation, review, fixes, tests, and merge with agents overlapping.

There was partial work too. Model Prompt Tests received commits for a DeepSeek V4 benchmark article late in the window, but it had not merged before the cutoff. The telemetry also contains sessions that were mainly status checks or ticket closure rather than new software.

What the records say about the cabin

They say less than I expected.

The continuous hosted-agent activity and successful GitHub and Linear operations prove that connectivity was available for substantial parts of the session. The records do not measure Wi-Fi latency, outages, seat, cabin, charging, battery level, thermals, meals, sleep, or tray-table space. I cannot reconstruct those details honestly from git or Mission Control, so I am leaving them unknown.

The inactivity gaps are visible. User-request activity breaks for about 29 minutes, 1 hour 25 minutes, 18 minutes, and 17 minutes between the main blocks. My notes fill in some of that context. I stopped for meals, and the longest gap included an internet black spot of about 1 hour 20 minutes. I was also travelling with my wife and our two children. Looking after them meant plenty of shorter interruptions throughout the flight.

The logs cannot assign every gap to one cause, and agents sometimes kept running while I was away from the keyboard. That is another reason the 5 hour 46 minute figure is an interaction estimate rather than a claim of uninterrupted focus.

Completed, partial, and blocked

Completed: 27 PRs merged across Mission Control, the betting platform, Model Prompt Tests, bshp, and the agent skills plugin. LinkedIn Optimizer got its initial commit. The work included product features, defect fixes, benchmark tooling, packaging, and four published site changes.

Partial: the DeepSeek V4 benchmark article had implementation and review-fix commits but no merge inside the window. Some long-running agent sessions crossed the flight boundaries, so only their in-window events belong to this measurement.

Blocked or unknowable: I cannot recover a written pre-flight checklist, exact cabin conditions, a reliable Wi-Fi outage log, or a true stopwatch total. Codex token collection was empty, and collector failure semantics differ by source. None of those gaps justify replacing missing evidence with a smooth story.

So, how much can you build?

On this flight, with the repositories ready and internet access to hosted agents, GitHub, Linear, and a home inference server, I moved 27 PRs through merge, made an initial commit in another project, and left one benchmark article in progress. The human interaction estimate was 5 hours 46 minutes inside an 8 hour 38 minute telemetry envelope.

That is a result for one prepared queue on one flight, with meal stops, an internet black spot, and two children to look after. It says more about parallel agent workflows and setup than about typing speed or uninterrupted focus. The practical answer is that a flight can be a useful delivery window when the work is already shaped and the services remain reachable. The logs are much less useful for proving comfort, attention, or whether doing this again would be a good idea.