DEV Community: Yurii Tor

Carry AI Coding Context Between Sessions with a Markdown Handoff

Yurii Tor — Thu, 08 Oct 2026 18:21:49 +0000

An AI coding session can end with a working patch and still be hard to continue. The code shows what changed. The conversation may contain the rest: why an approach was rejected, which command failed, what a test actually verified, and where the investigation stopped.

That context matters when you hand work to another person, start a fresh task, or switch tools.

Session Exporter is an open-source plugin from Tor Production that turns the accessible context of a ChatGPT or Codex conversation into a Markdown handoff. It packages instructions as a skill, with no MCP server or account connection of its own.

Its default scope includes the complete accessible transcript, organized context, and an integrity report. The useful part is keeping decisions connected to the evidence behind them.

Preserve the decision and the evidence

A handoff should let the next reader answer four questions:

What are we trying to do? The goal, constraints, and current state.
Why did we choose this approach? Decisions and relevant failed attempts.
What was verified? Files, commands, test results, or sources that support the conclusion.
What remains open? Unfinished work, missing information, and the next useful step.

Session Exporter's structure adapts to the work. A debugging session may need repository state and test output; a research session may need sources and unresolved questions. Inapplicable sections are omitted.

The transcript remains useful when the handoff needs checking. A note that says “tests passed” is much easier to assess when the underlying command and visible result are preserved.

A small example

Here is a conceptual excerpt from a queue-debugging handoff. It illustrates the information worth preserving; it is not an actual plugin export or a verified test result.

Goal: prevent completion after a worker's lease expires.
Decision: check ownership and expiry within the write transaction.
Verified: a deterministic test covers expiry while waiting for a lock.
Failed attempt: a sleep-based test was flaky in CI.
Next step: add the regression case to the acceptance suite.
Missing: behavior under production traffic has not been measured.

The next session now has a specific place to resume. It also knows which conclusion still needs evidence.

A real export should preserve the commands, results, and wording available in the session. If a detail cannot be retrieved, the document should mark that gap.

Try it in a Codex task

Open the public Plugins Directory through the project's installation guide, find Session Exporter by Tor Production, and install it.

Start a new Codex task after installation so the skill is available. This follows the documented plugin installation flow.

When that task is ready for a handoff, ask:

Use $session-exporter to export this entire conversation
to Markdown for handoff.

The default filename combines session_export, a timestamp, and a short context suffix. Review the file, then supply it to the next person or tool that can read Markdown. Include access to the relevant repository or files when continuing the work requires them.

The README also documents a Git marketplace installation route and a copy-paste fallback for chats where the installed skill is unavailable.

Know what the file can carry

The export can only contain information the current session can access. An earlier message that is no longer retrievable remains a gap, even if it once existed in the conversation. The integrity report records unavailable material, omissions, and redactions.

The public skill instructions exclude hidden system instructions and private chain-of-thought, and require redaction of visible secrets. Review the generated file before sharing it: that requirement is not a guarantee of perfect secret detection.

The plugin adds no analytics, automatic upload, or synchronization. The export stays in the current environment unless you send it elsewhere. A Markdown handoff also does not transfer permissions or give the receiving tool access to your accounts.

Use it where continuity matters

This approach is useful for a paused investigation, a review passed to another agent, or a project that spans several sessions. A short summary may be enough for a small, self-contained task.

The practical check is: can the next reader identify what was verified and what to do next? If a claim lacks evidence, add the source or mark it unresolved.

The repository contains the implementation, installation options, and full export instructions.

AI disclosure: This article was drafted and edited with AI using the project's documentation. The debugging excerpt is illustrative. No measured time, token, or quota savings are claimed.

What 216 Coding Attempts Revealed About Sol 6.1's Value

Yurii Tor — Tue, 06 Oct 2026 18:38:30 +0000

TL;DR

Sol 6.1 Low averaged $0.101 per attempt, scored 100/100 on the main checks, and delivered accepted code in 12/12 attempts.

On the transaction task, its added tests caught 4/6 and 5/6 seeded defects. Medium improved that to 5/6 and 6/6 at 9.9% more estimated cost.

These are results from six specified tasks. Dollars are frozen API-equivalent estimates.

I compared Sol 5.6, Sol 6, and Sol 6.1 in a benchmark published through my Tor Production project. The most useful differences appeared when I looked beyond passing scores: what did the generated tests catch, and what did that capability cost?

The public repository contains the stand, task contracts, evaluators, submitted code, results, and English report.

What I compared

The setup used three models × six reasoning efforts × six Python tasks × two attempts = 216 attempts. The efforts were Low, Medium, High, Xhigh, Max, and Ultra.

The tasks covered:

Interval merging.
A TTL/LRU cache.
A concurrent dependency-graph executor.
A reservation service with SQLite, HTTP, and CLI components.
An exact constrained optimizer.
A serializable MVCC transaction engine with recovery.

Each attempt started with a fresh scaffold and session. Agents could run supplied tests and add tests, but received no hidden-test feedback or grading retry. The archive retains failed outcomes: 214 attempts completed; 213 were accepted deliveries.

1. Low effort offered strong delivery value

Sixteen of the 18 model-and-effort settings reached 100/100 on the main functional score. That ceiling leaves little room for a useful quality ranking from the main score alone.

At Low effort, the comparison looked like this:

Model	Mean estimate / attempt	Main score	Accepted deliveries
Sol 5.6	$0.318	100/100	12/12
Sol 6	$0.125	99.44/100	11/12
Sol 6.1	$0.101	100/100	12/12

Sol 6.1 Low was the cheapest fully observed setting with a perfect main score and all 12 deliveries accepted.

The chart covers all efforts; the table isolates Low.

A saved implementation's grade and a completed delivery are separate outcomes. For example, a Sol 6 Max reservation attempt timed out although its saved code passed the main checks. It reduced the accepted-delivery rate, while retaining its passing functional score.

2. Generated tests separated implementations that all passed

All 36 transaction implementations passed the main evaluator. Their added tests were much less alike.

I evaluated those tests against six fixed defects injected into a correct reference implementation: snapshot-read errors, write skew, missed phantoms, forgotten reads after rollback, recovery-version gaps, and checkpoint aliasing.

Model, Low effort	Mean estimate / MVCC attempt	Defects caught: run 1	Run 2
Sol 5.6	$0.305	0/6	0/6
Sol 6	$0.137	3/6	0/6
Sol 6.1	$0.129	4/6	5/6

The three zero results mean those attempts had no recognized candidate-added tests. The implementations still passed their main checks; the zeros apply to this test-strength criterion.

A usable mutation result requires the added tests to pass on both the candidate and the positive reference. Only executed assertion failures count as detected defects. Incompatible or incomplete evidence is reported as N/A, rather than averaged into a setting's score.

What additional effort bought on this task

For Sol 6.1:

Low: 9/12 defect opportunities detected across two runs, at about $0.129 per attempt.
Medium: 11/12, at $0.142 — a 9.9% estimated cost increase.
High: 12/12, at $0.203. This was the cheapest setting in the archive to catch all six defects in both runs.

This makes the effort choice concrete: how much additional test sensitivity is useful for your task? The result applies to this declared defect set; it does not establish that higher effort always catches more real-world bugs.

3. The cost advantage included both pricing and usage differences

Across 70 matched task/effort/repetition observations per model, Sol 6.1's API-equivalent total was 28.9% lower than Sol 6's. The same two partial-cost keys were excluded from both models.

The pricing bridge shows three steps:

Sol 6 usage at Sol 6 rates: $19.71.
Exactly that usage repriced at Sol 6.1 rates: $16.68.
Observed Sol 6.1 usage at Sol 6.1 rates: $14.02.

The middle step changes the cached-input tariff while holding usage constant. The final step reflects the observed usage difference under a common tariff. This order-dependent comparison does not provide causal proof of intrinsic model efficiency.

How I would use these results

Sol 6.1 showed strong value in this suite, especially at Low. For the specified transaction task, Medium bought a measurable improvement in generated-test sensitivity at a modest estimated cost increase.

When passing scores reach a ceiling, inspect another outcome that matters to your work. Here, tests that detect declared defects offered more useful separation than the aggregate main score.

Keep the scope in view:

Costs are estimates from observed Codex tokens at a frozen Standard API price schedule; they are not subscription bills or a direct API experiment.
Agent elapsed time includes reasoning, tools, and self-tests. Generated-code runtime is measured separately.
Six tasks and two attempts per configuration cannot establish a general intelligence ranking. Manual design review remains pending.

The findings and derivations make every comparison inspectable.

What task or defect would you add to make the next comparison more useful?

Passing Tests, Expired SQLite Leases: An AI Coding Benchmark

Yurii Tor — Thu, 01 Oct 2026 17:03:01 +0000

A background job can pass its acceptance suite and still have a concurrency bug at the exact point where it waits for the database. In a small experiment I ran on a durable TypeScript and SQLite reminder queue, both Astra + Luna implementations passed the original checks. A later audit found that both could make lease decisions using a timestamp sampled before SQLite granted the write lock.

This is a narrow engineering result. A useful review question is whether a time-sensitive decision happens before or after a transaction wait.

What the experiment measured

The task was to build a durable reminder queue that survives restarts, retries failed deliveries, and handles competing workers. I compared four configurations, with two measured runs per configuration. In paired configurations, Astra planned and reviewed while another model implemented. The table below focuses on Astra solo and Astra + Luna because that is where the cost/time comparison and shared defect appeared.

Configuration	Original acceptance	Seven later diagnostic checks	Mean fixed-rate estimate per attempt	Mean elapsed time
Astra solo	2/2 runs accepted	7/7 and 7/7	38.681850 units	543.302 s
Astra + Luna	2/2 runs accepted	4/7 and 4/7	20.384872 units	795.081 s

The fixed-rate token-cost estimate for Astra + Luna was 47.3% lower than Astra solo; elapsed time was 46.3% longer. Those units are an estimate from token counts multiplied by fixed historical rates. They are not a bill, a measured subscription deduction, or a subscription-quota saving.

The diagnostic audit was retrospective. Three of the seven checks probe the same clock-after-lock defect. The 4/7 result is limited evidence about these two implementations on this one task.

How a clock read becomes stale

A lease usually combines an owner token with an expiration time. A worker claims a job, performs work, then tries to complete or fail it. The database must serialize claims and state transitions so two workers cannot act on the same live lease.

SQLite can make a writer wait for another transaction. If application code reads the clock before requesting the write lock, the value can age during that wait. A simplified, illustrative ordering looks like this:

const now = clock.now();
await beginImmediateTransaction(db); // may wait for another writer
await claimDueJob(db, now);
await commit(db);

If the lock arrives after the previous lease deadline, this code can still evaluate the claim using the earlier time. Depending on the queue's rules, it may create a lease that is already expired, or accept a completion/failure based on ownership that expired while the transaction waited.

For a lock-protected decision, acquire the transaction first and sample time only after the write lock is held:

await beginImmediateTransaction(db);
const now = clock.now();
await claimDueJob(db, now);
await commit(db);

Treat the snippet as an ordering illustration and adapt it to the real transaction API. Keep the time comparison and relevant state update inside the same transaction, preserve owner-token checks, and account for clock semantics. Sampling after lock acquisition removes this particular pre-wait staleness; it does not prove that every timing or lease bug is solved.

Make the wait deterministic in a test

The ORCH-1 audit exercised this boundary with real, independent SQLite connections and a controlled clock. The simplified outline below follows that audit; adapt the barriers and connection setup to your own queue:

Open two independent SQLite connections.
On connection A, begin an immediate write transaction and hold it behind a test barrier.
Start a claim operation on connection B and observe that it reaches the lock boundary.
Advance an injected clock beyond the relevant lease deadline while B is waiting.
Release A, let B continue, and assert that the resulting lease and ownership checks use the post-wait time.
Repeat the same shape for claim, complete, and fail paths.

In the public audit, the clock advanced from 0 to 10 while the operation waited. With a lease duration of 5, a fresh claim should end at 15. Completion and failure should reject ownership that expired at 5. Both Astra + Luna runs instead returned a claim ending at 5 and accepted expired ownership.

The barrier and controllable clock matter. A timing test based only on real sleeps can be flaky and may never hit the boundary in CI. The assertions should distinguish the operations: a new claim may reclaim work after its prior lease expires, but should calculate the new lease from time sampled after lock acquisition; complete and fail should verify the owner token and reject expired ownership using current post-lock time. Assert those state invariants, not an incidental number of milliseconds.

In this experiment, both paired implementations read the clock before waiting for SQLite's write lock. Three probes for claim, complete, and fail each exposed that same timing defect. Astra's review did catch other concrete issues: it found string-preservation problems in SQLite storage, which Luna then fixed. The review still missed the lock-wait boundary, and the supplied tests did not exercise it.

What the numbers do and do not say

The cost/time tradeoff is real for these measured attempts, but it should not be read as a ranking of models. The test used one TypeScript/SQLite task and two runs per setup. There was no Sol-only control. Before the Astra + Luna runs, the CLI version and executor-selection protocol changed. The additional audit was designed after inspecting the implementations, and its three clock checks share one defect class.

Astra's planning and review accounted for 95.6% of the paired workflow's fixed-rate estimate in these runs. Even a hypothetical free executor would remove only the remaining 4.4% if all observed work stayed fixed. That is a useful reminder to measure the whole workflow, not just the executor price. It is not a general statement about orchestration economics.

For a production queue, I would put lock-wait cases in the acceptance suite from the start, test through separate database connections, and make the clock controllable. I would also keep the benchmark's acceptance result separate from the later diagnostic result so a retrospective test does not rewrite what was originally accepted.

The next comparison should add a Sol-only control under the same client and protocol, use more tasks, and freeze the expanded checks before running the candidates.

Sources

AI-generated draft: AI prepared this article from my published report and project notes. The linked sources contain the experiment results and methodology; this article makes no additional benchmark claims.