The Economics of Agentic Work

A coding agent can produce in minutes code that used to take a developer hours. That is no longer a particularly exotic experience. Depending on the task, the difference can be impressive: an implementation that might once have taken half a working day can appear as a first complete diff after only a few minutes.

That quickly invites an apparently obvious calculation:

10× faster code generation
=
10× faster software development
=
10× lower costs

The first line of that calculation can be true. The two equal signs cannot.

Not because code generation has no value. Quite the opposite: I now work intensively with coding agents and experience clear productivity gains myself. For my own work, I would currently place the effect roughly around 20 percent – already including serious review of the generated changes. That is not a scientific effect size. It is my personal estimate in my current working context.

The mistake lies elsewhere: we confuse the acceleration of one production step with the acceleration of the entire production system.

Software engineering is not just writing code. Before a change come problem understanding, requirements, architecture, and solution decisions. Afterward come tests, integration, debugging, verification, review, security, operations, and business acceptance. Some of those steps can also become faster with AI. Others remain largely intact. Some become more important as the volume of machine-generated changes grows.

That is why the interesting economic question is not:

How cheaply can a model generate tokens?

It is:

What costs were necessary before a requested change became a technically and functionally sufficiently verified, accepted change?

I will call this operational unit Cost per Accepted Change.

It is not the same as ROI. A change can be generated, tested, and accepted for a few euros and still have no economic value. Conversely, an expensive change can create enormous business value. Cost per Accepted Change initially measures the efficiency of the engineering process. Economic value sits one level above it.

The thread of this article therefore runs from the token, through the agent run and the accepted change, to the organization – and finally to a question that is easily lost in short-term productivity calculations: what capabilities does an organization still possess afterward, and which ones is it building for the future?

The false multiplier

Software engineering is not coding.

That sounds trivial, yet it is forgotten surprisingly quickly in many discussions about AI productivity. If an activity that used to take three hours shrinks to 18 minutes, the visible speedup factor really is ten. But that activity may have been only one part of an eight-hour change.

The rest does not disappear automatically.

A business requirement still has to be understood. Architecture decisions still have to fit an existing system. Tests not only have to exist; they have to make meaningful assertions. A diff can be syntactically correct and still be functionally wrong. A migration can work locally and fail in production. Security requirements are not fulfilled merely because the model confidently claims they are.

Coding agents can support these activities too. That is an important part of their value. But then we have to measure exactly that effect – not the factor by which implementation-code generation alone became faster.

10× code generation
≠
10× software engineering
≠
10× cost reduction

Current empirical research shows just how strongly measured effects depend on the slice of work being observed. In a well-known randomized GitHub Copilot experiment with 95 recruited software developers, participants completed a clearly bounded JavaScript task on average 55.8 percent faster with Copilot. Three larger randomized field experiments at Microsoft, Accenture, and another Fortune 100 company, covering 4,867 developers in total, found 26.08 percent more completed tasks in the pooled analysis. That work has since been published in Management Science. Even there, results vary substantially across the individual experiments; the pooled estimate has a standard error of 10.3 percentage points.

Another setting produced the opposite result. In 2025, METR asked experienced open-source developers to work on real tasks in repositories they had known for years. With the AI tools available at the time, participants took 19 percent longer on average in the randomized experiment. METR explicitly stresses that this was a snapshot of early-2025 tools in a particular environment. A follow-up experiment with newer models pointed more toward acceleration in 2026, but suffered from such serious selection and measurement problems that the authors themselves describe the magnitude as unreliable.

Even more interesting is the September 2026 revision of the NBER working paper Writing Code vs. Shipping Code, which uses data from more than 500,000 GitHub developers and their AI-usage telemetry. With newer generations of coding tools, measured commits rise dramatically. For autonomous coding agents, the authors report a cumulative effect of 240 percent on commits. At higher production stages, however, the effect weakens sharply: to 80 percent for projects and only 30 percent for actual releases. This is still a working paper, not a final causal truth. But the result illustrates the problem of this article beautifully: writing code and shipping code are different production stages.

The relevant multiplier therefore does not live in the editor. It lives in the full production flow.

From the token to the accepted change

The simplest economic metric for a language model is the price per token. It is precise, easy to compare, and therefore attractive.

Unfortunately, it answers only a very small question.

A more useful hierarchy looks like this:

Cost per Token
↓
Cost per Run
↓
Cost per Successful Run
↓
Cost per Accepted Change
↓
Economic Value

Cost per Token answers how expensive inference is according to the tariff.

Cost per Run takes into account how much context and output a concrete run actually consumes.

Cost per Successful Run additionally accounts for the fact that an agent can fail, abort, or pursue an unusable solution path.

Cost per Accepted Change finally considers how many attempts, tests, corrections, reviews, and how much human work were required before the change became acceptable.

Only above that comes Economic Value: what economic benefit does this change create at all?

Put differently:

Model pricing answers what computation costs. It does not answer what problem solving costs.

That distinction is fundamental. A 20-cent agent run whose result takes me 45 minutes to repair can be more expensive than a five-dollar run I accept after ten minutes of review.

And a technically accepted change can still be a feature nobody needs.

Cost per Accepted Change is therefore not a replacement for ROI. It is the operational engineering layer immediately below it.

What does generation actually cost?

In token-based billing, three directly priced categories are especially relevant at first. Input Tokens include the context the model receives: prompt, conversation history, source code, agent instructions, tool results, and potentially large parts of a repository. Cached Input is reusable context that a provider can bill at a reduced price. Output Tokens cover usage generated by the model. With reasoning models, this can additionally include internal Reasoning Tokens that do not appear as visible answer text.

Agentic workflows make this calculation more complex than a single chat. An agent reads files, executes tools, receives their results, changes code, starts tests, and processes their output. It may see the same repository context multiple times or loop several times because an initial hypothesis failed.

Tool calls can also carry additional charges depending on the platform. Long contexts may have their own pricing rules. With GPT-5.6 Sol, for example, API requests above 272,000 input tokens are billed for the entire request at twice the input rate and 1.5 times the output rate; cache writes cost 1.25 times the normal input rate. GPT-6 Astra likewise has its own cache-write and long-context rules. Product surfaces such as Codex can in turn have different exceptions.

So even a model’s list price is not yet a complete cost function for an agentic flow.

Model prices in September 2026

As of September 10, 2026, OpenAI lists the following standard prices per million text tokens for GPT-5.6 Sol and GPT-6 Astra:

Model	Input / 1M	Cached Input / 1M	Output / 1M	Note
GPT-5.6 Sol	$4.00	$0.40	$20.00	promotional rate at least through Nov. 21, 2026
GPT-6 Astra	$10.00	$1.00	$50.00	standard rate at the reference date
Astra / Sol ratio	2.5×	2.5×	2.5×	based on these list prices

The values come from OpenAI’s current official model pages and token-based rate card. OpenAI explicitly notes that the current Sol price is a time-limited promotional rate.

Nominally, Astra therefore has a 2.5× higher price per token than Sol.

That is a correct statement.

The statement

Astra costs 2.5 times as much per solved task

does not follow from it.

And the statement

Astra costs 2.5 times as much per accepted change

follows even less.

Concrete prices will probably already be outdated in 2027. The calculation model behind them will remain relevant.

Reasoning is not a fixed multiplier

Statements such as “High reasoning costs three times as much” require particular caution. A higher reasoning level at OpenAI does not automatically increase the list price per token within the same model. The current rate card gives GPT-5.6 the same tariff across its different reasoning levels.

More reasoning can, however, generate more usage. OpenAI exposes reasoning tokens inside output_tokens_details; they count as part of output usage. max_output_tokens includes both visible output and reasoning tokens.

The economically clean formulation is therefore:

Reasoning effort is not a fixed price surcharge. Higher effort can cause additional compute and additional tokens, whose magnitude depends on the task, model, and run.

That is more than semantic nitpicking. On one task, a higher reasoning effort may increase token count and still be cheaper if it eliminates two additional agent runs. On a simple, already highly converged task, the same additional effort may simply be waste.

A change is more than its implementation

Take a deliberately simplified change that requires eight hours of classic engineering effort in total. The implementation itself accounts for three of those hours.

A coding agent accelerates exactly that part by a factor of ten: 180 minutes of implementation become 18 minutes.

At the same time, work shifts into other phases. The agent produces more tests and iterates independently; the developer invests more heavily in review and verification. The following values are not empirical averages, but an illustrative model calculation:

Work step	Classic	Agentic
Understanding / analysis	60 min	55 min
Architecture / decision	45 min	50 min
Implementation	180 min	18 min
Tests / iterations	75 min	90 min
Review / verification	60 min	100 min
Integration / acceptance	60 min	67 min
Total	480 min	380 min

Actual code production has fallen by 90 percent. Total duration falls only from eight hours to six hours and 20 minutes: about 21 percent.

That would be anything but disappointing.

A robust productivity gain of around 20 percent in an expensive engineering organization would be economically highly attractive. It simply sounds less spectacular than “10×.”

And that is precisely the problem with many AI discussions: a realistic systemic gain looks small when placed directly next to the acceleration factor of a single activity.

The empirical findings fit this caution. Under clearly bounded conditions, very large speedups can occur; in more complex real-world work environments, effects vary substantially and can weaken along the production chain.

My personal estimate of roughly 20 percent is therefore exactly that: a personal estimate. It neither confirms nor disproves any study.

The more expensive model can be cheaper

With OpenAI’s current prices, the problem can be made even more concrete.

Assume a demanding change where each agent run uses around 200,000 input tokens and 15,000 output tokens. The first run uses uncached input; for follow-up attempts, we make the strongly simplified assumption that the large context can be read entirely from the cheaper cache.

Sol needs three attempts. Astra, in this example, reaches an acceptable solution in one.

For human labor, the model calculation assumes fully loaded costs of $100 per hour. Again, that is only an illustrative figure.

Metric	GPT-5.6 Sol	GPT-6 Astra
List price by token category	1×	2.5×
Tokens per run	200k input + 15k output	200k input + 15k output
Number of runs	3	1
Correction loops	2	0
Model cost	$1.86	$2.75
Steering / correction time	70 min	25 min
Review / verification	35 min	20 min
Total Human Active Time	105 min	45 min
Human cost at $100/h	$175.00	$75.00
Accepted	yes, after run 3	yes, after run 1
Cost per Accepted Change	$176.86	$77.75

Sol’s model cost here consists of a first run costing $1.10 and two heavily cached follow-up runs at $0.38 each. Astra is indeed more expensive in pure inference at $2.75.

In the total calculation, Astra is still considerably cheaper because assumed human work falls much more sharply.

The model calculation does not prove that Astra is generally better or cheaper. It merely shows why list price is not a sufficient optimization variable.

The cheapest model is not necessarily the model with the lowest token price. It is the model that produces a sufficiently good, verified change at the lowest total cost.

The counterexample matters just as much. For a standardized CRUD endpoint with excellent tests, clear architecture rules, and little decision freedom, a frontier model may be unnecessary. If a cheaper model produces the same change with the same reliability, additional capability simply destroys margin.

Model routing is therefore not only a quality question. It is an economic control problem.

Model economics ages quickly

The development of the last two years already shows how quickly this analysis can age.

The following table is explicitly not a benchmark time series. Benchmarks, harnesses, prompting, reasoning budgets, test-time compute, and in some cases even datasets have changed. The numbers should therefore not be connected into a mathematical “capability curve.”

They illustrate something else: what was available for coding and agentic work could improve substantially while list prices remained constant or even fell.

Date	Model	Input / 1M	Output / 1M	Relevant coding / agentic signal
06/2024	Claude 3.5 Sonnet	$3	$15	new Sonnet generation at the existing mid-tier price
10/2024	Claude 3.5 Sonnet, update	$3	$15	SWE-bench Verified according to Anthropic from 33.4 to 49.0%, same price
02/2025	Claude 3.7 Sonnet	$3	$15	63.7% on the internally runnable 489-task SWE-bench Verified subset; 70.3% with additional test-time compute
05/2025	Claude Sonnet 4	$3	$15	72.7% SWE-bench Verified in the published setup
09/2025	Claude Sonnet 4.5	$3	$15	77.2% SWE-bench Verified, different thinking / prompting setup
02/2026	Claude Sonnet 4.6	$3	$15	same price; around 70% preference over 4.5 in early Claude Code tests
04/2026	GPT-5.5	$5	$30	82.7% Terminal-Bench 2.0
07/2026	GPT-5.6 Sol	currently $4	currently $20	88.8% Terminal-Bench 2.1; September 2026 price is temporarily reduced
06/2026	Claude Sonnet 5	$2	$10	introductory price made permanent in August 2026

Anthropic launched Claude 3.5 Sonnet in 2024 at $3/$15 and kept that price for several successors. The Claude 3.5 Sonnet update, for example, raised Anthropic’s reported SWE-bench Verified score from 33.4 to 49.0 percent without increasing the price. Claude 3.7, Sonnet 4, and Sonnet 4.5 likewise remained at $3/$15.

The comparability of the respective SWE-bench values is limited, however. With Claude 3.7, for example, only 489 of the 500 tasks were internally runnable on Anthropic’s infrastructure, and the high-compute result used parallel attempts plus a selection mechanism. Sonnet 4 was evaluated with a simple two-tool setup; Sonnet 4.5 again used a defined thinking budget and an additional prompt instruction.

In 2026, the price movement became even clearer: Sonnet 4.6 remained at $3/$15. Sonnet 5 launched in June at $2/$10 as an introductory price; Anthropic then made that price permanent in August 2026.

OpenAI likewise does not follow a simple “newer = more expensive” equation. GPT-5.5 launched at $5 input and $30 output per million tokens. GPT-5.6 Sol is at $4/$20 at the reference date of this article, albeit as a time-limited promotion. OpenAI reports, among other things, 88.8 percent on Terminal-Bench 2.1 for GPT-5.6 Sol versus 85.6 percent for GPT-5.5.

With GPT-6 Astra, Terminal-Bench has already moved to version 4.0. There, OpenAI reports 57.9 percent for Astra and 37.3 percent for Sol. Those figures are explicitly not comparable as a continuous historical line with Terminal-Bench 2.0 or 2.1 from older releases. On the still identically named DeepSWE v1.1, Astra and Sol are much closer in the same current OpenAI evaluation, at 74.1 and 72.7 percent.

That is the important economic lesson:

Capability can rise sharply while list price stays constant or even falls.

A business case built around the price-performance ratio of one particular model today is therefore only a snapshot.

Small capability jumps can create large agentic effects

Benchmark increases of a few percentage points can look unimpressive. In long agentic flows, however, a small improvement in local reliability can have a much larger effect.

Take a purely illustrative workflow with ten relevant decisions. Suppose each decision were made correctly and independently with a probability of 90 percent:

0.9^10 ≈ 35%

At 97 percent:

0.97^10 ≈ 74%

This explicitly does not mean that real agents can be modeled mathematically in this way. Decisions are neither independent nor equally difficult. Some errors can be corrected later; others influence several subsequent steps at once.

The model illustrates only one mechanism: the longer the decision chain, the more strongly additional reliability can affect the probability of completing the workflow without human intervention.

That also explains why individual model generations can subjectively feel like a quantum leap even when a benchmark rises only moderately. Not every improvement appears as a spectacularly better single answer. Sometimes the decisive difference is simply that after the seventh tool call, the agent no longer drifts away from the original task.

Agentic capabilities can respond nonlinearly to comparatively small improvements in model reliability.

And at that point, a nominally more expensive model may suddenly require far less Human Active Time.

88 billion tokens say surprisingly little

At one quarterly meeting, my current employer proudly reported roughly 88 billion tokens consumed in a single quarter. The company has around 1,000 employees.

My first thought was: that sounds enormous.

The second was more interesting: what does that number actually mean?

Were they input tokens? Cached input? Output? Reasoning? Coding agents? Other AI workloads? Large repository contexts repeatedly loaded? Highly efficient automated workflows? Or expensive agent loops running more often than necessary?

With the current Sol and Astra list prices, it is easy to show how little the raw token count says about cost.

Eighty-eight billion tokens equal 88,000 units of one million tokens:

If all 88B tokens were assumed to be …	Approximate cost
Sol Cached Input at $0.40 / 1M	$35,200
Sol Input at $4 / 1M	$352,000
Astra Input at $10 / 1M	$880,000
Sol Output at $20 / 1M	$1,760,000
Astra Output at $50 / 1M	$4,400,000

The calculation uses OpenAI’s official prices as of September 10, 2026.

Of course, none of these extreme cases is realistic. A real workload consists of a mix of token categories, models, cache rates, and potentially additional tool costs.

That is precisely why the table is useful.

The same number of 88 billion tokens represents between roughly $35,000 and $4.4 million in those boundary cases – a factor of 125.

And even if we knew the actual costs exactly, we still would not know whether the usage was economically worthwhile.

Token consumption is an activity metric, not a productivity metric.

Eighty-eight billion tokens can be a sign of excellent automation. Or a sign that very expensive loops are running very often. The number alone cannot distinguish between the two.

When usage becomes the success metric

Many organizations are still in an early phase of AI adoption. Metrics such as active AI users, agent runs, generated lines of code, or tokens consumed are therefore natural.

Those metrics are not useless. They answer questions about adoption, infrastructure demand, and cost development.

They should simply not be confused with the outcome.

Usage
↓
Cost
↓
Verified Outcome
↓
Engineering Value
↓
Business Value

If token consumption itself becomes the success measure, a curious incentive appears: a team that produces the same change with half the tokens looks worse in a usage dashboard than one that burns twice as much inference for the same work.

Goodhart’s Law fits here rather well: once a proxy metric becomes the target, it can lose its information value.

For an engineering dashboard, metrics such as successful agent runs, retries per accepted change, Human Active Time, review rework, Defect Escape Rate, or Cost per Accepted Change would therefore be more interesting than a raw token count.

Only at this level does usage begin to say something about production.

Expensive inference can still be economically cheap

Up to this point, it would be easy to get the wrong impression that the argument is simply: AI is more expensive than it looks.

That is not the point.

AI can be economically highly attractive even when the absolute inference bill looks frightening.

Consider an organization with 200 developers. As a simple model assumption, use 160 working hours per month and fully loaded costs of €75 per developer hour.

That gives the organization, arithmetically, per quarter:

200 developers
× 160 hours
× 3 months
=
96,000 developer hours

What would a genuine productivity increase of 10, 20, or 30 percent imply arithmetically?

Productivity assumption	Theoretical capacity released / quarter	Valued at €75/h
10%	9,600 h	€720,000
20%	19,200 h	€1,440,000
30%	28,800 h	€2,160,000

Again, this table is exclusively a model calculation.

Released capacity is not cash in the bank. Twenty percent less time spent on certain activities does not automatically mean 20 percent more features, 20 percent more revenue, or 20 percent fewer employees. Bottlenecks can sit elsewhere. Demand can be limited. Some of the gained time can dissipate.

The order of magnitude still shows why an inference bill of several hundred thousand euros per quarter is not automatically “too expensive.”

Expensive inference can be surprisingly cheap if it genuinely makes expensive human labor more productive.

The critical qualification is contained in the word genuinely.

This brings the calculation back to accepted changes rather than tokens.

Wall Clock is not Human Active Time

Agentic work adds another peculiarity.

Suppose an agent needs 20 minutes for analysis, implementation, and tests.

Are those 20 minutes a cost for the developer?

Not necessarily.

If I stare at the screen waiting for completion, Agent Time and my tied-up time are almost identical. If I instead prepare an architecture decision, clarify requirements, or read documentation, productive overlap becomes possible.

I now regularly use such phases for documentation, architecture work, or learning more about AI. That is a real part of the productivity effect I personally experience with agentic work.

It is therefore useful to distinguish three time concepts.

Agent Time is the time during which the machine works independently.

Human Active Time is the time during which a human must actively decide, plan, review, correct, or provide context.

Coordination Time is one part of that human work: handoffs, questions, context switching, synchronizing multiple agents, and rebuilding the developer’s own mental model.

Wall Clock
├── Agent Time
└── Human Active Time
    └── of which: Coordination Time

Agent Time and Human Active Time can overlap.

The categories are therefore not simply additive. While Agent Time is running, human work on the same or a different activity can happen at the same time.

The economically interesting variable is therefore not merely the agent’s runtime.

Agentic Work can do more than reduce the duration of a task. It can release human attention during that duration.

Released attention only has economic value, however, when it actually flows into valuable work, learning, planning, or other productive activities.

Technical parallelism is not human parallelism

Parallel agents initially look like the perfect scaling strategy.

One agent implements a feature. A second builds E2E tests at the same time. A third may already be analyzing the next change.

Technically, that is impressive.

Cognitively, it can become unpleasant very quickly.

I use a relatively simple principle for myself: “Focus on one thing and do it well.” That is not a universal law. It merely describes how I process complex engineering work most reliably.

Cognitive research supports at least the mechanism behind it. Research on task switching distinguishes stable task focus from cognitive flexibility when moving between tasks. Reviews of interruptions show measurable effects, including on resumption time and accuracy on a primary task. This does not imply that humans “cannot multitask.” It does imply that switching and resuming are not cognitively free.

For agentic work, that matters.

Machines can execute three workstreams in parallel. The developer may still have to hold three different system states, solution spaces, and open decisions in mind.

Agentic parallelism is technically cheap. Human parallelism is not cognitively free.

The number of agents that can usefully run in parallel therefore does not automatically scale with available compute.

Parallelism works better inside the same solution space

In my own work, parallelism works much better when the parallel activities orbit the same problem.

For example:

Feature
├ Implementation Agent
├ E2E Agent
├ Review Agent
└ Human: architecture and acceptance

Everyone is operating in the same business context. If the implementation agent makes a decision, the review agent can inspect exactly that decision. The E2E agent tests the same flow. I myself only have to keep one system model active in my head.

It becomes harder when three agents simultaneously change three functionally unrelated features. Technical parallelism can then rise while Human Active Time and Coordination Time grow disproportionately.

That leads to a practical hypothesis:

Agentic parallelism is especially valuable when machines work on different parts of the same problem without forcing the human to keep several system models open at once.

The optimal number of agents is therefore not purely an infrastructure question. It also depends on the human ability to coordinate and verify the resulting changes meaningfully.

The real investment is Agent Infrastructure

Anyone who looks at agentic work only through ongoing token costs misses another substantial cost block: building an environment in which agents can work reliably.

I now deliberately try to intervene as little as possible directly in an agent implementation. My goal is not to manually rescue every bad agent run.

Instead, I prefer investing in structures that make the next run better:

• Agent Files and Skills,
• clear architecture rules and module boundaries,
• understandable slicing,
• stable contracts,
• automated tests,
• executable architecture and quality checks,
• transparent review rules,
• consistent naming and project structure.

That shifts the focus.

I write less implementation code directly and spend more time on architecture, solution design, constraints, inspiration, review, and agent enablement. Even activities that were never among my favorite tasks – writing tickets cleanly and completely, for example – AI can often structure more effectively than I would spontaneously.

I do not claim to have mastered agentic work perfectly. Quite the opposite: part of my current work is figuring out how far a well-designed flow can be pushed.

But one shift is becoming increasingly clear: in the long run, the most important prompt may not be the one that generates the next change. It may be the infrastructure that makes a hundred similar changes reliable.

Maximum boredom in the code

The goal of repeatable agent work is not maximum creativity for me.

I want as much boredom as possible.

Similar problems should produce structurally similar solutions. A new capability should live where I expect it. An API access should follow the same rules as the previous one. State management should not be reinvented for every feature.

That is valuable for human teams already. With agents, it becomes economically even more interesting.

Because repeatability does not only reduce implementation time.

It also reduces verification cost.

If I roughly know what structure a change should have, I can read it faster. Tests can be targeted more precisely. Architecture rules can be checked mechanically. Surprises become rarer.

Repeatability reduces not only implementation cost. It also reduces verification cost.

That changes the cost function of agentic work.

Take a heavily simplified one-time investment of €10,000 for agent instructions, architecture rules, test infrastructure, and review automation. Spread over 20 accepted changes, that is €500 of upfront cost per change. Over 50 changes, €200. Over 100, €100.

Agent Files
+ Skills
+ Architecture Rules
+ Test Infrastructure
+ Review Setup
=
high upfront cost

          ↓

20 changes → €500 / change
50 changes → €200 / change
100 changes → €100 / change

Again, this is only a numerical example. But the mechanism follows classic fixed-cost economics: the upfront investment is expensive; the marginal cost of repeatable production can subsequently fall.

Agentic Work becomes economically especially interesting when one-off prompt work turns into reusable production logic.

In the long run, I see more potential here than in the question of whether one individual prompt was especially clever.

Local models have a different cost function

Cloud models have one pleasantly simple property: usage produces mostly variable cost. Process ten times as many tokens, and the bill rises accordingly.

Local inference changes the cost structure.

Instead of ongoing provider prices, you get hardware investment, depreciation, electricity, maintenance, administration, and utilization risk.

As a concrete September 2026 example, consider Qwen3.8-27B on an NVIDIA DGX Spark. The official Qwen model is released under Apache 2.0. NVIDIA specifies 128 GB of unified memory, 273 GB/s memory bandwidth, a GB10 with a 140-watt TDP, and a 240-watt power supply for DGX Spark. The current U.S. list price for DGX Spark is $4,699.

At the reference date, there is no robust manufacturer figure for the actual Qwen3.8-27B speed on this hardware that I would treat as general throughput. One explicitly labeled community benchmark reports roughly 25.1 tokens per second for an NVFP4+MTP configuration in single-stream decoding. That is not an NVIDIA or Qwen guarantee and can vary substantially with runtime, quantization, context length, and configuration.

It still allows a transparent model calculation.

Assumptions:

Hardware:              $4,699
Depreciation:          3 years
Working days:          220 / year
Decode:                25.1 output tokens/s
Electricity:           $0.30 / kWh
Power in the model:    240 W

The 240 watts correspond to the power-supply rating and are deliberately used here as a conservative calculation assumption, not as a measured sustained inference draw. Administration, maintenance, downtime, financing, prompt processing, and concurrent users are not included. The calculation looks only at a rough output-token-equivalent capacity. For that reason alone, it is not a direct full-cost comparison with a cloud output tariff, but a utilization calculation for local hardware.

Scenario	High utilization	Low utilization
Active inference	8 h / working day	1 h / working day
Output capacity / year at 25.1 tok/s	approx. 159M tokens	approx. 19.9M tokens
Output capacity over 3 years	approx. 477M	approx. 59.6M
Hardware depreciation / 1M output tokens	approx. $9.85	approx. $78.79
Electricity / 1M under model assumptions	approx. $0.80	approx. $0.80
Hardware + electricity / 1M	approx. $10.65	approx. $79.59

At high utilization, local inference suddenly looks very cheap. At low utilization, depreciation dominates.

That is exactly the point:

Local inference partly replaces variable cloud cost with fixed cost and utilization risk.

Ecological efficiency is explicitly not the subject of this article. Energy consumption is considered here only as a business-cost item.

Local is not automatically cheaper

The table could invite another wrong conclusion.

If Qwen locally works out to roughly eleven dollars per million output tokens while Astra costs 50 dollars in the cloud, then local must automatically be cheaper.

No.

A Qwen token and an Astra token are not economically the same product.

If a smaller local model drifts more often on the same change, needs more retries, produces weaker tests, or consumes more Human Active Time in review, the nominal token advantage can disappear.

The simplified local calculation also omits administration, upgrades, monitoring, downtime, runtime tuning, and the opportunity cost of idle hardware.

So this analysis again returns to the same metric:

Cost per Accepted Change.

Local can be extremely attractive at high, predictable utilization. For simple or highly standardized task classes, a smaller model may be economically ideal.

For complex, infrequent tasks, a frontier model can remain cheaper despite a much higher token price.

The interesting architecture may therefore not be “cloud or local,” but a portfolio:

routine / high frequency
→ cheaper or local model

complex / high uncertainty
→ frontier model

critical
→ additional verification

Local as a strategic option

Local models can have two additional economic values beyond the raw inference calculation.

The first is confidentiality. A local model can remove the central external model trust boundary. That does not automatically mean the whole agentic flow is local or secure.

An agent can still send data to web services, MCP servers, package managers, telemetry systems, or other external APIs.

Local Model and Local Workflow are therefore two different claims.

The second value is strategic optionality. If an organization can operate a local alternative for certain task classes, it gains an exit option against provider pricing, quotas, or changes in product conditions.

That option can have value even if it is not currently the cheapest production path.

The quiet workflow lock-in

There is a slightly ironic development hidden here.

At the beginning, teams may say:

The AI subscription costs about 25 euros per month. That is almost negligible.

A few years later, architecture, delivery processes, team sizes, review flows, and throughput expectations may all be designed around permanent inference.

Then the calculation may sound more like:

It costs considerably more now – but our current production flow no longer works without it.

No malicious provider intent is required for that.

It is a normal economic mechanism: the deeper a technology is integrated into a production process, the higher switching costs can become. Agent Files, tooling, prompt caches, APIs, evaluations, and organizational workflows may also be optimized around particular models.

The deeper Agentic Work is integrated into the production system, the higher the real switching costs can become.

In the long run, the interesting variable may therefore not only be today’s token price, but also the price elasticity of an organization whose production model already depends on continuous inference.

Consumer subscriptions create a pricing illusion

Consumer subscriptions are also of limited use for enterprise cost calculations.

ChatGPT Plus still costs $20 per month in the U.S.; local prices can differ because of taxes and billing. OpenAI now also offers Pro tiers at $100 and $200. According to current product information, Pro $100 includes five times and Pro $200 twenty times the usage volume of Plus. API usage is billed separately.

No guaranteed “API equivalent value” can be derived from that.

One user may consume very little inference in a month. A heavy user can generate much more usage. Rate limits, product quotas, caching, different models, and internal routing mechanisms further change the cost structure.

The public API list price is also not the same as the marginal price at which a provider internally produces inference.

A plausible hypothesis is therefore that subscription products can work through portfolio economics: some users generate usage whose API-list-price equivalent is far above their subscription price, while others barely consume their quotas, with caching and rate limits further shaping actual cost.

That says nothing about a provider’s real internal margins.

For an organization, the conclusion is simpler: a consumer subscription is not a robust cost model for a production process.

From the accepted change to the organization

Up to this point, the perspective has been operational.

How expensive is the model? How many runs do we need? How much Human Active Time remains? How high is review effort? How many accepted changes result?

That describes a surprisingly large part of short-term agentic economics.

But there is a second balance sheet.

If AI permanently takes over a larger share of execution, not only the cost structure of an individual change can shift. It can also change how people build experience.

That brings us to a much slower economic variable: Human Capital.

Entry-level hiring is under real pressure – but not only because of AI

The question of junior developers is now difficult to separate from the AI debate.

At the same time, observation and causality have to be distinguished very carefully.

In the United States, the August 2026 revision of the Stanford working paper “Canaries in the Coal Mine?”, based on administrative ADP payroll data covering millions of workers, shows a striking association. For 22- to 25-year-olds in highly AI-exposed occupations, employment under the study’s comparison method lies around 19 percent below the path of similarly young workers in less AI-exposed occupations. The authors find no comparable gap among experienced workers. Particularly relevant: according to the study, the adjustment appears primarily through less hiring, not increased separations. Declines are also more concentrated in occupations where observed AI use is more substitutive than complementary.

This is a strong descriptive signal of an interesting pattern, but explicitly not a causal demonstration of a monocausal AI effect. The authors themselves examined earlier versions after criticism and acknowledged that part of earlier declines was likely driven by other factors; under stricter controls, the temporal relationship becomes clearer only from 2024 onward.

Other data also call for caution. LinkedIn’s Economic Graph reported in February 2026 that entry-level hiring in software engineering was moving similarly to the broader technology sector and the U.S. labor market. LinkedIn therefore interpreted the SWE decline at that point primarily as part of broader macroeconomic weakness rather than an isolated AI effect. At the same time, according to those data, 55 percent of U.S. graduates with computer-science degrees in 2023 and 2024 started their first full-time job outside traditional software-engineering roles, compared with 49 percent in 2016.

Both can be true at once: the tech labor market can be cyclically weak while AI adds pressure to particular entry-level tasks within that weak market.

Germany has an additional cyclical IT problem

The U.S. data should not simply be transferred to Germany.

Germany’s Federal Employment Agency describes substantially weaker demand in the ICT labor market for 2025. On annual average, around 13,000 open ICT positions were registered – 22 percent fewer than in the previous year and the lowest stock since 2015. The occupation-specific unemployment rate rose from 3.7 to 4.5 percent. At the same time, roughly 1.15 million people were still employed in ICT occupations subject to social-security contributions, two percent more than the year before.

So the picture is not “IT is collapsing.”

It is closer to this: employment is still growing over the longer term, while new hiring and open positions have weakened substantially in the short term, and demand is shifting more toward highly qualified specialists and experts.

Those data alone do not establish an AI effect.

For juniors, the mechanism is nevertheless relevant: if companies are already hiring less in a weak market and at the same time become more productive with senior-plus-agent configurations, it becomes economically easier for an entry-level opening never to be created at all.

The labor market can shrink from the bottom without mass layoffs

Public debate about AI and labor markets often looks for spectacular events.

Which occupation was replaced? How many people were laid off? Where is the big automation wave?

Part of the effect may be much less visible.

A position that is never advertised appears in no layoff statistic.

An additional junior team that is never created because an existing team became more productive generates no termination letter.

That is exactly why the Stanford finding on hiring rather than separations is so interesting.

The hypothesis is then not:

AI suddenly destroys the profession of software developer.

It is:

Part of the adjustment may happen because certain entry opportunities simply stop being created.

For an individual company, that can be entirely rational in the short term.

Over the longer term, however, it creates a different economic question.

Senior + Agent is a very rational short-term combination

An experienced developer brings an already-developed mental model.

They recognize unclear requirements earlier. They know common failure patterns. They can distinguish between a pretty diff and a robust solution. They know where additional tests are needed and where a proposed architecture is disproportionately complex.

A capable agent complements exactly that developer with fast execution.

The result is an extremely attractive combination:

experience
+
high generation speed
+
automated tests
+
fast iterations
=
high short-term output

From a company’s perspective, the question “Why should I hire a junior instead?” is therefore not absurd.

A junior requires onboarding, mentoring, and review. And many of the tasks through which beginners used to contribute productively – clearly bounded implementations, standard CRUD, tests, simple refactorings – are also among the tasks where coding agents are improving particularly quickly.

No moral judgment is needed.

In the short term, Senior + Agent can simply be the economically more attractive unit.

The problem begins only if we calculate exclusively in the short term.

A junior task produces two things

A junior task produces at least two outputs.

Junior Task
├ Software today
└ Experience tomorrow

The first component is obvious. An endpoint, form, test, migration, or bug fix gets produced.

The second component appears in almost no delivery metric.

The junior learns how the system works.

They make a mistake and understand why it was wrong. In review, they learn why an apparently elegant abstraction becomes problematic later. They debug a production failure. They see how a business exception shapes a technical architecture. Over time, they take over larger parts of the system and more responsibility.

A junior task does not only produce software. It produces experience.

If AI takes over the first production process more efficiently, that can be excellent in the short term.

But if the second production process disappears with it, a long-term cost item emerges that is absent from the token calculation.

Experience is Human Capital

Experience cannot be fully replaced by reading documentation.

It develops through repeated confrontation with real systems:

Implement
→ Make mistakes
→ Debug
→ Receive review
→ Experience production
→ Make decisions
→ Take responsibility
→ Build system understanding

That does not mean juniors need to write CRUD manually for ten years before they become “real developers.”

That idea would be more an argument against progress.

If AI takes over routine work, training does not need to be kept artificially inefficient. The more interesting question is:

How do people build systemic engineering judgment when an increasing share of the former practice surface is automated?

Agents may even help with that. They can explain code, demonstrate alternatives, simulate reviews, and accelerate learning loops.

But that does not happen automatically simply because the agent takes over the task completely.

A company can buy experience – a market has to build it

This is one of the most interesting long-term questions in agentic economics for me.

An individual company can say:

We do not need juniors. We hire experienced developers.

That can be completely rational.

The next company can make the same decision.

And the next one too.

Eventually a coordination problem emerges.

A company can buy experience. A labor market can only build it.

When a company hires a senior, it buys the result of years of investment: education, mentoring, projects, mistakes, reviews, and responsibility – often financed by other companies.

If many organizations simultaneously hire fewer juniors, develop fewer mid-level engineers, and primarily want to buy finished experience, the labor market could produce less experience over the long run.

That is explicitly a hypothesis, not a prediction that there will suddenly be no seniors left in 2036.

Markets react. Training models change. New roles emerge. AI itself can become a learning tool.

The economic question remains:

Anyone who wants to buy only finished experience depends on someone else having financed it first.

That is classic human-capital economics under new technological conditions.

Turnover does not make capability building pointless

A common objection to investing in junior talent is that employees leave companies anyway.

That is true and still not a convincing counterargument.

As a rough reference point, the U.S. Bureau of Labor Statistics reports a median tenure with the current employer of 4.3 years for computer and mathematical occupations in January 2024. That is not a global software-developer turnover rate and says nothing about remote versus office work. It only shows that multi-year tenure is by no means unusual, while lifetime attachment cannot be assumed either.

Working conditions also influence retention. A peer-reviewed Nature randomized controlled trial with 1,612 employees of a Chinese technology company found that two work-from-home days per week reduced the resignation rate by roughly one third without measurable deterioration in performance or promotion. That is a strong result for this particular setting, but likewise not a universal “remote employees stay X years” formula.

People change employers.

Yet during their employment, domain knowledge, system knowledge, relationships, and productivity still accumulate.

Turnover is not an argument against capability building. It is a reason organizations must continuously reproduce capability.

A company that buys experience exclusively from the outside makes itself dependent on a market whose supply side it does not help develop.

Junior development is an investment, not charity

That is why the junior question should not primarily be framed morally.

“Companies have a social obligation to hire juniors” is a different argument.

From an economic perspective, this is already sufficient:

Developing junior talent is an investment in future capability.

That investment creates company-specific knowledge, domain understanding, technical succession, team relationships, and an internal pipeline for responsibility.

Of course, a trained employee can leave.

A database can also be migrated, a server depreciated, and a platform replaced. Investments never provide guaranteed eternal value.

The relevant question is whether expected value over time exceeds the investment.

And Agentic Work changes exactly this calculation: the direct production value of simple junior tasks may decline while their training value remains.

That means training has to become a more explicit part of the production system than before.

Training has to change

It would make little sense to respond to AI by demanding “more traditional coding.”

If agents can generate code reliably, people should learn to work productively with that reality.

But that means more than adding another “Prompt Engineering” course.

Systematic reviews of GenAI use in programming education show a mixed picture. AI can support learning performance, feedback, and problem solving. At the same time, risks arise from overreliance, incorrect outputs, and differences in people’s ability to verify generated solutions in the first place. A 2025 review of 40 empirical studies therefore emphasizes deliberate pedagogical integration and appropriate assessments. A Heliyon review published in September 2026 across 76 empirical studies similarly concludes that AI is especially useful when combined with scaffolding, process-oriented feedback, and human judgment.

For software engineering, this could mean placing more emphasis on capabilities needed across the entire production flow: problem understanding, requirements, system models, architecture, debugging, review, trade-offs, security awareness, verification, and end-to-end responsibility.

Coding does not disappear in this model.

Someone who cannot read code cannot review it well. Someone who has never experienced why certain implementations fail has little basis for engineering judgment.

But the weighting can shift.

I also see this gap in my private environment. A family member received exceptionally positive feedback for the architecture structure of a semester project. The understanding required for that structure did not, however, come primarily from the degree program, but to a significant extent from informal conversations about architecture.

That is a personal anecdote, not evidence about the quality of any particular university program.

For me, it simply illustrates the question: if technical execution becomes increasingly easy to obtain, how systematically do we actually teach the ability to recognize and design good systems?

From specialist to end-to-end understanding

One potentially positive development of Agentic Work is that developers may again work more broadly across a complete flow.

DB
→ Service
→ API
→ Client
→ View

That does not mean every frontend developer suddenly has to become a database, backend, networking, security, and UX specialist.

Agents can take over part of the technological execution.

What matters more then is the meta-model.

A frontend developer may not need to implement a CQRS-oriented or hexagonal microservice at the same depth as a backend specialist. But if they work on one with an agent, they should be able to recognize what responsibilities the layers have, where domain logic belongs, how the contract works, and whether the generated code is structurally plausible.

The same applies in the other direction.

Agentic Work can broaden end-to-end responsibility without abolishing expert knowledge.

Security, cryptography, and highly critical business domains in particular are poor candidates for the idea that a generalist can suddenly replace any depth with enough AI support.

Agentic Work can broaden technical execution without making deep expertise obsolete.

Perhaps a strong future team consists precisely of people with a broad system model and specialists who provide true depth where it is economically or safety-critical.

Software Engineering is shifting

I am currently deliberately trying to write as little code myself as possible. Not because I consider coding worthless, but because I want to understand how far a well-designed agentic flow can really go.

That is already changing my own work substantially. Less time goes into direct code production. More goes into architecture, solution design, constraints, reviews, Agent Infrastructure, and system understanding. I do not experience that as retreating from software engineering, more as a shift within it.

The agent may implement the method. I increasingly try to ensure that it can only work inside a space where sensible solutions are likely in the first place. That includes clear module boundaries, tests, architecture rules, and mechanical checks. But it also includes the ability to recognize when an automatically generated solution builds green while still embodying the wrong abstraction.

I now regard Agentic Work as an extraordinarily powerful tool. At the same time, I would not claim to have mastered it perfectly. Precisely for that reason, the difference between two ways of working becomes increasingly obvious to me: AI as faster autocomplete is one thing. An engineering system in which agents independently analyze, implement, test, and review is another. The second approach requires substantially more upfront investment. But it also creates a completely different cost structure.

Two economic balance sheets

That brings us to two separate but connected economic views.

The first is operational.

It asks:

What does a verified, accepted change cost?

That calculation includes model prices, input and output, caching, reasoning, tool calls, failed runs, retries, tests, review, Human Active Time, and Coordination Time.

Its endpoint is:

Cost per Accepted Change

The second view is strategic.

It asks:

What capabilities does the organization possess after this change – and which capabilities is it building for the future?

That balance sheet includes Agent Infrastructure, system understanding, domain knowledge, junior development, specialist knowledge, and the ability to continuously reproduce capability.

The second balance sheet does not make the first one less important.

A company has to operate economically in the short term. An agentic flow that creates no measurable value does not become sensible merely because it is supposedly strategically important in the long run.

Conversely, a quarterly calculation can also be incomplete if it counts every eliminated junior task as pure efficiency gain and assigns a value of zero to building future experience.

The interesting economics of Agentic Work live precisely between those time horizons.

Token
↓
Agent Run
↓
Successful Run
↓
Accepted Change
↓
Engineering Capability
↓
Business Value
↓
Future Capability

Models will keep becoming cheaper, more expensive, and cheaper again. Capability will rise. Some tasks will become almost completely automatable. Others will prove surprisingly resistant. New ways of working will emerge, and some of today’s debates about token prices will probably look in retrospect about as relevant as old debates over the price of individual gigabytes of cloud storage.

The economic mechanism nevertheless remains.

Code generation is only one production step.

Token consumption is only an activity measure.

Inference cost is only one cost item.

An accepted change is not yet Business Value.

And short-term productivity is not the only capability an engineering organization has to produce.

Agentic Work can be enormously economical. My own experience strongly suggests that today’s systems already enable substantial productivity gains. At the same time, empirical research shows that the magnitude depends heavily on context and that large local speedups can become much smaller along the full production system.

So the correct conclusion is neither:

AI makes software development extremely cheap.

nor:

AI is actually too expensive.

The more interesting statement is more sober:

The economics of Agentic Work only emerge in the full system of model cost, verification, human attention, reusable infrastructure, and long-term capability building.

Operationally, we should ask:

What does a verified, accepted change cost us?

Strategically, we should also ask:

What capability are we building in the process – and what might we be dismantling?

Code gets cheaper. Software engineering does not automatically follow.

Anyone who wants to understand the economics of Agentic Work therefore has to calculate further than the token price.

The token appears on the bill. The value – and some of the long-term costs – appear elsewhere.

Sources and context

The concrete pricing and product information in this article is a snapshot from September 10, 2026. Model prices, product names, usage limits, and benchmarks in particular change quickly. The economic calculation models are therefore intended to remain useful even after some individual numbers become outdated.

OpenAI – ChatGPT Rate Card / token-based pricing.
Current prices for GPT-5.6 Sol, GPT-6 Astra, and other models, plus notes on long context, Fast Mode, and regional processing.
https://help.openai.com/en/articles/20001415

OpenAI – GPT-5.6 Sol.
Model price, promotional rate, context window, current coding evaluations, and efficiency notes.
https://developers.openai.com/api/docs/models/gpt-5.6-sol
https://openai.com/index/gpt-5-6/

OpenAI – GPT-6 Astra.
Current price plus coding and agentic evaluations. Important: Terminal-Bench 4.0 should not be read as a direct historical continuation of older Terminal-Bench versions.
https://developers.openai.com/api/docs/models/gpt-6-astra
https://openai.com/index/gpt-6-astra/

OpenAI – Understanding and counting tokens.
Reasoning tokens are not visible as answer text, but count toward output usage and are billed as output tokens.
https://help.openai.com/en/articles/4936856-w

Anthropic – Claude 3.5 Sonnet, Claude 3.7 Sonnet, Sonnet 4.5, Sonnet 4.6, and Sonnet 5.
Primary sources for the pricing and coding evaluations used in the historical comparison. The individual SWE-bench results differ in harness, prompting, thinking budget, and test-time compute in some cases and are therefore not treated as one uniform time series in this article.
https://www.anthropic.com/news/3-5-models-and-computer-use
https://www.anthropic.com/news/claude-3-7-sonnet
https://www.anthropic.com/news/claude-sonnet-4-5
https://www.anthropic.com/news/claude-sonnet-4-6
https://www.anthropic.com/news/claude-sonnet-5

Peng et al. – “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”.
Randomized experiment with a clearly bounded JavaScript task; the Copilot group completed the task 55.8 percent faster.
https://arxiv.org/abs/2302.06590

Cui et al. – “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”.
Three randomized field experiments with 4,867 developers in total; pooled estimate of 26.08 percent more completed tasks. Published in Management Science in 2026.
https://doi.org/10.1287/mnsc.2025.00535

Demirer, Musolff, Yang – “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”.
NBER Working Paper 35275, revised in September 2026. The current version uses data from more than 500,000 GitHub developers and reports a strong attenuation for autonomous coding agents from commit-level effects to actual releases. Working paper, not a final causal consensus.
https://www.nber.org/papers/w35275

METR – Developer Productivity Studies.
The early-2025 RCT with 16 experienced open-source developers and 246 tasks found a 19 percent slowdown. METR now describes this result itself as a historical snapshot. The 2026 follow-up pointed more toward acceleration, but selection and measurement issues prevented a reliable precise effect estimate.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
https://metr.org/blog/2026-02-24-uplift-update/

Stanford Digital Economy Lab – “Canaries in the Coal Mine?”.
Revised August-2026 version based on ADP payroll data. Among 22- to 25-year-olds in highly AI-exposed occupations, employment is substantially lower relative to less exposed peers; the difference appears mainly through lower hiring. The authors explicitly describe the results as descriptive early indicators rather than a causal AI estimate.
https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

LinkedIn Economic Graph – U.S. Software Engineer Talent Landscape / February 2026.
Context for weak U.S. SWE hiring and the weaker direct pipeline from CS graduates into traditional software-engineering roles.
https://economicgraph.linkedin.com/content/dam/me/economicgraph/en-us/PDF/us-software-engineer-talent-landscape-2026.pdf

German Federal Employment Agency – ICT labor market 2025.
Around 13,000 registered ICT vacancies on annual average, 22 percent fewer than the previous year; unemployment rate 4.5 percent; at the same time roughly 1.15 million employees subject to social-security contributions in ICT occupations.
https://www.arbeitsagentur.de/presse/2026-24-arbeitsmarkt-in-der-informations-und-kommunikationstechnik-ikt-im-spannungsfeld-konjunkturelle-schwaeche-trifft-auf-strukturellen-wandel

U.S. Bureau of Labor Statistics – Employee Tenure 2024.
Median of 4.3 years with the current employer for “Computer and mathematical occupations”; not a software-developer-specific or remote-tenure metric.
https://www.bls.gov/news.release/tenure.t06.htm

Bloom et al. – “Hybrid working from home improves retention without damaging performance”.
Randomized experiment with 1,612 Trip.com employees; two work-from-home days per week reduced the resignation rate in the experiment by around one third.
https://doi.org/10.1038/s41586-024-07500-2

Nathaniel et al. – “Literature Review on the Integration of Generative AI in Programming Education”.
Systematic review of 40 empirical studies on GenAI integration in programming education.
https://doi.org/10.1007/s40593-025-00524-3

“Artificial intelligence in programming education: A systematic review …”, Heliyon 2026.
Systematic review of 76 empirical studies on AI in programming education.
https://doi.org/10.1016/j.heliyon.2026.e45361

Qwen – Qwen3.8-27B.
Official model weights, Apache 2.0 license, and model information.
https://huggingface.co/Qwen/Qwen3.8-27B

NVIDIA – DGX Spark.
Official hardware specifications: 128 GB unified memory, 273 GB/s memory bandwidth, 140 W GB10 TDP, and 240 W power supply. NVIDIA raised MSRP to $4,699 in February 2026.
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
https://forums.developer.nvidia.com/t/2-23-2026-price-change-announcement/361713

Qwen3.8-27B on DGX Spark – community benchmark.
The 25.1 tok/s used in the model calculation is an explicitly labeled community measurement for NVFP4 + MTP, not a manufacturer guarantee. Other runtime configurations can produce substantially different values.
https://axforge.ai/benchmarks/qwen-3-8-dgx-spark/

OpenAI – ChatGPT Pro tiers.
Current U.S. product tiers: Pro $100 with 5× and Pro $200 with 20× usage compared with Plus. These allowances are not guaranteed API token quantities.
https://help.openai.com/en/articles/9793128

Stephen Monsell – Task switching (2003); Simon Y. W. Li, Farah Magrabi, and Enrico Coiera – A systematic review of the psychological literature on interruption and its patient safety implications (2012).
Review articles on task switching and interruptions, including switch costs, resumption time, and errors. They support the limited cognitive mechanism described in the article, not a concrete productivity estimate for coding agents. Task switching; Review of interruptions.