Building the Machine That Drives Software to Release Candidate

A few days ago I looked at my ChatGPT usage telemetry and stopped at one number:

6.7 billion lifetime tokens.

The same telemetry showed a peak of 239.6 million tokens, a longest task of almost 84 hours, and a longest continuous streak of 13 days.

Those numbers are interesting, but by themselves they prove almost nothing.

The useful question is not how many tokens I consumed.

The useful question is:

This article is deliberately a rough analysis.

It is not a scientific benchmark, not a controlled experiment, and not an accounting statement. I do not have perfect historical attribution of cached input, uncached input, visible output, reasoning, model mix, or engineering versus non-engineering activity.

I use ChatGPT for software development, research, writing, browser work, architecture, technical investigation, and occasional personal tasks. All of that exists in the telemetry.

So there is noise.

But the difference between the relevant economic scales is large enough that even a substantial error margin remains informative.

More importantly, the telemetry captures a transition in the way I work as an engineer.

Before discussing autonomy, one boundary needs to be explicit.

This is not a claim about autonomous commercial production deployment.

I am not arguing that an agent should be allowed to modify a production system, merge arbitrary changes, deploy them, and become the final authority for a commercial release.

Production adds a different responsibility layer:

Even if an agent drives a repository to a green state, a person should still be able to open the pull request, read the diff, inspect the code in an IDE, and accept responsibility for the release.

The experiment described here is narrower.

It focuses on the development path:

The question is therefore not:

The question is:

This article is primarily about the cost structure of development, not about production applicability.

The cumulative usage curve becomes much more interesting around April-May 2026.

That is when I began developing Console MCP and moving from ordinary conversational assistance toward direct agent access to local repositories.

Before that transition, I sometimes worked in the familiar way: upload a ZIP archive, provide a large block of project material, ask ChatGPT to analyze it, then manually move the useful result back into the development environment.

After the Console MCP workflow became central, that pattern largely disappeared from my engineering work.

The repositories stayed local.

The model received bounded capabilities through MCP and could request the state it needed directly from the real development environment.

The workflow increasingly became:

This matters when interpreting the token curve.

The growth after April-May did not come from me writing progressively larger prompts.

In fact, the human-authored prompts often became dramatically smaller.

A surprising amount of my interaction eventually looked like this:

These messages contain almost no new engineering information.

They are mostly continuation signals.

The important change is that the workflow moved out of the prompt and into the infrastructure.

That does not mean total model input became tiny. Tool results, repository state, file content, test output, and other machine-generated context are still input to the model.

The change is specifically in human-authored coordination:

human input became smaller while machine-executed engineering work became larger.

From that point forward, I was no longer developing only the product ecosystem.

I was developing two systems in parallel:

Console MCP started as a controlled way to connect an interactive AI session to local engineering capabilities.

Then practical use kept exposing missing pieces.

If an agent repeatedly misunderstood a repository boundary, the tooling needed a stronger boundary.

If it repeatedly selected a technically valid but locally non-canonical architecture, that rule needed to become explicit.

If a task could not prove that it was complete, the verification layer needed better evidence.

This is how Canon, Gating, Inspecting, repository reconnaissance, repair loops, bounded execution, Git operations, GitHub capabilities, and completion logic gradually became part of the same engineering environment.

The feedback loop looks roughly like this:

This makes the system recursive.

Some AI compute produces product code.

Some AI compute improves the developer platform that will make the next unit of AI compute more useful.

For that reason, one million tokens in April and one million tokens in October are not necessarily equivalent units of engineering production.

The machine between the model and the repository has changed.

Another important change is parallelism.

The work is no longer naturally described as one developer working sequentially on one repository.

In an active wave, I commonly have roughly six to eight repositories in flight at the same time, sometimes more.

One may be in reconnaissance.

Another may be repairing architectural violations.

Another may be running verification.

Another may be reconciling Git state.

Another may already be in a later remediation cycle.

The exact concurrency changes with repository weight, tests, browser activity, and available local resources, so I do not treat six to eight as a capacity benchmark.

It is simply a realistic description of the current working pattern.

This changes what productivity means.

Lines of generated code are not particularly interesting.

Even commits alone are weak as a primary metric.

More useful measures are becoming:

My current operational impression from nightly runs is that roughly half of chats may already reach ready_to_delete=true.

I intentionally call that an observation rather than a measured benchmark until the historical logs are aggregated and analyzed.

But the semantic meaning is important: the loop has reached a state where the conversation no longer contains useful unfinished repository work.

If the approximately 50% figure survives measurement, it will be a much more meaningful result than a raw token count.

In ordinary AI-assisted development, the engineer often becomes a transport protocol between the model and the development environment.

The engineer copies an error into the chat.

Runs a command.

Returns the output.

Copies a patch back into the repository.

Checks Git.

Pushes.

Checks GitHub.

Returns to the model.

This can be productive, but the human is still physically connecting every stage of the feedback loop.

MCP changes that geometry.

State can move machine-to-machine.

The model requests a bounded capability.

The tool returns evidence.

The next decision is based on that evidence.

If a gate fails, the loop can continue.

If the repository is dirty, the agent can inspect why.

If a canonical rule is violated, the agent can attempt a repair.

If the required checks pass, the workflow can advance.

The human no longer needs to be the transport layer between reasoning and execution.

Once the human contribution to many transitions becomes Go, Next, or Continue, a new architectural question appears.

Why should a person have to provide a continuation signal that contains no new engineering judgment?

This is where the reasoning engine enters the system.

Console MCP already works with bounded iteration budgets. A task can be permitted to continue for a defined number of cycles and under explicit stop conditions rather than requesting a new human permission after every mechanical transition.

We have also integrated JEV into the reasoning/control path. Its intended role is not to replace the main engineering model, but to help answer a narrower control-plane question:

The simplified control path becomes:

This is important because Go ahead is usually not engineering reasoning.

It is a permission signal.

If the control layer can evaluate the evidence, preserve the execution envelope, and remain inside a predefined budget, that signal can increasingly be generated by the system itself.

I do not want autonomy to mean disappearance.

I do not want to send a task into a black-box background process and return hours later to a final patch with no useful working history.

The model conversation remains valuable as an observation and intervention surface.

I want to be able to enter the same chat whenever I choose.

I can inspect what is happening.

Add an architectural constraint.

Stop a direction I do not like.

Ask a question.

Change the objective.

Then leave the loop again and allow bounded autonomous continuation.

The design target is therefore not:

It is:

The important part is continuity.

Human participation does not require exporting state, switching to another dashboard, reconstructing context, or restarting the task in a different system.

The same conversation remains the shared control surface.

With billions of tokens visible in telemetry, the obvious optimization question is how to reduce reasoning and output.

I absolutely want to reduce redundant tokens.

But I do not want to optimize away observability before the system has learned what needs to be formalized.

This requires an important distinction.

I am not claiming access to the model’s private hidden chain of thought.

What I do have is an observable engineering trajectory:

That operational trace makes it possible to notice a class of errors that ordinary industry checks may not detect.

An implementation can compile.

Tests can pass.

Static analysis can be green.

The solution can even be reasonable by common industry practice.

And it can still violate the architecture of this particular ecosystem.

It may use the wrong physical topology.

The wrong naming convention.

The wrong interface direction.

The wrong API convention.

The wrong ownership boundary.

These are local canonical violations.

The useful cycle is therefore:

In that sense, one of the best token optimizations is not a shorter prompt.

It is moving knowledge out of conversation and into executable infrastructure.

The next obvious optimization is not only to reduce the number of tokens, but to choose the appropriate cost for each token.

Not every step requires frontier-level reasoning.

Some tasks are closer to control-plane classification:

We are developing access through Cloudflare AI Gateway so that cheaper models can eventually be used for suitable parts of this control path.

But this distinction is important:

that future routing is not part of the economic result described in this article.

I currently have essentially no meaningful paid API token usage supporting this workflow, and I do not maintain a separate paid stream of cheap-model tokens or subscriptions that should be counted as hidden operating cost.

The cheaper-model layer is still being developed and expanded.

JEV is closer to practical continuation-control use, while broader model routing remains a next-stage experiment.

If that work succeeds, the system should eventually optimize two dimensions at once:

Now the 6.7 billion-token figure becomes economically interesting.

First, another important clarification:

I did not run this workload through a paid OpenAI API account.

My meaningful paid API usage is effectively negligible relative to the workflow described here.

The work was performed primarily through the ordinary ChatGPT Plus product.

OpenAI’s published list price for ChatGPT Plus is currently USD 20 per month. My practical out-of-pocket subscription cost is roughly in the USD 20-25/month range depending on billing and taxes.

API pricing is therefore used below only as a counterfactual replacement-cost benchmark.

It is not an API bill that I avoided paying, and it is not a claim about OpenAI’s internal cost of serving ChatGPT.

The question is simply:

There is no exact answer because the 6.7 billion-token telemetry does not provide a clean historical split between:

Also, the 6.7 billion figure is lifetime usage. It should not be mechanically treated as if every token belonged to the April-October engineering period.

So the only honest calculation is scenario-based.

As of October 3, 2026, OpenAI publishes GPT-5.6 Sol API pricing of approximately:

Official pricing reference: OpenAI GPT-5.6 Sol model pricing.

Take one purely illustrative agentic mix:

Applied mechanically to 6.7 billion tokens, that scenario produces approximately:

That is not a claim that my workload "cost USD 23,048."

It is one replacement-cost scenario under one current model and one assumed token distribution.

The same volume under a much cheaper model would be dramatically lower. A more output-heavy or less cache-efficient frontier workflow could be higher. Tool calls and other metered services can also change the result.

This is why I do not think a precise multiplier is defensible.

The useful observation is not whether the correct hypothetical number is USD 8,000, USD 15,000, or USD 23,000.

Discount the number aggressively.

Remove non-engineering usage.

Assume a much cheaper routing strategy.

Assume much better caching.

Assume a production-quality agent would be significantly more efficient than my exploratory workflow.

The economic categories can still remain very far apart:

That does not make subscription pricing and API pricing directly comparable products. They are not.

It does not prove that one pricing model is universally better.

It does not reveal provider economics.

It simply shows why the economics of personal agentic computing are worth studying.

The gap is large enough that a substantial uncertainty coefficient does not automatically erase the observation.

The larger effect may be human orchestration time.

Traditional AI-assisted development constantly interrupts the engineer:

Each interruption is small.

Collectively, they destroy parallelism.

A human can understand many systems but cannot continuously babysit many independent feedback loops with equal attention.

If six, eight, or more repository workflows can make progress concurrently, and some of them reach terminal state while I am absent, the value is not merely that several tasks were completed.

The deeper value is that the feedback loops existed in parallel without consuming equivalent human coordination time.

This is why I increasingly care less about:

and more about:

There is another reason I do not want to over-clean the dataset.

My ChatGPT activity includes more than code generation.

It includes research, writing, browser work, architecture, technical questions, planning, and personal breakpoints in a real working day.

For a laboratory benchmark, that is contamination.

For a description of how an engineer actually works, it may be part of the phenomenon.

Real engineering is not eight uninterrupted hours of producing commits.

It is debugging, investigation, communication, design, reading, reconsideration, experimentation, and context switching.

When an AI environment becomes a general cognitive workspace, some of that inevitably appears in its telemetry.

Future analysis should separate those categories where possible.

But I do not want to pretend the human day is cleaner than it really is.

The 6.7 billion-token figure started this analysis, but it should not become the final KPI.

The more useful next step is to correlate several independent time series from April-May onward:

The central question is no longer:

It is:

That is a much more interesting measure of agentic development maturity.

Six point seven billion tokens are not an accomplishment by themselves.

If the system matures correctly, the same verified engineering outcome should eventually require fewer tokens, fewer human continuation signals, and less expensive reasoning.

The evolution so far has been roughly:

At the same time, the human role moves upward:

That is the transition I am trying to measure.

Not whether AI can type code faster than I can.

Not whether a model can eliminate production review.

Not whether a large token number looks impressive.

The more interesting question is whether one engineer can build an execution environment in which increasingly complex pre-release engineering proceeds in parallel, under explicit budgets and rules, while the human remains able to enter the same loop whenever judgment is actually needed.

Over several months, I started with an AI assistant.

Then I gave it controlled access to the development environment.

Then I began encoding architectural rules into the tools around it.

The tools became loops.

The loops began repairing repositories.

They began verifying their own results.

Several repository workflows began operating in parallel.

Some began reaching terminal states without requiring another manual Go.

Now a reasoning/control layer is beginning to answer whether the next iteration is justified within a defined budget, while cheaper model routing remains a future optimization rather than a hidden current cost.

The human has not disappeared.

The production review boundary has not disappeared.

Responsibility has not disappeared.

What is disappearing, gradually, is the requirement for a human to serve as the mechanical coordinator of every engineering transition before Release Candidate.

That is why I no longer think of the 6.7 billion tokens as the result.

They are telemetry from a transition:

The next task is to measure that transition properly.

This article is based on the author’s practical development workflow, local repository automation, Console MCP, and observed ChatGPT usage telemetry.

ChatGPT Plus was used as an engineering, research, and editorial instrument in the process described here and in preparing this text.

The economic calculations are illustrative replacement-cost scenarios, not invoices, audited cost models, provider cost estimates, or promises of equivalent API behavior.

Console MCP, its reasoning engine, JEV integration, and model-routing work remain under active development. The workflow described here should not be interpreted as a production-readiness claim or as a recommendation to remove human code review from commercial releases.

Copyright © 2026 Oleksandr Tishchenko, Marketing America Corp.