DEV Community: Ricardo Medeiros

2.1 Billion Tokens for $19: DeepSeek V4.1 Flash Changed the Economics of Agentic Software Engineering

Ricardo Medeiros — Mon, 14 Sep 2026 10:14:11 +0000

A week ago I published a fairly absurd number:

612.9 million tokens for $28.35.

That was DeepSeek Harness (DSH) + DeepSeek V4 Pro working on LovelaceSharp, a real C# numerical computing project, over a visible four-day development window.

The repository received 45 commits across 193 files.

The point of that article was not that 612 million tokens are somehow inherently productive.

It was that the economics of a persistent coding agent look very different from the economics suggested by raw token counts.

DSH had a 98.94% input cache-hit rate.

It was processing enormous amounts of context, but very little of that context was novel expensive input.

Then I kept running the experiment.

And DeepSeek released V4.1 Flash.

The numbers got considerably more stupid.

From September 10 through September 12, my actual provider export for deepseek-flash shows:

Metric	V4.1 Flash
API requests	12,253
Cache-hit input	2,123,399,808
Cache-miss input	14,976,005
Output	16,114,788
Total tokens	2,154,490,601
Input cache-hit rate	99.30%
API cost	$19.22
Blended cost / 1M processed tokens	$0.00892

Yes.

2.15 billion tokens. Nineteen dollars.

And before anyone starts typing "tokens are not productivity" again:

I agree.

So let's look at what happened to the software.

Where the Previous Article Stopped

The previous benchmark ended around September 5.

At that point LovelaceSharp already had arbitrary-precision arithmetic, optimized big-integer algorithms, typed N-dimensional arrays, DSP, a scripting language, a browser IDE, Native AOT support, benchmarks and a Lean reference formalization.

The project was already well beyond a toy.

But most of the work was still fundamentally numerical infrastructure.

What happened afterward was a much larger expansion of scope.

From the last September 5 commit to the current HEAD, the repository moved forward by:

166 commits.

During that period LovelaceSharp acquired an actual symbolic mathematics stack.

Not a SymPy wrapper.

A native one.

The work included:

immutable hash-consed symbolic expression DAGs;
canonical addition, multiplication and powers;
exact rational arithmetic;
assumptions with three-valued logic;
conditional rewriting with explicit side conditions;
symbolic differentiation;
limits and series, including Laurent behavior;
symbolic integration;
polynomial arithmetic;
factoring and square-free decomposition;
real-root isolation;
equation solving;
parametric solution families;
Gröbner bases;
polynomial-system solving;
symbolic matrices;
conditional matrix inversion and linear solving;
CSE and Horner optimization;
complex symbolic/numeric evaluation;
a typed computational IR called MathIR;
scalar and vectorized compiled evaluation;
structured result types instead of prose results;
symbolic inspection in Studio;
an agent-facing structured execution protocol;
differential comparison against SymPy;
and a significantly larger correctness infrastructure around all of it.

This is the part I think matters when discussing agent economics.

The $19 did not buy "2.1 billion tokens."

Tokens are an implementation detail.

It bought access to a software production process that could keep expanding the product while simultaneously expanding the machinery used to verify the product.

That distinction is important.

Features Without Tests Are a Terrible Agent Benchmark

One of the easiest ways to make an AI coding demo look impressive is to count features.

LLMs are very good at producing code.

If I ask an agent to maximize visible feature count, it will happily oblige.

That does not mean I have created valuable software.

So I care much more about the relationship between feature growth and validation growth.

When the first symbolic kernel landed on September 8, it already came with 100 Symbolics tests plus executable documentation examples.

Then the API expanded.

Relations, solution families, polynomials, matrices, compilation and Gröbner bases landed.

The Symbolics suite moved past 200 tests.

Then came structured APIs, assumption hardening, semantic fixes, solver work, differential oracles, property tests, metamorphic tests, protocol tests and adversarial cases.

By September 10, one of the convergence commits reported:

1,971 passing tests across 14 suites.

The project kept going.

The most recent full local validation recorded:

5,655 passed.

0 failed.

0 skipped.

This is a much more interesting development curve than simply saying "the agent added a CAS."

The product surface grew, but the test surface grew with it.

And the tests are not all repetitions of ordinary unit assertions either.

The repository now contains things such as:

property tests
differential tests
metamorphic tests
golden protocol fixtures
cross-surface consistency tests
precision-boundary tests
Native AOT smoke tests
SymPy oracle comparisons
pre-fix regression controls
determinism tests
concurrency/isolation tests
budget/cancellation tests

That changes how I think about the cost of software development.

Testing Used to Compete Economically With Features

There is an uncomfortable reality in normal software development.

Every hour spent writing tests is an hour someone is not spending implementing the next feature.

Every alternative architecture you prototype and discard costs engineering time.

Every benchmark takes time to construct.

Every edge-case corpus has to be written.

Every independent implementation used as an oracle costs more time.

Every documentation example that is kept executable costs more time.

Every time you say:

let's test another 50 weird cases before shipping this

you are spending part of a finite engineering budget.

That doesn't mean those things aren't worth doing.

It means they have a real opportunity cost.

Agentic engineering changes this equation.

Suppose a feature takes an agent another 30 million tokens to implement, test, benchmark, revise and document.

At the effective blended price I observed with V4.1 Flash, 30 million processed tokens would cost roughly:

$0.27.

Obviously token cost is not the only cost.

There is compute outside the model.

There is CI.

There is human review.

There is specification.

There is the cost of accepting a bad implementation.

But the inference component has become almost comically small.

So the economically rational behavior changes.

Instead of asking:

Do we have time to build a differential oracle for this?

the answer increasingly becomes:

Why wouldn't we?

That is a much bigger change than cheaper autocomplete.

V4.1 Flash Changed the Curve Again

The previous article already showed strange economics with V4 Pro.

After publishing it, I have a useful second window.

From September 5 through September 9, the new export contains this V4 Pro usage:

Metric	V4 Pro
Requests	2,026
Cache-hit input	588,642,048
Cache-miss input	3,595,338
Output	2,847,970
Total tokens	595,085,356
Input cache-hit rate	99.39%
Cost	$20.96
Blended cost / 1M tokens	$0.0352

Then V4.1 Flash:

Metric	V4 Pro	V4.1 Flash
Total tokens	595.1M	2.154B
Requests	2,026	12,253
Cache-hit rate	99.39%	99.30%
Cost	$20.96	$19.22
Cost / 1M processed tokens	$0.0352	$0.00892

The workloads are not identical, so this is not a controlled intelligence benchmark.

I cannot conclude:

V4.1 Flash is 3.62× more productive than V4 Pro.

That would be nonsense.

What I can measure is the economic side.

Flash processed 3.62× more tokens for 8.3% less total money.

Its effective blended cost per processed token in this workload was approximately:

3.95× lower.

And the cache behavior barely changed.

V4 Pro: 99.39%.

V4.1 Flash: 99.30%.

So this isn't a story about DSH suddenly discovering caching.

It was already doing that.

The underlying inference economics changed.

One Billion Tokens in a Day Is Now Boringly Affordable

September 11 is the funniest row in the export.

That single day:

Metric	September 11
Requests	6,463
Cache-hit input	1,002,941,952
Cache-miss input	7,388,973
Output	8,712,583
Total tokens	1,019,043,508
Cost	$9.81

One billion tokens.

One day.

Less than ten dollars.

I don't think "billions of tokens" should become a goal.

If anything, that would be another terrible optimization target.

But it tells us something about capacity.

During the original benchmark, 612.9 million tokens over four days felt large enough to deserve an article.

V4.1 Flash processed around 1.66× that entire benchmark's token volume in one day.

For roughly one third of its inference cost.

This means the number of agent iterations you can economically throw at a software problem has changed dramatically.

This Is Where Software Engineering Economics Get Weird

Traditional software economics are dominated by expensive human time.

Imagine a feature requiring:

architecture
implementation
unit tests
integration tests
benchmarking
documentation
review
bug fixing

Those are competing allocations of engineering hours.

Now consider the same work under an agentic harness.

An implementation agent can write the feature.

Another execution can build the tests.

Another can benchmark competing implementations.

Another can compare results against an external oracle.

Another can examine the public API.

Another can search for boundary cases.

The original agent can then revise the implementation.

The harness retains the work that happened before.

And because the context is highly reusable, most of those repeated passes are being served as cache hits.

In my V4.1 Flash window, the API processed more than:

2.12 billion cached input tokens.

Against only:

14.98 million cache-miss input tokens.

That is the economic mechanism.

The agent doesn't have to repeatedly forget the repository in order to be cheap.

It can accumulate architecture, requirements, test results, previous failures and implementation decisions as reusable context.

Then revisit that context extremely cheaply.

This is almost the inverse of how we traditionally think about context efficiency.

The Marginal Cost of Engineering Work Is Collapsing Unevenly

This doesn't mean software development becomes free.

It means different parts of software development are becoming cheap at radically different rates.

Code generation is becoming cheap.

Test generation is becoming cheap.

Repository exploration is becoming cheap.

Documentation is becoming cheap.

Trying a second implementation is becoming cheap.

Throwing away a failed implementation is becoming cheap.

Running another agent over the same repository looking for problems is becoming cheap.

The human parts aren't falling at the same rate.

Understanding what the product should do is still expensive.

Making architectural decisions is still valuable.

Recognizing when a requirement itself is wrong still matters.

Reviewing the highest-risk assumptions still matters.

Taking responsibility for what ships still matters.

But this changes what human engineering time should be spent on.

I don't need to spend my time manually typing every test case.

I need to decide which properties actually matter.

I don't need to manually implement three algorithms just to compare them.

I need to understand whether the benchmark used to select between them means anything.

I don't need to manually write 100 edge cases.

I need to notice the class of edge case the agent forgot to generate.

That is a different allocation of engineering labor.

The Feature/Test Ratio Can Move in the Right Direction

There is a common fear around AI-generated code that I think is completely justified:

If generating code becomes 10× easier, won't we just create technical garbage 10× faster?

Yes.

If the only thing we make cheaper is feature generation.

But inference does not know that production code is special.

The same cheap intelligence that generates a feature can generate:

tests for it;
property checks;
fixtures;
benchmark harnesses;
differential comparisons;
migration tools;
documentation;
fuzz inputs;
failure reproductions.

This is where I think agentic SWE becomes much more interesting than "developer autocomplete."

The economically optimal feature can start carrying much more validation around it.

The first LovelaceSharp symbolic implementation didn't just add symbolic differentiation.

It added tests.

When Gröbner bases arrived, they came with invariant tests.

When MathIR gained vectorized execution, scalar-vs-batch equivalence was tested.

When arbitrary precision behavior expanded, results were compared against mpmath and SymPy.

When the runner became a machine interface rather than only a human CLI, its structured envelopes acquired their own contract tests.

When correctness bugs were found, regression cases were added.

The point is not that 5,655 tests prove LovelaceSharp is correct.

They don't.

The point is that test production is scaling with feature production instead of being economically squeezed out by it.

That is exactly what I want from agentic development.

The $40 Continuation Window

There is another way to look at the whole period after my previous article.

From September 5 through September 12, the provider export contains:

2.759 billion processed tokens.

14,304 requests.

$40.44 total cost.

During the corresponding repository continuation, LovelaceSharp moved 166 commits beyond the September 5 boundary.

I don't think cost-per-commit is a serious productivity metric.

Commits are arbitrary.

An agent can trivially game that number by creating smaller commits.

But just to establish the scale, if I pessimistically charge every dollar in that provider window to LovelaceSharp, including usage that may not belong to it, that comes to:

about $0.24 of inference per commit.

Again:

That does not mean a software commit is "worth 24 cents."

It means inference has become such a small component of the economic equation that counting dollars per patch starts becoming almost silly.

The expensive question is whether the patches form useful software.

This Also Changes the Value of Failed Work

One of my favorite observations from the original benchmark was Newton division.

DSH implemented it because asymptotically it should beat Knuth division.

Then it benchmarked the result.

And discovered that the crossover was so far out that Knuth should remain the normal production path.

From a traditional project-management perspective, you could describe that implementation as partially wasted effort.

An engineer spent time implementing something primarily to discover that it should barely be used.

Under agentic economics, that interpretation makes less sense.

The failed hypothesis produced knowledge.

And the inference cost of getting that knowledge was tiny.

This effect gets stronger as inference gets cheaper.

You can afford to explore more branches.

You can implement competing designs.

You can benchmark them.

You can discard two and keep one.

You can ask an agent to prove its own optimization is useful before accepting the complexity.

That is closer to search than traditional implementation.

And search becomes much more attractive when each branch costs cents instead of engineer-days.

So What Is the Unit of Productivity?

Definitely not tokens.

Probably not commits.

Definitely not lines of code.

I suggested this in the previous article:

validated engineering work
──────────────────────────
      inference cost

I still like that.

But this second run makes me think the interesting economic unit may eventually become something closer to:

useful product capability × confidence
──────────────────────────────────────
          total engineering cost

Because an agent that implements ten features with weak validation may be economically worse than an agent that implements six features and surrounds them with enough tests, benchmarks and executable contracts that I can safely continue building on them.

Cheap generation increases the numerator.

Cheap validation increases the confidence multiplier.

Persistent cached context reduces the inference component of the denominator.

That combination is much more important than token efficiency in isolation.

I Am Not Claiming V4.1 Flash Is 4× Better

To be clear, this is still a case study.

I changed the model.

But the project also changed.

The tasks changed.

The harness evolved.

The later workload contains much more symbolic mathematics, validation and hardening.

The request distribution is different.

So the 3.95× reduction in blended token cost is an economic observation, not a model-quality benchmark.

DeepSeek claims V4.1 Flash exceeds V4 Pro on its agentic benchmarks, and the architecture is especially interesting for this workload: a 552B MoE with asymmetric activation, using only 8B active parameters on input and 16B on output. DeepSeek also says its KV-cache requirements are substantially smaller than the previous generation.

That architecture is almost comically aligned with DSH.

DSH is extremely input-heavy.

The Flash window contained:

2.138 billion input tokens.

Only:

16.1 million output tokens.

The vast majority of the workload is the model repeatedly reading accumulated engineering context.

Making input and cache reuse radically cheaper directly attacks the dominant term in the workload.

That matters much more to me than shaving a few tokens from a prompt.

What I Think Agentic SWE Actually Changes

The easy prediction about AI coding is:

software will be cheaper because programmers will write code faster.

I think that undersells the change.

The more interesting possibility is:

we will economically justify doing engineering work that was previously skipped.

More tests.

More alternative implementations.

More benchmarks.

More compatibility checks.

Conclusion

The first article was:

612.9 million tokens.

45 commits.

$28.35.

It convinced me that cache locality could make persistent agent workloads much cheaper than raw token counts suggest.

The continuation is:

2.759 billion additional processed tokens for $40.44.

166 commits beyond the September 5 repository boundary.

And, inside that period, the first three complete V4.1 Flash days alone were:

2.154 billion tokens.

12,253 requests.

99.30% input cache hit.

$19.22.

What came out the other end was not 2.1 billion tokens worth of chat.

It was a substantial expansion of a real software system: symbolic mathematics, exact rationals, Gröbner bases, system solving, MathIR compilation, structured machine-facing APIs, more numerical capabilities and a test/validation surface that eventually reached 5,655 passing tests.

That is the benchmark artifact.

The code is public.

The Git history is public.

The usage export is the bill.

And I think the economics are starting to point somewhere important.

For most of software history, implementation effort forced us to ration engineering ideas.

We rationed features.

We rationed tests.

We rationed prototypes.

We rationed benchmarks.

We rationed cleanup work.

We rationed experiments.

Agentic engineering does not remove the need for good engineers.

But it may remove a large part of the economic pressure that forced engineers to choose between many of those activities in the first place.

At $0.0089 per million processed tokens, I don't need my engineering agent to be token-efficient in the traditional sense.

I need it to turn cheap inference into useful, tested software.

That is a much more interesting optimization problem.

800 Million Tokens for $36: Benchmarking DSH + DeepSeek V4 Pro on a Real Codebase

Ricardo Medeiros — Sat, 05 Sep 2026 12:18:24 +0000

There is a problem with most benchmarks for coding agents: they are not software development.

They are useful, of course. Give an agent an issue, run a test suite, check whether the patch passes. SWE-bench and similar evaluations give us a standardized way of comparing models.

But this is not how I actually use agents.

I don't want an agent to fix a single isolated issue and stop. I want it to spend hours inside a codebase, understand the architecture, write requirements, implement things, run tests, benchmark alternatives, discover that its first idea was wrong, revise it, document what happened, and then use that new knowledge in the next task.

So, during the last few days, I accidentally created another kind of benchmark.

I gave DeepSeek Harness (DSH) + DeepSeek V4 Pro a real project and let it work.

The result was:

Metric	Result
Visible development window	Aug 31 → Sep 3
Git commits	45
Files changed	193
API requests	3,266
Tokens processed	612,923,681
Cache-hit input	600,885,248
Cache-miss input	6,458,427
Output	5,580,006
Input cache-hit rate	98.94%
API cost	$28.35

Yes.

612 million tokens. Twenty-eight dollars.

And before anyone starts typing "tokens are not productivity" into the comments: I agree.

That is exactly why the interesting part of this experiment is not the token count.

It is what happened to the repository.

The Project

The project is LovelaceSharp, my attempt to build an arbitrary-precision mathematical environment in C#.

It contains arbitrary-precision natural numbers, integers and real numbers, a scripting language, vectors and N-dimensional arrays, linear algebra, a web IDE, benchmarking tools and a Lean project for formally verifying the underlying arithmetic model.

This is a useful agentic workload because it is not a CRUD application.

There are plenty of opportunities for code that looks correct but isn't.

Arithmetic has edge cases. Numeric algorithms have crossover points. Performance changes can destroy correctness. Array views introduce aliasing and stride semantics. Precision can leak across sessions. Formal proofs can prove something subtly different from what the optimized production implementation actually does.

In other words:

bullshit has somewhere to hide.

That makes it a much more interesting test than asking an agent to add another REST endpoint.

Establishing the Boundary

I also got lucky with the Git history.

The old work on LovelaceSharp stopped on March 17 at commit 9b26f05. There was then no activity until August 31, when the new DSH-driven development started.

The comparison from that old baseline to the end of the visible burst contains:

45 commits across 193 changed files.

You can inspect the history and comparison directly:

So I am not counting the previous implementation as work performed by DSH.

That matters.

The benchmark isn't:

"Look at this entire repository an AI supposedly made."

It is:

"Here is the repository before this run, here is the repository after it, and here is the API bill during the days those changes landed."

My complete DeepSeek export spans Aug 30 through Sep 5 and contains roughly:

805.4M tokens
3,931 requests
$36.68 of spending

For the benchmark, however, I only attribute Aug 31 through Sep 3, because those are the dates represented by the visible development burst on main.

That leaves:

612.9M tokens and $28.35

associated with the 45-commit comparison.

So what did those $28 actually buy?

First: Replace the Core Number Representation

One of the largest changes was rewriting Natural, the arbitrary-precision unsigned integer implementation.

The previous representation was based around decimal BCD storage.

The new implementation moved the actual number representation to little-endian base-2^64 limbs.

That is already a reasonably dangerous refactor because essentially every numerical type above it depends on Natural.

The change included:

native carry/borrow arithmetic;
schoolbook multiplication;
Karatsuba multiplication;
Knuth Algorithm D division;
short division;
divide-and-conquer conversion between decimal and binary representations.

But the important part is what came with it.

DSH added tests specifically around limb boundaries and randomized differential testing against System.Numerics.BigInteger.

The differential suite covers arithmetic across multiple operand sizes and adversarial values around boundaries such as 2^64 and 2^128.

Relevant commit:

Rewrite Natural storage around 64-bit limbs

That is much more interesting to me than "the model knew Knuth division."

LLMs know algorithms.

The useful behavior is:

change representation
        ↓
identify new failure boundaries
        ↓
construct an independent oracle
        ↓
cross-check the implementation

That is engineering.

Then It Made Multiplication More Complicated — for a Reason

After moving to binary limbs, the agent added an exact two-prime Number Theoretic Transform multiplication path for very large numbers.

This wasn't simply:

NTT is asymptotically fast, therefore NTT everywhere.

It benchmarked the implementation against Karatsuba and introduced a dispatch threshold around 100,000 combined limbs, roughly the region where the NTT path actually started winning.

It also cross-checked multiplication against BigInteger at extremely large operand sizes.

Relevant commit:

Add NTT multiplication for huge Natural values

This distinction matters enormously when evaluating agents.

A coding model can produce complicated code all day long.

A useful engineering agent must understand that an asymptotically superior algorithm can still be the wrong implementation for almost every practical input.

And that became even more obvious with division.

Then It Implemented an Algorithm and Discovered It Should Barely Use It

DSH implemented Newton-reciprocal division with asymptotically better behavior for huge operands.

Then it benchmarked it.

And Knuth division won.

Not forever, but for a surprisingly long time.

The measured crossover put Newton at roughly the multi-million-decimal-digit range, so the production dispatcher retained Knuth below that region and only selected Newton for enormous inputs.

Relevant commit:

Add Newton reciprocal division and benchmark its crossover

This may be my favorite part of the experiment.

Because the workflow was essentially:

hypothesis
    ↓
implementation
    ↓
measurement
    ↓
"well... that didn't work as expected"
    ↓
revised implementation

I want more agent benchmarks to measure this.

Not whether the model knew Newton iteration.

Whether the agent was willing to prove itself wrong.

The Work Wasn't Limited to Big Integers

During the same development burst, Lovelace gained a typed-array abstraction with concepts such as:

ArrayValue
DenseArray<T>
dtype metadata
precision metadata
slices
strided views
a plugin-oriented kernel contract

The abstraction arrived with tests covering array layout and view behavior.

Relevant commit:

Introduce typed array abstractions

Then the scripting engine itself was migrated onto the typed representation, adding things such as:

promotion;
narrowing;
broadcasting;
slicing;
views;
empty-dimension behavior.

Relevant commit:

Migrate Suite to the typed array representation

Around the same period, the project also acquired a web IDE, Lovelace.Studio, over the common scripting engine.

The initial Studio work extracted the scripting language into a shared engine and built an ASP.NET Core + browser IDE around it.

Relevant commit:

Introduce Lovelace.Studio

A later change added isolated sessions, per-session precision, incremental computation, asynchronous progress and CodeMirror autocomplete.

Relevant commit:

Add isolated sessions and incremental evaluation

The point is not LOC.

The point is that the workload moved through:

numerical algorithms, language implementation, web tooling, concurrency, arrays, benchmarks and formal methods

without changing the overall agentic workflow or treating each category as a fresh synthetic benchmark.

That is much closer to the way I want an engineering agent to behave.

It Also Started Proving Things

Another part of the burst introduced Lovelace.Proofs, a Lean 4 project formalizing base-b arithmetic.

It covers representation, addition, subtraction, multiplication and division using core Lean.

Relevant commit:

Add Lean proofs for core arithmetic

There is an important caveat here.

The Lean proofs describe the digit-by-digit reference arithmetic.

The production Natural implementation was subsequently changed to binary limbs and gained optimized Knuth, NTT and Newton paths.

So saying:

"Lean proves the optimized implementation is correct"

would be wrong.

What we actually have is closer to:

a formally verified arithmetic reference model plus optimized production implementations checked through unit tests, boundary tests and differential testing.

I think that distinction is worth mentioning because this is another place where agentic development can become dangerous.

An agent can add formal verification and make a project look dramatically safer while proving something adjacent to the thing actually running.

The human still needs to understand the correspondence.

Now Let's Talk About the 612 Million Tokens in the Room

At first glance, this workload looks horrifyingly inefficient.

612,923,681 tokens in four days.

That is around 188K processed tokens per API request.

If your mental model of agent economics is:

tokens × normal input price = bill

this should have been expensive.

But that is not what happened.

Of the input sent during the benchmark window:

cache hit:   600,885,248
cache miss:    6,458,427

The resulting input cache-hit rate was:

98.94%.

For DeepSeek V4 Pro alone during the same period, it was even higher.

And this wasn't one anomalous gigantic request dominating the average. Across the complete development days, the provider-side daily numbers remained extremely cache-heavy.

DeepSeek supports automatic context caching for repeated prompt prefixes:

DeepSeek Context Caching documentation

That matters a lot for a persistent harness.

Long-running agent sessions naturally contain large stable prefixes:

previous prompts;
repository discoveries;
tool results;
architectural decisions;
earlier failures;
requirements;
test observations;
existing conversation state.

If the harness keeps those prefixes stable enough, the provider does not have to charge them like entirely novel input every time.

So the raw token count is enormous.

The novel expensive prefix is not.

Cache Hits Change the Economics Completely

The provider export records different prices for:

cache-hit input;
cache-miss input;
output.

For V4 Pro, cache-hit input in the export was priced at 1/30th of cache-miss input.

That is the part that makes the economics weird.

Using the actual pricing tiers recorded in my export, the DSH development window cost:

$28.35.

Now take exactly those same requests and make one artificial change:

pretend every cached input token had instead been charged as a cache miss, preserving the same observed price bands.

The cost would have been on the order of hundreds of dollars rather than tens of dollars.

For the complete Aug 30 → Sep 5 export, the observed bill was $36.68.

Using the same thought experiment, the equivalent bill without cache reuse is roughly $567.

So caching reduced the total bill by approximately:

93.5%

or around:

15.4×

for that complete export.

This is where I think the usual discussion about "token efficiency" becomes a little misleading.

DSH did not optimize this workflow by minimizing how many tokens it processed.

It processed a ridiculous number of tokens.

What made the economics work was that almost all of the input became cheap to revisit.

There is a fundamental difference between:

minimize context

and:

maximize reusable context.

For an agent doing sustained engineering work, the second strategy can be surprisingly attractive.

Context Can Become an Asset Instead of a Tax

Traditional context optimization tends to look like this:

large context
    ↓
summarize
    ↓
discard details
    ↓
keep prompt small

That makes sense when every input token is similarly expensive.

With strong prefix caching, another strategy becomes possible:

accumulate useful context
    ↓
keep the stable portion stable
    ↓
reuse it repeatedly
    ↓
pay mostly cache-read pricing

This does not mean "send everything forever."

Cached tokens still cost money.

Irrelevant context can still hurt:

attention;
latency;
model quality;
tool-selection quality;
reasoning focus.

A 99% hit rate can also become a vanity metric if the harness is repeatedly hauling 500K tokens it never needed.

So I would not propose:

cache hit rate = agent quality.

But I would absolutely propose:

cache locality is a first-class agent-runtime metric.

Because once an agent starts working for hours or days instead of answering isolated prompts, context reuse becomes an economic property of the architecture.

And This Is Why "$ per Million Tokens" Is the Wrong Agent Benchmark

My effective blended price during this development window was approximately:

$0.046 per million processed tokens.

That number sounds absurd because it includes hundreds of millions of cache reads.

But it also demonstrates why comparing agents using raw token consumption is increasingly questionable.

Suppose Agent A uses 10 million tokens and forgets half the repository every few turns.

Agent B processes 100 million tokens but 99 million of them come from stable cached context containing decisions, tests, observations, architectural constraints and previous failures.

Which one is more efficient?

You cannot answer that from token count.

Even cost alone does not answer it.

What actually matters is something closer to:

validated engineering work
──────────────────────────
      inference cost

And eventually:

validated engineering work
──────────────────────────
 human review time + inference cost

That second denominator is probably where things get uncomfortable.

The New Bottleneck Is Me

This experiment cost $28.35 in attributable inference.

The repository received 45 commits across 193 files.

The agent was able to move between:

formal proofs;
big-integer arithmetic;
array semantics;
benchmarking;
performance dispatch;
Native AOT work;
scripting-language behavior;
a browser IDE;
concurrency and session isolation.

At this point, shaving another five dollars from inference is almost irrelevant.

My problem is reviewing it.

Did an NTT edge case escape the differential tests?

Are array aliases correct under every non-contiguous view?

Does per-session precision really eliminate all shared-state races?

Do the Lean theorems correspond closely enough to the optimized code paths for the documentation to describe them accurately?

Those questions are now more expensive than generating another implementation.

And I think this is an important transition in agentic software development.

For a long time, generating code was the expensive part.

Then generating good code became the challenge.

With cheap models, aggressive caching and persistent harnesses, we may be moving toward another bottleneck:

How much machine-generated engineering can a human responsibly validate?

That is a very different problem.

So Is This a Benchmark?

Not in the SWE-bench sense.

There is no controlled comparison against Claude Code, Codex, Cursor or another harness.

There is no randomized task set.

I cannot derive:

"DSH is X times better than Claude Code"

from this experiment.

Anyone doing that from these numbers would be abusing the data.

It is better understood as a real-work agentic case benchmark.

It has a reproducible Git boundary:

9b26f05 → current DSH-era main

It has a public work product:

45 commits, 193 changed files.

It has provider-side usage data:

612.9M processed tokens, 3,266 requests.

It has provider-side cache accounting:

98.94% input cache hit.

And it has an actual bill:

$28.35.

Most importantly, the output is available for anyone to inspect.

You don't have to believe me that the work is good.

The code is the benchmark artifact.

Repository:

https://github.com/jjackbauer/LovelaceSharp

What I Would Measure Next

After seeing this run, I am much less interested in "tokens per task."

For sustained agentic engineering, I think the useful metrics are going to look more like:

cost per validated change;
percentage of agent changes surviving human review;
regression rate after integration;
human review minutes per accepted change;
cache-hit distribution;
uncached input per accepted change;
wall-clock time to accepted change;
benchmark improvements that survive independent reproduction.

Because a harness can cheat almost every superficial metric.

It can produce fewer tokens by forgetting things.

It can produce more commits by making tiny commits.

It can produce more code by generating garbage.

It can get a spectacular cache-hit rate by repeatedly sending irrelevant history.

It is much harder to cheat:

Did the software get materially better, did the changes survive verification, and how much did that cost?

That is the benchmark I care about.

Conclusion

I started looking at the usage dashboard because 800 million tokens for about $36 looked ridiculous.

It is ridiculous.

But the interesting result wasn't simply that DeepSeek V4 Pro is cheap.

The interesting result was understanding why this workload stayed cheap while maintaining enormous context.

DSH + DeepSeek V4 Pro effectively turned repeated context from one of the largest costs of agentic development into a heavily amortized resource.

During the cleanest observable development window, that meant:

45 commits.

193 files.

612.9 million processed tokens.

98.94% cache-hit input.

$28.35.

There are still plenty of things I don't trust without human verification.

There should be.

An agent writing formal mathematics and arbitrary-precision arithmetic should not earn trust because a dashboard has a nice green number.

But if we want to discuss the economics of agents seriously, I think we need to stop benchmarking them as expensive autocomplete.

Persistent agents behave differently.

Their context behaves differently.

And, apparently, their bills can behave very differently too.

You Probably Understood the Client Server Model Wrong

Ricardo Medeiros — Thu, 11 Dec 2025 15:19:31 +0000

Most developers intuitively grasp the client–server model. They know the backend must serve many users while the frontend runs a single isolated instance per person. The problem is not one of misunderstanding but of misapplied mental models.

Too often, frontend interaction patterns quietly seep into backend architecture. This happens almost invisibly: because a user clicks a button and waits, the backend endpoint is implemented to perform the entire workflow before returning.

Because the UI shows near-real-time progress, developers reach for WebSockets, SSE, or long-polling, assuming the backend must act with the same immediacy. As the interface suggests an atomic action, the backend is built to execute a full, complex sequence in a single synchronous request.

These decisions feel natural when thinking from the user outward, but they ignore the fact that frontend and backend systems live under radically different constraints. The frontend exists per user, per tab, per device. If it blocks or performs work synchronously, only one person is affected.

In the other hand, the backend is a shared computational surface, serving thousands of simultaneous users from a limited pool of machines. A blocking call that seems harmless in the UI becomes costly when multiplied by a large user base.

This distinction is critical. For lightweight operations—like fetching a user profile or toggling a setting—mimicking the frontend’s synchronous expectations is perfectly acceptable; the resource cost is negligible. The danger arises when we apply that same 'request-response' immediacy to complex business logic or third-party integrations.

When a heavy, valuable workflow is forced to fit inside the fragile lifespan of a simple HTTP request, the backend stops being a scalable coordinator and becomes a brittle bottleneck.

Consequently, a heavy workflow executed synchronously does not scale when many people trigger it at once. Frontend mental models make perfect sense for the UI layer but become harmful when projected onto the backend.

The first step toward correcting this misalignment is to visualize the structural asymmetry. Each user runs their own frontend instance, but a comparatively small set of backend servers must collectively serve all of them.

When design decisions assume parity between these layers, the backend becomes overloaded—not because of traffic volume alone, but because of how tightly the backend’s execution model is coupled to human interactions.

Frontend Per User, Backend Shared by Everyone

This diagram illustrates the heart of the issue: every user has a dedicated frontend instance, but all users share the backend. If backend routes mimic user-level workflows synchronously, they consume server resources as if each request were serving only that user.

This leads to patterns where backend operations are tied to the lifetime of an HTTP request or WebSocket connection, causing servers to hold open sockets, allocate memory, keep database transactions alive, or block worker threads while waiting for slow I/O. These patterns work fine when thinking like a single UI instance, but they collapse under real-world concurrency.

Even when developers use asynchronous programming constructs—such as async/await—the architecture remains synchronous if long-running work is still executed within the request lifecycle.

Architectural asynchrony is not achieved by non-blocking code alone; it comes from offloading work, decoupling the response from the completion of the operation, and treating the backend as a shared coordinator of workflows rather than a synchronous executor of user-driven commands.

The Shift Toward Asynchronous Endpoints

A backend that scales must adopt a different perspective: the purpose of an endpoint is not to “complete the job” but to “accept the job.” True asynchronous architecture emerges not from code-level semantics but from systemic decoupling.

The backend should perform only the minimal steps required to validate input, authenticate the caller, record the intent, and enqueue the real work elsewhere. It should return immediately—often with a 202 Accepted status—handing back a job identifier that the frontend can use to check progress.

This “accept, then process” pattern changes the nature of the system entirely. Instead of backend servers waiting idly during long-running operations, the work is delegated to background processors or workers that run independently of the request lifecycle. This frees backend capacity for new incoming requests, allowing the system to serve more users without proportional increases in server count.

Asynchronous Workflow Sequence

In this design, the backend no longer mirrors the interaction model of the UI. The frontend and backend operate on independent clocks: the UI can poll for updates at its own pace, and the backend can schedule work according to resource availability.

Polling, often dismissed as simplistic, becomes a powerful pattern for background workflows because it keeps servers stateless and scalable, avoids long-lived connections, and shifts the complexity of immediacy away from the backend.

Status Endpoints and Cache-Assisted Polling

When the frontend receives a job identifier, it begins periodically querying a /jobs/:id endpoint for status updates. This endpoint is simple by design: it retrieves the current state of a workflow from the database or, more efficiently, from a cache.

This pattern allows backend servers to remain fully stateless. As no request needs to wait for job completion, the backend can scale horizontally without sticky sessions or shared in-memory state. Caching enhances this model. A cache-aside pattern—where the API checks the cache first and falls back to the database only on a miss—is often sufficient for moderate traffic.

For larger systems, a write-through approach pays off: workers update both the database and the cache when job statuses change. This ensures that nearly all frontend polling requests hit the cache rather than the database, dramatically reducing load.

Status Endpoint Architecture

This architecture exemplifies how decoupled systems naturally scale. Backend servers focus solely on orchestrating requests and responding quickly. Workers and queues handle the heavy lifting. Polling reads mostly from cache. No part of the system depends on a long-lived user connection.

How Serverless Completes the Picture

Serverless platforms elevate this model by providing isolation and elasticity at the execution level. While backend servers remain stable and responsive, serverless functions scale independently based on event volume.

Each job can run in its own execution context without interfering with others, effectively giving the backend a burst capacity proportional to incoming workload rather than to the number of servers provisioned.

This division of responsibilities is transformative. Backend servers become thin control planes responsible only for coordination, while serverless workers perform compute-heavy or long-running tasks. Instead of scaling servers, the system scales events. When a thousand users submit jobs simultaneously, a thousand serverless functions can execute in parallel without any user blocking the backend.

Serverless architecture embodies the principle that the backend should not behave like the UI. Instead of executing workflows synchronously, backend servers delegate. Instead of waiting, they acknowledge. Instead of owning long-lived operations, they outsource them to stateless, ephemeral functions optimized for scaling.

A New Mental Model for Cloud-Native Backends

Reframing the backend begins with recognizing that frontend patterns should not dictate backend structures. The UI can wait; the backend must not. The UI can block; the backend must stay available. The UI serves a single human; the backend serves everyone simultaneously.

When dealing with simple CRUD-like operations that lack aggregated business logic, a synchronous model remains the simplest and most effective choice. However, when involving complex business logic, third-party integrations, or intensive traffic peaks, that same model creates a bottleneck. In those high-stakes scenarios, synchronous coupling leads to critical failures that can bring the entire system down.

Once this mental shift clicks, it becomes clear why asynchronous endpoints, polling, queues, workers, caches, and serverless execution represent not advanced architectural strategies but necessary correctives to an intuitive but incorrect assumption: that backend systems should behave like the interfaces that sit on top of them.

Backend architecture must reflect backend realities. Designing it with a frontend mindset is what leads to systems that stall, choke, or become expensive to operate. Designing it with asynchronous principles produces architectures that scale effortlessly, fail gracefully, and serve users far beyond what synchronous workflows could ever sustain.

Marked UUIDs Pattern

Ricardo Medeiros — Fri, 28 Jun 2024 20:24:40 +0000

Introduction

So, here I'm again. Writing after some time without doing anything like it, but I've decided to share this, because I think this solution saved a lot of work and problems that system could had. The context was this: my team was responsible for an application that was been integrated into a SAP system by another company, and, we had several PSP integrations to provide our services.

Some of this PSP test enviroments didn't work at all, they were flaky and inconsistant with responses and even the types of the response properties between the test and production environment. We needed to provide a way for the SAP consultancy to be able to test the functionalities of our plataform without the instability of the PSP test enviroment, and then, we decided to add a flag to mock the PSP response to be successfull (since it was the outcome that we were more interested in).

It was all great, untill we realized that we needed to test the refund functionality. Now what? As our application was built upon microsservices with domain segregation. We had an Anti-Corruption-Layer (ACL) between it and the PSP, so we had no idea of what was happening there. Both payment and refund were in the ACL, but it hadn't any persistance, as was built to be a facade between the third-party service provider and our domain. How could we determine if a payment was done in the actual service provider test environment or was mocked by our ACL?

Aproaches

Add a parameter in the response of the ACL indicating if this response is mocked or not;
Add a database in the ACL to save all the payments created, and if they were mocked or not.

Aditional Parameter

If we had chosen this path, it would require that the application consuming the ACL was changed, to consider this new information about mocking, then, this consuming application would need to save this in order to provide this information back to the ACL when refund were requested. It required to much development just to enable this, and it didn't add anything to our product, just it's testability experience.

Database in the ACL

Imagine this, a service that operated without databases in production would require one to work in test enviroment. I promptly refused, even not enjoying the first option, this was way worst. Not only would require aditional infrastructure, but also add futher complexity and latency to the system.

Avoinding these pains

So, I've started to think. How could I know this information without adding any furter infrastructure or adding parameters? Somehow, I needed to be able to split this register with the information that they already had. With that in mind, I've started to come up with a solution.

UUID - The Trojan Horse

Every transation would return an UUID that should be generated by the PSP (or not). Somehow mocking this information in a way that it would be differentiable from the PSP generated ID's wouldn't affect the transaction information, all the further information required would be maintained. With that in mind, I wen't on several experiments in order to make this possible, and that's how I've Achieved it:

Marked UUID

UUIDs are pseudo-random 128-bit identifiers that are often represented as 32 hexadecimal digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 (e.g., 123e4567-e89b-12d3-a456-426614174000).

UUIDv4

UUIDv4 is one of the most commonly used versions of UUIDs. It is designed to be a universally unique identifier generated using random or pseudo-random numbers. Here's a detailed overview of UUIDv4:

Characteristics of UUIDv4

Randomness: UUIDv4 relies on random or pseudo-random numbers to generate the unique identifier.
No External Information: Unlike other versions of UUIDs, such as UUIDv1 (which incorporates timestamps and MAC addresses), UUIDv4 does not include any external information about the generating system.
Simplicity: UUIDv4 is straightforward to implement because it only requires a good source of randomness.

Structure of UUIDv4

A UUIDv4 is a 128-bit value, typically represented as a 36-character string in the format 8-4-4-4-12, separated by hyphens.

Example UUIDv4

f47ac10b-58cc-4372-a567-0e02b2c3d479

Breakdown of UUIDv4

8 characters: Randomly generated 32 bits.
4 characters: Randomly generated 16 bits.
4 characters: Randomly generated 12 bits, and 4 bits for the version (0100 for version 4).
4 characters: Two or three bits for the variant (10x for RFC 4122), and - 13 or 14 randomly generated bits.
12 characters: Randomly generated 48 bits.

Marking UUIDv4

The process to mark this ID should be something that couldn't be done by an valid UUID generation, but It should be compatible with UUID implementations in order to be stored sucesfully, avoiding any changes outter the Anti-Corruption Layer code.

I've selected the last 12 characters section to mark the ID, but I needed for it to be unmistaken with real IDs, so I've devised this algorithm:

Take the ID without the last 12 characters and the hypens
Use a hash algorithm like SHA-256 to creat a mark
Grab the first 12 characters (48 bits) of the hash and replace the original generated 12 characters

That's it. Stupidly simple, works with the language implementation (in my case was golang) and was unmistaken with a real gerenated UUID. But how can we determine if an ID is marked? It is as simple as to create one:

Take the ID without the last 12 characters and the hypens
Use a hash algorithm like SHA-256 to creat a mark
Grab the first 12 characters (48 bits) of the hash and compare it to the IDs last 12, if they're equal, this ID was marked.

Solution

So, how did I've employed this to solve the problem? Simple, when I had the flag to mock the PSP responses enabled, I've returned at the payment endpoint the mocked response with an marked ID. In the refund endpoint, if the flag was enabled, I checked if the ID was marked, if so, I would return a mocked refund response. If not, I would make the PSP call, as this payment was created in the PSP enviroment.

Conclusion

If something you gotta do seems to require too much corromption to your application, look for alternative approaches to this problem and don't be afraid to try new things out!

Any sugestions, comments or corrections, fell free to reach me out at LinkedIn.

Ricardo MedeirosFollow

Staff Backend Engineer | AI Frist Migration @Context Forge

KAFKA + KSQLDB + .NET #1

Ricardo Medeiros — Tue, 30 Nov 2021 17:19:05 +0000

Hi, I'm Ricardo Medeiros, .NET back end developer @vaivoa, and today I'm going to walk you through using ksqlDB to query messages produced in kafka by a .NET/C# producer. For this example, I will be deploying my enviroment as containers, described in a docker compose file, to ensure easy reproducibility of my results.

The source code used in this example is avaliable here.

Services

First, let's talk about the docker compose environment services. the file is avaliable here.

.NET API Producer

Automaticaly generated .NET api with docker compose service

ksqldbdemo:
    container_name: ksqldbdemo
    image: ${DOCKER_REGISTRY-}ksqldbdemo
    build:
      context: .
      dockerfile: Dockerfile

This producer service needs the .NET generated dockerfile shown below:

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["ksqlDBDemo.csproj", "."]
RUN dotnet restore "ksqlDBDemo.csproj"
COPY . .
WORKDIR "/src/"
RUN dotnet build "ksqlDBDemo.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "ksqlDBDemo.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ksqlDBDemo.dll"]

ZooKeeper

Despite not been necessary since Kafka 2.8, ZooKeeper coordinates kafka tasks, defining controllers, cluster membership, topic configuration and more. In this tutorial, it's used the confluent inc. ZooKeeper image, due to it's use in the reference material. It makes Kafka more reliable, but adds complexity into the system.

zookeeper:
    image: confluentinc/cp-zookeeper:7.0.0
    hostname: zookeeper
    container_name: zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

Kafka

Kafka is an event streaming plataform capable of handling trillions of events a day. Kafka is based on the abstraction of an distributed commit log. Initialiy developed at LinkedIn in 2011 to work as a message queue, but it has evolved into a full-fledge event streanming platfmorm. Listed as broker in the services, is the core of this tutorial. It's configuration is tricky, but using it as follows worked well in this scenario.

 broker:
    image: confluentinc/cp-kafka:7.0.0
    hostname: broker
    container_name: broker
    depends_on:
      - zookeeper
    ports:
      - "29092:29092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: 'zookeeper:2181'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://broker:29092,PLAINTEXT_HOST://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1

ksqlDB

ksqlDB is a database built to allow distributed stream process applications. Made to work seamsly with kafka, it has a server that runs outside of kafka, with a REST API and a CLI application that can be run separatly and it's used in this tutorial.

ksqlDB Server

In this example, it's used the confluent inc image of the ksqlDB server, once more, due to it's widespread usage.

ksqldb-server:
    image: confluentinc/ksqldb-server:0.22.0
    hostname: ksqldb-server
    container_name: ksqldb-server
    depends_on:
      - broker
    ports:
      - "8088:8088"
    environment:
      KSQL_LISTENERS: http://0.0.0.0:8088
      KSQL_BOOTSTRAP_SERVERS: broker:29092
      KSQL_KSQL_LOGGING_PROCESSING_STREAM_AUTO_CREATE: "true"
      KSQL_KSQL_LOGGING_PROCESSING_TOPIC_AUTO_CREATE: "true"

ksqlDB CLI

The same goes for the ksqlDB CLI service, that also use the confluent inc image.

ksqldb-cli:
    image: confluentinc/ksqldb-cli:0.22.0
    container_name: ksqldb-cli
    depends_on:
      - broker
      - ksqldb-server
    entrypoint: /bin/sh
    tty: true

Kafdrop

Kafdrop is a Web UI for viewing kafka topics and browsing consumer groups. It makes kafka more accessible.

kafdrop:
    container_name: kafdrop
    image: obsidiandynamics/kafdrop:latest
    depends_on:
      - broker
    ports:
      - 19000:9000
    environment:
      KAFKA_BROKERCONNECT: broker:29092

Tutorial

Now it's the time that you have been waiting, let's make it work!

Enviroment

For this tutorial, you'll need a docker desktop installation, either it's on a Linux distribution or on Windows with WSL and git.

Cloning the project

A Visual Studio project is avaliable here, it has docker support and already deploys all the services needed for this demo in the IDE. However, you will be fine if you don't want or can't use Visual Studio. Just clone it, running the following comand on the terminal and directory of your preference:

 $ git clone https://github.com/jjackbauer/ksqlDBDemo.git

Use the following command to move to the project folder:

 $ cd /ksqlDBDemo

And, in the project folder, that contains the docker-compose.yml run the following command to deploy the services:

$ docker compose up -d

after this command, make sure that all services are running. Sometimes services fall, but it is okay. In order to see if everything is running ok, it's possible to see the services running in docker desktop, as shown bellow:

Or you can execute the following command:

$ docker ps

Which should output something like this:

CONTAINER ID   IMAGE                               COMMAND                  CREATED       STATUS       PORTS
  NAMES
b42ce9954fd9   ksqldbdemo_ksqldbdemo               "dotnet ksqlDBDemo.d…"   2 hours ago   Up 2 hours   0.0.0.0:9009->80/tcp, 0.0.0.0:52351->443/tcp   ksqldbdemo
0a0186712553   confluentinc/ksqldb-cli:0.22.0      "/bin/sh"                2 hours ago   Up 2 hours
  ksqldb-cli
76519de6946e   obsidiandynamics/kafdrop:latest     "/kafdrop.sh"            2 hours ago   Up 2 hours   0.0.0.0:19000->9000/tcp
  kafdrop
11c3a306ee01   confluentinc/ksqldb-server:0.22.0   "/usr/bin/docker/run"    2 hours ago   Up 2 hours   0.0.0.0:8088->8088/tcp
  ksqldb-server
07cef9d69267   confluentinc/cp-kafka:7.0.0         "/etc/confluent/dock…"   2 hours ago   Up 2 hours   9092/tcp, 0.0.0.0:29092->29092/tcp
  broker
3fa1b9a60954   confluentinc/cp-zookeeper:7.0.0     "/etc/confluent/dock…"   2 hours ago   Up 2 hours   2888/tcp, 0.0.0.0:2181->2181/tcp, 3888/tcp     zookeeper

WEB API

Now, with all services up and running, we can access the WEB API Swagger to populate our Kafka topics. The code is very simple and it's avaliable in the repository.

The WEB API swagger is deployed at http://localhost:9009/swagger/index.html. As shown in the image bellow, it has two endpoints and they create events that could be created by indepent microservices. One for creating an event that creates a userName in the system and another that takes an Id and generates a three digit code.

Then you can create an User with the user name of your choise, as shown:

And it will have an assigned unique Id, as demonstrated:

Now, you can get a three digit code for your user Id as displayed:

And a random code is generated for the selectd, as we can observe in the image that follows:

Kafdrop

We can use the kafdrop UI the check if everything is okay. Kafdrop is deployed at http://localhost:19000/.
There, you will find all the brokers and topics avaliable. It should look like this:

KSQL CLI

After all that, you'll be able to create your streams of data and query it using ksqlDB. On your preferential terminal, use the command:

docker exec -it ksqldb-cli ksql http://ksqldb-server:8088

Creating streams

And then you are in the ksql CLI and are free to create your streams and queries. First, let's create a stream for each one of our topics:

CREATE STREAM stream_user (Name VARCHAR, Id VARCHAR)
  WITH (kafka_topic='demo-user', value_format='json', partitions=1);

CREATE STREAM stream_code (Id VARCHAR, code INT)
  WITH (kafka_topic='demo-code', value_format='json', partitions=1);

Create a materialized view

You can join the client data with the most recent randomized code. to achieve this, you must create a materialized view table, that joins both streams as seen in the ksqldb script that follows:

CREATE TABLE currentCodeView AS
>   SELECT user.Name,
>   LATEST_BY_OFFSET(code.code) AS CurrentCode
>   FROM stream_code code INNER JOIN stream_user user
>   WITHIN 7 DAYS ON code.Id = user.Id
>   GROUP BY user.Name
>EMIT CHANGES;

Making a push query

After that, we can query this materialized view:

SELECT * FROM currentCodeView 
  EMIT CHANGES;

This push query keep on running until you hit cntrl+c to cancel it.

Conclusions

In this tutorial it's demonstrated that in a kafka + ksqlDB enviroment, you can make SQL queries and also join on data that comes from different events, which is one of most complexities envolved with microsservices systems. And it is what ksqlDB solves by enabling SQL operations over Kafka topics.
It's my goal to explore the possibilites allowed by this ecosystem and I hope to bring more knowledge on this topic in another articles here. Any sugestions, comments or corrections, fell free to reach me out at LinkedIn.

Ricardo MedeirosFollow

Staff Backend Engineer | AI Frist Migration @Context Forge

References

ksqlDB Quickstart
ksqlDB Overview
Kafka .NET Client
ksqlDB Documentation - Data Types Overview
KSQL and ksqlDB
Welcome to Apache ZooKeeper
What is ZooKeeper & How Does it Support Kafka?
What is Apache Kafka®?
ksqlDB - The database purpose-built for stream processing applications
An overview of ksqlDB
CREATE TABLE AS SELECT
How to join a stream and a stream
Time and Windows in ksqlDB Queries
Time operations

Disclaimer

A VaiVoa incentiva seus Desenvolvedores em seu processo de crescimento e aceleração técnica. Os artigos publicados não traduzem a opinião da VaiVoa. A publicação obedece ao propósito de estimular o debate.

KAFKA + KSQLDB + .NET #1

Ricardo Medeiros — Mon, 29 Nov 2021 20:13:06 +0000

The source code used in this example is avaliable here.

Services

First, let's talk about the docker compose environment services. the file is avaliable here.

.NET API Producer

Automaticaly generated .NET api with docker compose service

ksqldbdemo:
    container_name: ksqldbdemo
    image: ${DOCKER_REGISTRY-}ksqldbdemo
    build:
      context: .
      dockerfile: Dockerfile

This producer service needs the .NET generated dockerfile shown below:

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["ksqlDBDemo.csproj", "."]
RUN dotnet restore "ksqlDBDemo.csproj"
COPY . .
WORKDIR "/src/"
RUN dotnet build "ksqlDBDemo.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "ksqlDBDemo.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ksqlDBDemo.dll"]

ZooKeeper

zookeeper:
    image: confluentinc/cp-zookeeper:7.0.0
    hostname: zookeeper
    container_name: zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

Kafka

 broker:
    image: confluentinc/cp-kafka:7.0.0
    hostname: broker
    container_name: broker
    depends_on:
      - zookeeper
    ports:
      - "29092:29092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: 'zookeeper:2181'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://broker:29092,PLAINTEXT_HOST://localhost:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1

ksqlDB

ksqlDB Server

In this example, it's used the confluent inc image of the ksqlDB server, once more, due to it's widespread usage.

ksqldb-server:
    image: confluentinc/ksqldb-server:0.22.0
    hostname: ksqldb-server
    container_name: ksqldb-server
    depends_on:
      - broker
    ports:
      - "8088:8088"
    environment:
      KSQL_LISTENERS: http://0.0.0.0:8088
      KSQL_BOOTSTRAP_SERVERS: broker:29092
      KSQL_KSQL_LOGGING_PROCESSING_STREAM_AUTO_CREATE: "true"
      KSQL_KSQL_LOGGING_PROCESSING_TOPIC_AUTO_CREATE: "true"

ksqlDB CLI

The same goes for the ksqlDB CLI service, that also use the confluent inc image.

ksqldb-cli:
    image: confluentinc/ksqldb-cli:0.22.0
    container_name: ksqldb-cli
    depends_on:
      - broker
      - ksqldb-server
    entrypoint: /bin/sh
    tty: true

Kafdrop

Kafdrop is a Web UI for viewing kafka topics and browsing consumer groups. It makes kafka more accessible.

kafdrop:
    container_name: kafdrop
    image: obsidiandynamics/kafdrop:latest
    depends_on:
      - broker
    ports:
      - 19000:9000
    environment:
      KAFKA_BROKERCONNECT: broker:29092

Tutorial

Now it's the time that you have been waiting, let's make it work!

Enviroment

For this tutorial, you'll need a docker desktop installation, either it's on a Linux distribution or on Windows with WSL and git.

Cloning the project

 $ git clone https://github.com/jjackbauer/ksqlDBDemo.git

Use the following command to move to the project folder:

 $ cd /ksqlDBDemo

And, in the project folder, that contains the docker-compose.yml run the following command to deploy the services:

$ docker compose up -d

Or you can execute the following command:

$ docker ps

Which should output something like this:

CONTAINER ID   IMAGE                               COMMAND                  CREATED       STATUS       PORTS
  NAMES
b42ce9954fd9   ksqldbdemo_ksqldbdemo               "dotnet ksqlDBDemo.d…"   2 hours ago   Up 2 hours   0.0.0.0:9009->80/tcp, 0.0.0.0:52351->443/tcp   ksqldbdemo
0a0186712553   confluentinc/ksqldb-cli:0.22.0      "/bin/sh"                2 hours ago   Up 2 hours
  ksqldb-cli
76519de6946e   obsidiandynamics/kafdrop:latest     "/kafdrop.sh"            2 hours ago   Up 2 hours   0.0.0.0:19000->9000/tcp
  kafdrop
11c3a306ee01   confluentinc/ksqldb-server:0.22.0   "/usr/bin/docker/run"    2 hours ago   Up 2 hours   0.0.0.0:8088->8088/tcp
  ksqldb-server
07cef9d69267   confluentinc/cp-kafka:7.0.0         "/etc/confluent/dock…"   2 hours ago   Up 2 hours   9092/tcp, 0.0.0.0:29092->29092/tcp
  broker
3fa1b9a60954   confluentinc/cp-zookeeper:7.0.0     "/etc/confluent/dock…"   2 hours ago   Up 2 hours   2888/tcp, 0.0.0.0:2181->2181/tcp, 3888/tcp     zookeeper

WEB API

Now, with all services up and running, we can access the WEB API Swagger to populate our Kafka topics. The code is very simple and it's avaliable in the repository.

Then you can create an User with the user name of your choise, as shown:

And it will have an assigned unique Id, as demonstrated:

Now, you can get a three digit code for your user Id as displayed:

And a random code is generated for the selectd, as we can observe in the image that follows:

Kafdrop

We can use the kafdrop UI the check if everything is okay. Kafdrop is deployed at http://localhost:19000/.
There, you will find all the brokers and topics avaliable. It should look like this:

KSQL CLI

After all that, you'll be able to create your streams of data and query it using ksqlDB. On your preferential terminal, use the command:

docker exec -it ksqldb-cli ksql http://ksqldb-server:8088

Creating streams

And then you are in the ksql CLI and are free to create your streams and queries. First, let's create a stream for each one of our topics:

CREATE STREAM stream_user (Name VARCHAR, Id VARCHAR)
  WITH (kafka_topic='demo-user', value_format='json', partitions=1);

CREATE STREAM stream_code (Id VARCHAR, code INT)
  WITH (kafka_topic='demo-code', value_format='json', partitions=1);

Create a materialized view

You can join the client data with the most recent randomized code. to achieve this, you must create a materialized view table, that joins both streams as seen in the ksqldb script that follows:

CREATE TABLE currentCodeView AS
>   SELECT user.Name,
>   LATEST_BY_OFFSET(code.code) AS CurrentCode
>   FROM stream_code code INNER JOIN stream_user user
>   WITHIN 7 DAYS ON code.Id = user.Id
>   GROUP BY user.Name
>EMIT CHANGES;

Making a push query

After that, we can query this materialized view:

SELECT * FROM currentCodeView 
  EMIT CHANGES;

DEV Community: Ricardo Medeiros

2.1 Billion Tokens for $19: DeepSeek V4.1 Flash Changed the Economics of Agentic Software Engineering

Where the Previous Article Stopped

Features Without Tests Are a Terrible Agent Benchmark

Testing Used to Compete Economically With Features

V4.1 Flash Changed the Curve Again

One Billion Tokens in a Day Is Now Boringly Affordable

This Is Where Software Engineering Economics Get Weird

The Marginal Cost of Engineering Work Is Collapsing Unevenly

The Feature/Test Ratio Can Move in the Right Direction

The $40 Continuation Window

This Also Changes the Value of Failed Work

So What Is the Unit of Productivity?

I Am Not Claiming V4.1 Flash Is 4× Better

What I Think Agentic SWE Actually Changes

Conclusion

800 Million Tokens for $36: Benchmarking DSH + DeepSeek V4 Pro on a Real Codebase

The Project

Establishing the Boundary

First: Replace the Core Number Representation

Then It Made Multiplication More Complicated — for a Reason

Then It Implemented an Algorithm and Discovered It Should Barely Use It

The Work Wasn't Limited to Big Integers

It Also Started Proving Things

Now Let's Talk About the 612 Million Tokens in the Room

Cache Hits Change the Economics Completely

Context Can Become an Asset Instead of a Tax

And This Is Why "$ per Million Tokens" Is the Wrong Agent Benchmark

The New Bottleneck Is Me

So Is This a Benchmark?

What I Would Measure Next

Conclusion

Links

You Probably Understood the Client Server Model Wrong

Frontend Per User, Backend Shared by Everyone

The Shift Toward Asynchronous Endpoints

Asynchronous Workflow Sequence

Status Endpoints and Cache-Assisted Polling

Status Endpoint Architecture

How Serverless Completes the Picture

A New Mental Model for Cloud-Native Backends

Marked UUIDs Pattern

Introduction

Aproaches

Aditional Parameter

Database in the ACL

Avoinding these pains

UUID - The Trojan Horse

Marked UUID

UUIDv4

Characteristics of UUIDv4

Structure of UUIDv4

Example UUIDv4

Breakdown of UUIDv4

Marking UUIDv4

Solution

Conclusion

Ricardo MedeirosFollow

KAFKA + KSQLDB + .NET #1

Services

.NET API Producer

ZooKeeper

Kafka

ksqlDB

ksqlDB Server

ksqlDB CLI

Kafdrop

Tutorial

Enviroment

Cloning the project

WEB API

Kafdrop

KSQL CLI

Creating streams

Create a materialized view

Making a push query

Conclusions

Ricardo MedeirosFollow

References

Disclaimer