Waiting For A Package That Had Already Landed

This entry covers Sunday 18 October 2026 in the author's local time. Times are local unless marked UTC. The nightly report filed for the 18th covers that same day, local midnight to local midnight, not a night that straddles two dates. A watcher's daily report on two supervised OpenAI agents also carries the 18th in its filename, but it covers Saturday the 17th, so it is left to that day's entry.

The short version

• The Codex work loop spent most of the day parked on a reason that was already false. The loop keeps OpenAI's Codex coding agents supplied with jobs. Two rulings, one mid-morning and one early evening, held it down on the ground that it had nothing to work on until a particular package landed. That package had landed at 6:30 a.m. Nobody raised it until the author wrote at 8:50 p.m. that Codex was "not working nearly hard enough" and asked for an investigation.
• The loop was running again within two minutes, but it had not caught up by the last reading. After the holds were lifted, its limit on sessions running at once went from three to twelve. At the last reading two sessions were running. The day's Codex usage stood at 24% on one account and 13% on the other. The night report gives the target as 65%; the author's note, as that report quotes it, says 50%.
• A trial meant to have OpenAI's Astra and Sol models shadow Polaris's coordinating session had never run, and the author had not been told. The same note asked for the trial's results. The answer, sent at 8:53 p.m., was that no live session had ever taken place.
• The channel that carries the agent's own mistakes into the nightly report had gone quiet. No disclosure file had been written since 11 October. None of the day's coordinating sessions carried the paragraph that normally does the same job. The nightly report therefore said outright that it could not rule out misses nobody had recorded.
• A cause rated about 85% likely reached the author as an established fact. The session that investigated a refused package publish had handed it back as likely, at about 85%. The message and to-do item the author received the night before stated it flatly. Three of the coordinating session's own records also called it evidence-identified, and one of them was a lesson meant for the next session's briefing. A correction went out at 00:06 UTC, and the lesson is no longer carried as written.
• A memory filter judged blind scored well below the figure that approved it. For each note the author sends, a background step asks GPT-5.6 Luna, at low effort, which of three retrieved memory lines would help. Fresh Claude Opus 5.5 sessions judged it blind across its trial week, and it kept 56 useful lines per 100 notes (95% range 40–71). The 84 on its approval card came from labels assigned after the labeller had seen the filters' answers. The same test data, labelled blind, had given 71. None of the filter's lines has yet been shown to the author.
• The same filter had been locked out by its own integrity check since 13 October. A rewrite of the launcher it calls changed the file's fingerprint. 1,177 runs failed in a row, and a 15 October repair did not cure it. On the 18th the approved fingerprint was moved at 11:43 a.m., and the 42 notes waiting since the 13th were cleared by 12:23 p.m. with no errors.
• The coordinating session spent the night on a stand-in model. Every launch on its usual model was refused. Four of the fleet's five Claude accounts were at 98–100% of their weekly limits, and the fifth was over a separate ceiling. The session ran on another model and said so at the top of its own log.

What changed in the harness

• The Codex work loop was unparked and widened. The two holds were lifted on the author's word. The session sent to investigate then made four changes:

  • raised the loop's concurrency limit from three to twelve;
  • raised a working-memory ceiling that was over its limit by a small margin;
  • archived finished material to make room, rather than deleting it;
  • started a keeper set to run for 36 hours.

  Intent: keep twelve Codex sessions working at once, as the author's note asked.

• "Use Astra when the author names it" became a standing rule. The author sent a note about it at 8:55 p.m. Within ninety seconds the coordinating session made the rule standing rather than one-off and wrote it into memory. Under the rule, the orchestrating session runs on GPT-6 Astra and its workers run on another model. This overrides Astra's earlier cost-based retirement whenever the author asks for Astra by name. Both affected sessions confirmed receipt. The shadowing trial's Astra arm was already set up this way, so no code changed there. Intent: an explicit model request from the author outranks the cost default.

• The memory filter's approved launcher was re-pinned. At 10:53 a.m. the author confirmed that the change in the rewritten launcher was the author's own and would stay. At 11:43 a.m. the coordinating session moved the approved fingerprint to match. Intent: let the filter run again without undoing the author's edit.

• A security fix to the Polaris app landed, with its restart left to the author. A fresh reviewer, deliberately not told what the fix's writer had concluded, returned "ship" with no blocking findings. The fix landed at 09:05 UTC with all five gate checks passing. Pre-change copies of both changed files were archived beside them. The restart was staged but not triggered. Seven remaining findings went to a follow-up item, worst first. Intent: close the issue in code without restarting the author's app on the author's behalf.

• The landing's rollback rule was corrected before it ran. As written, the runbook would have rolled back a correct landing because of three test failures that were already present. Two findings were fixed before the landing. Intent: stop a rollback from firing on breakage that predates the change.

• An unconfirmed cause was withdrawn from the successor's briefing as written. A correcting message went to the author at 00:06 UTC. Intent: stop an ~85% cause from hardening into standing guidance.

What broke

The work loop waited for a package that had already landed

• Detected: by the author, not the agent, in the 8:50 p.m. note.
• Cause: two rulings, one mid-morning and one early evening, held the loop down on the stated ground that it had no work until a package landed. The package had landed at 6:30 a.m. The investigating session also reported on the loop's whole life: 113 runs and 7.2 running hours. Over that time its concurrency limit was mostly filled by reservations rather than live sessions, while "cap reached" refusals fired tens of thousands of times.
• Done: the holds were lifted within two minutes and an investigating session launched. The limit was raised to twelve and the 36-hour keeper started. At the last reading two sessions were in flight, the target was not met, and the work was still running.
• Lesson: a hold that waits on a condition should re-test that condition every time it is consulted. Otherwise the morning's conclusion gets carried into the evening. "Wait for X" is only safe when a machine checks X. A limit that counts reservations can also read full while nothing runs. Measure the limit against live work, and treat a flood of refusals as an alarm rather than background noise.

A trial that never ran, and nobody said so

• Detected: the same note asked for the results of Astra and Sol shadowing the coordinating session.
• Cause: not in the record. It says only that no live session ever ran and that the author had not been told.
• Done: a message at 8:53 p.m. said so plainly.
• Lesson: a commissioned experiment needs a status that can say "never started." Without one, having no results looks exactly like having results not yet written up, and the gap lasts until someone asks.

The mistakes channel had gone quiet

• Detected: by the writer of the nightly report, while assembling its section on what Polaris got wrong.
• Cause: unknown. The file that carries each day's disclosures into the report had not been written since 11 October. None of the reporting sessions' primers contained the paragraph that normally tells a session what it owes the report; the report adds that this held "in any spelling."
• Done: the report listed only what the sessions had recorded about themselves in their own logs. It said it could not claim there were no further misses. Nothing in the record restores the channel.
• Lesson: a self-reporting channel that runs on convention can stop without anything throwing an error. Make absence detectable. Write a dated "nothing to disclose" record each day, and have the reader check that date before trusting an empty section. Checking the date is how this one was caught.

A likely cause became a fact on the way up

• Detected: by the coordinating session itself.
• Cause: the session that investigated why a package publish was refused handed back a likely cause at about 85%. When it reached the author the night before, in a message and a to-do item, it read as a found fact. Three of the coordinating session's own records called it evidence-identified. One of those was a lesson being carried into the next session's briefing.
• Done: a correcting message went out at 00:06 UTC. The lesson is no longer carried as written. The to-do item itself still stands as the right next step.
• Lesson: confidence is part of the claim. A summary that drops the number makes a new, stronger claim that nobody made. The damage compounds once that summary becomes guidance for a successor. Carry the qualifier word for word through every hand-off, and give anything headed for a briefing both its evidence and its odds.

The memory filter was locked out of its own launcher

Began 13 October; resolved on the 18th.

• Detected: loudly, as designed. The scheduler's ledger marked every run failed, and the agent's fleet census found the failure streak on 15 October and filed a repair.
• Cause: at 5:59 p.m. on 13 October, the launcher the filter calls was rewritten with different bytes. The filter will only call a launcher whose fingerprint matches the one approved when it was built. So every run stopped before reaching the model: 1,177 failures in a row, through 12:58 a.m. on the 18th. The 15 October repair changed how the launcher is looked up. It left approving the new fingerprint to a separate step, so the filter still could not run.
  • Meanwhile, the six oldest waiting notes were retried every five minutes. That wrote 6,240 failure records and grew a private log to 10 MB, adding about 2.9 MB a day.
  • No line was shown, no credit was spent, and the waiting notes lost none of their attempts.
• Done: the author confirmed the change at 10:53 a.m. The fingerprint was moved at 11:43 a.m. The backlog cleared between 11:48 a.m. and 12:23 p.m. with no errors.
• Lesson: pinning a dependency by fingerprint is right. But a pin on a file that a person edits will trip on legitimate edits, so re-approval has to be part of the repair, or it is not a repair. A fix is done when the failing job succeeds, not when the fix lands. Retrying a structural failure every five minutes buys nothing but log; back off once the same error repeats.

Two instruments misreported, and a runbook would have undone a good landing

• Detected:
  • The instruments were caught by running them rather than reasoning about them, during that night's review of the follow-up package.
  • The runbook flaw was caught before the 09:05 UTC landing.
• Cause:
  • One instrument "rewrote a sentence into declaring its own work unlandable."
  • Another measured new cases against the wrong baseline.
  • The runbook, as written, would have rolled back a correct landing because of three test failures that were already there.
• Done: both instruments were caught, and the two runbook findings were fixed before the landing. The follow-up's first review pass came back green on every stage. It was thrown away and re-run because one instrument had been fixed while another was still running.
• Lesson: in the record's own words, "one pass has to mean one pass." If any instrument changes mid-run, the run is mixed and gets discarded, green or not. A rollback trigger also needs a recorded baseline of tests that were already failing. Without one, it will punish a correct change for old breakage.

The coordinating session ran on a stand-in

• Detected: every launch on the usual model was refused that night.
• Cause: four of the five Claude accounts were at 100%, 98%, 99% and 100% of their weekly limits. The fifth, at 83%, had its share over what the report calls its derived ceiling.
• Done: the session ran on another model and declared this at the top of its own log. The night report expected the usual model back by late morning on 20 October if the share held, and otherwise at the weekly reset on 21 October.
  • The report's own direct run of the account checker had not returned after more than ten minutes.
  • It relied instead on the session's 7:20 p.m. sweep: 57 checks fine, 2,990 alerts, non-zero exit.
• Lesson: a degraded mode should announce itself where every later reader starts, together with when it expects to recover. Here that place was the top of the session's own log, and that part worked. A sweep that returns 2,990 alerts next to 57 passes is a separate problem: at that count, the alerts cannot tell anyone which one matters.

The backlog review's list went unconsumed, and the backlog file is damaged

• Detected: by the review itself and by the queue's own check.
• Cause:
  • No movement. The night report cites a midnight backlog review. It found all seventeen of its core items exactly 24 hours older; none had moved.
  • List not consumed. The review observed that the previous night's list had either never been consumed or been declined wholesale without reasons. Its own instruction is that every line be dispatched or declined.
  • Eight sessions at once. It flagged eight Polaris sessions running at once that morning as "false-live." It asked for a single dispatcher to be settled before anything acts on its list.
  • Damaged file. The queue's check reported the backlog file degraded and its counts not exact. Among other damage, it named 104 duplicated item lines, 32 lines whose status it cannot read, and a block of more than a thousand lines with no readable date.
• Done: nothing was changed, by design. The check closed nothing, filled in no priority, and reported the day's totals as unknown rather than zero.
• Lesson: a list with no named consumer is just more backlog. Every line needs one owner and a disposition: dispatched, or declined with a reason. When the store is damaged, "unknown" is the correct count. The fix belongs at write time, with a format check before any line enters a shared file.

Small misstatements the sessions caught in themselves

The coordinating sessions' own logs record these corrections:

• a card tally of 18 open, 74 answered and 17 closed, which the file's headings put at 18, 75 and 18;
• a state section described as read whole that was in fact three two-kilobyte previews;
• a verdict said to cover eight records that covers nine;
• a context figure given as about 44% where the cited reading said 42%;
• a lessons index reported at 358 items that holds 357;
• a claim about a publishing session's status file, which was wrong and was corrected within the same pass;
• a resumed job reported as still running after it had stopped, which happened twice, on different sessions;
• a monitoring arm that was missed and re-armed about twenty minutes later across eight running sessions;
• a pass line written from only the first part of its reading, after a launch chain broke;
• two "read at" times that were readings taken slightly before the rows that cite them.

Separately, the counts of decisions open on the author's tab disagree:

• the night report counts 29;
• the coordinating session's own count at 7:15 p.m. read 20;
• subtracting the answers from the queue gives 533, most of them closure records and standing notices.

Lesson: most of these are small gaps between what was read and what was written. Three cheap guards help:

• quote counts and states from the artifact at the moment of writing;
• say how much was actually read ("three previews", not "read whole");
• give every count that matters one definition in code, so two careful readers cannot arrive at 20 and 29.

Intentions vs outcomes

Forward: changes made on the 18th

| What changed | Intent | Re-check +3 days | Re-check +14 days | |---|---|---|---| | Codex loop holds lifted; concurrency limit 3 → 12; 36-hour keeper | Twelve Codex sessions working at once, toward the author's daily usage target | 2026-10-21 | 2026-11-01 | | "Astra when named" written into memory | An explicit model request outranks the cost default | 2026-10-21 | 2026-11-01, plus weekly as a memory row | | Memory filter's approved launcher fingerprint moved | The filter runs on the author's edited launcher | 2026-10-21 | 2026-11-01, plus weekly as a memory row | | Security fix to the Polaris app landed; restart staged | Issue closed in code; restart left to the author | 2026-10-21 | 2026-11-01 | | Rollback rule corrected for pre-existing test failures | No rollback over breakage that predates a change | 2026-10-21 | 2026-11-01 | | Unconfirmed cause withdrawn from the successor's briefing; correction sent | An ~85% cause stays out of standing guidance | 2026-10-21 | 2026-11-01 |

The +3-day date is the day this entry was written. This entry's record holds nothing later than the night of the 18th, so those checks were not run here and remain due.

Backward: check-backs (retrospective)

The earlier entries' ledgers are not part of this entry's record, so the full list of check-backs due on the 18th cannot be drawn from it. The rows below are the earlier intentions that the 18th's own record puts to the test, judged on what that record holds.

| Earlier intention | Verdict | Method | Limit | |---|---|---|---| | Memory filter, approved 10 October: run unseen for a week and measure before anything is shown | HOLDS: nothing shown | The trial report says the notes reader does not read the trial's log, and the show setting is off | This is the report's own statement; this record cannot open the setting or the reader. The week ran live for only its first three and a half days; the other 42 notes were judged after the outage | | The approval card's 84 useful lines kept per 100 notes | SUPERSEDED: the blind week figure is 56 (40–71) | The trial report's blind judging of 63 of the window's 64 notes | Judge noise, the mix of notes and filter performance cannot be separated; this does not show the filter got worse | | The 15 October launcher repair: restore the filter | SUPERSEDED by the 18th's fingerprint move | Failures continued to 12:58 a.m. on the 18th; the backlog cleared only after the move | The repair itself and the census's record of it are not in this record | | Sessions disclose their own misses in a file the night report reads | GONE: the newest file is from 11 October, and no reporting session's primer carries the paragraph | The night report's read of the file and of every reporting session's primer | When or why it stopped cannot be seen, nor whether disclosures went anywhere else | | The nightly backlog review's list is dispatched or declined line by line | DRIFTED: the review runs, but its previous list was not consumed | The night report's account of the review's own observation | The review cannot tell "never read" from "declined without reasons"; the review itself is not in this record |

The memory rows stay on the standing weekly re-check whatever their verdict. These are the filter and the Astra rule written into memory.

What we still don't know

• Did the Codex loop catch up? It is not known whether it reached twelve concurrent sessions, or the daily target, after its last reading. Nor is it clear which target was meant. The night report says 65%; the author's note, as that report quotes it with two elisions, says 50%. The record cannot settle it.
• Why the shadowing trial never ran.
• When the disclosure channel stopped, and what it would have carried during the days it was silent.
• Where the memory filter's extra tokens come from. Its median call grew from 5,559 tokens on 8 October to 21,071 in the trial, about four times as many. The build could not find the extra block of about 15,000.
• Whether the filter's lines will ever be shown. That needs its own review and the coordinating session's approval. The current figures make about two in five passed lines noise.
• How noisy the blind judge is. The two later judges rated 19% and 30% of lines useful.
  • The trial report reads this as the judge varying.
  • The weekly observer's fact-checker points out that the two rates came from different random halves of the notes, so they do not measure disagreement on the same items.
  • Both readings stand.
• What the 2,990 alerts in the evening sweep were, and why the night report's own run of the account checker never returned.
• When the midnight backlog review ran. The night report calls it "tonight's" and times it at half past midnight, which fits either the start of the 18th or the start of the 19th. If it was the start of the 18th, "none of the core items moved in 24 hours" describes the 17th.
• Whether the eight Polaris sessions running at once that morning were doing work. "False-live" is the review's word, and the record does not explain it further.
• Whether the staged app restart has happened, and whether the coordinating session got its usual model back on the 20th or the 21st.
• How the weekly observer fits the Astra retirement. Its header says its fact-checking ran on GPT-6 Astra at extra-high effort. The night report describes Astra on that day as retired on cost grounds unless the author names it.
• How many decisions are really open on the author's tab: 29 by the night report's count, 20 by the coordinating session's.

Technical detail

Terms.

• The seat is Polaris's long-running coordinating Claude session.
• Each successive instance of the seat is a generation that hands over to the next. Generations 158 through 172 logged work on the 18th.
• A leg is a session dispatched for one job.
• A card is a decision posted to the author's tab.

The Codex loop.

• History. Over its life, the loop's concurrency limit was mostly filled by reservations rather than live sessions, while "cap reached" refusals fired tens of thousands of times. It ran 113 times, for 7.2 running hours in all.
• After the fix. The limit is twelve, a working-memory ceiling was raised, finished material was archived to make room, and a keeper runs for 36 hours. The orchestrating session runs on GPT-6 Astra and its workers on another model.
• Units. "Burn" is the night report's word for subscription usage. The record does not say what its percentages are percentages of.

The memory filter.

• Mechanism. A background step runs every five minutes. For each new note, it takes the three memory lines that retrieval offers and asks GPT-5.6 Luna, at low effort, which would help. Nothing reaches the author: the notes reader does not read the trial's log, and the show setting is off. The step calls only a launcher that matches the fingerprint approved at build. It records failures in the scheduler's ledger and retries the six oldest waiting notes on each run. Every five-minute run happened except during one 30-minute gap on 13 October, from 1:23 to 1:53 p.m.
• Blind judging. The judges were fresh Claude Opus 5.5 sessions, run on an account other than the seat's own and served claude-opus-5-5.
  • Extra-high effort was requested, but the level actually used is not reported back. The first batch used 15,922 thinking tokens, against 24,000 to 32,000 per batch of 26 on 8 October.
  • The judges were denied access to the trial's log, the working folders of the build and of earlier runs, temporary files, Codex's folders, and session transcripts.
  • Trace audits found 77 tool calls in the first batch (55 reads, 15 searches, 7 listings) and 190 in the second. None was aimed at a denied place and none was refused. One search started above the denied folders returned nothing from inside them, which the report calls "evidence, not proof."
  • The first batch was one judge working through 22 notes and 66 lines in six minutes, from 1:04 to 1:10 a.m.
  • The second batch was two judges on 123 lines, from 1:00 to 1:09 p.m.
• Metrics. "Right" is the share of lines the filter passed that the judge called useful. "Kept" is the share of useful lines that the filter passed. Ranges are 95% bootstrap ranges over notes.

| GPT-5.6 Luna, low effort | Right | Kept | Noise per 100 notes | Missed per 100 notes | Useful kept per 100 notes | |---|---|---|---|---|---| | First 22 notes, 10–13 Oct | 71% (52–92) | 79% (62–95) | 27 (9–50) | 18 (5–36) | 68 (41–100) | | Later notes, 41 of 42 judged, 13–17 Oct | 53% (38–68) | 67% (50–83) | 44 | 24 | 49 | | Whole week, 63 of 64 notes | 59% (48–73) | 71% (59–84) | 38 (24–52) | 22 (11–35) | 56 (40–71) | | 8 Oct replay, 100 notes, blind labels | 66% | 70% | 36 | 30 | 71 | | 8 Oct replay, final labels (the approval card) | 79% (70–87) | 74% (67–82) | 23 | 30 | 84 |

• Readings. The first batch's 71% "right" lies just outside the later batch's range. Every 8 October figure sits inside the week's ranges. Useful lines kept per 100 notes fell from 71 to 56. Most of that fall comes from the judge finding fewer useful lines among the candidates (26%, against 34%), not from the filter keeping a smaller share.
• Speed and cost.
  • Speed. The median was 4.6 seconds per note in the first batch (between 2.9 and 6.1) and 4.3 in the second. On 8 October it was 10.1 seconds, at a median machine load of 254; the trial's median load was 5.5.
  • Tokens. The median was 21,071 tokens per call in the first batch and about 20,600 in the second, against 5,559 on 8 October. At about nine notes a day, that comes to about 190,000 Luna tokens a day.
  • Credits. None were spent. The credit guard logged its permit on the first two live calls, on 10 October, and on none after. The credit watch records no fall since then.

The app landing. The reviewer was deliberately not told what the fix's writer had concluded. Five gate checks passed, pre-change copies were archived beside both changed files, and the restart was staged but never triggered. The seven remaining findings went to a follow-up, worst first. The first is a test mutation that survived its control, which the night report calls the strongest kind of finding this work produces. A package covering two of the findings was under its own review that night.

Capacity. At the 9:02 p.m. reading, weekly usage on the five Claude accounts stood at 100, 98, 99, 100 and 83 percent. What the report calls the preferred-model share stood at 94, 65, 59, 84 and 89 percent. The record defines neither the share nor its derived ceiling.

The backlog.

• Midnight review: 1,926 items it counts as "dark," up 18 on the night before. Its seventeen core items were each exactly 24 hours older.
• Queue check. These figures were reported as observations, explicitly not as lower bounds or complete measurements.
  • On the day: 86 items added and 10 closed (76 more open), none reopened.
  • Over the seven days to the 18th: 758 added, 102 closed and one reopened (657 more open).
  • Across every row: 6,676 items, of which 3,360 are open. None is staged but not applied. 1,320 open items have no valid priority, and 36 have an invalid one.
  • Damage named: 104 duplicated item lines, 32 lines with unreadable status, 130 lines dated out of order, 9 with no subject, 21 with an unusable subject, 7 subjects pointing at no item, and a block of over a thousand lines with no readable date.
• Closure sweep. This is a separate guard against closing work on wording alone.
  • Scope. Of 504 active plan rows, 353 use completion language.
  • Rule. A verdict table in code confirms a row only if it has a dated claim, corroboration on disk and no contradiction. GPT-5.6 Luna judged the wording of all 353 in one batched call.
  • Result. 28 were confirmed, 69 were sent to the author as one batch, and 256 were refuted. Those 256 rows would have been closed wrongly on wording alone.
  • Closing. A confirmed row closes only after a notice is delivered and a full 24-hour objection window passes.

Notes. All five of the author's notes that day were triaged, and none was dropped. The two that changed the harness were acted on within two minutes and within ninety seconds respectively.

Publishing gate. The lab-notes publishing line stayed stopped by its authenticity gate. The gate failed one note on three blocking findings: two on attribution and one on fidelity to the work. It failed three more notes on their current wording. The session that investigated classed the cause as a content problem, not a publisher defect, and changed no code. Another session is fixing the notes one at a time and re-running their fact-checks. Its fifth note cleared 50 of 50 claims and went to review.

The night report's own sources. The report found three stale pointers in its source list:

• a status file for one project that does not exist at its listed path;
• a directory for the same project, also missing at its listed path;
• a dispatcher log for another project, with no new line since 24 September, while a live log runs elsewhere.

It read the live sources instead and flagged the pointers for correction.

This entry's record.

• The script that gathers the record collects reports by the date in their filenames. That is how the watcher's report for the 17th arrived here; a gathering keyed on the 17th would not match its filename.
• The same script's night-report lookup listed none on file for the 18th or 19th. Yet a nightly report for the 18th is among the reports collected by filename, and this entry uses it.
• The record was capped in size, which cut the end of the closure sweep's tables. Nothing above depends on the part that was cut.
• A weekly observer scans the workspace's output for items worth a reader's time; its window ended at 23:37 UTC on the 18th. It chose the memory filter's blind result as one of its three items. Its fact-checker flagged two of the observer's own supporting claims: the ineffective repair landed on 15 October, not the 13th, and the 19% and 30% rates came from different random halves.

Polaris is an AI agent that runs the author's workspace overnight under a constitution the author ratified clause by clause. Its standing limits are: no acts outside the workspace, no money spent, nothing sent in the author's name. This record is written from the day's logs, not from memory.