DEV Community: Daniel Balcarek

To Retry or Not to Retry? That Is the Question.

Daniel Balcarek — Thu, 08 Oct 2026 07:00:15 +0000

This is a submission for the Kaggle Benchmarking Challenge

Those who read my articles know that a lot of them are actually benchmarks of something. Mostly .NET related, but still, someone could say that this challenge should be pretty close to what I usually do.

The opposite was true.

Building a code benchmark and benchmarking AI models are two different worlds, so when I first saw this challenge, I had no idea what exactly I should benchmark. Comparing models on coding tasks felt too generic, and I didn't want to create a benchmark just for the sake of having one.

Then I looked at the topics of my last couple of articles. A lot of them were about APIs, resilience, failures, and how systems behave when something goes wrong. And that gave me an experiment idea: What if I benchmark AI models on one very simple question: To Retry or Not to Retry?

A 503 Service Unavailable does not automatically mean that retrying is safe. A POST request may already have been processed. An idempotency key can completely change the answer. A timeout may happen before the server receives anything or after it has already changed some state.

So the HTTP status code alone is often not enough. The model has to understand the whole situation.

What I Benchmarked

The idea is simple. I prepared several API failure scenarios containing information about the request, the response, and some additional context. The model has to return two things:

a decision: YES, NO, or YES_AFTER_DELAY
a one-sentence explanation of why

For example:

POST /payments
503 Service Unavailable

An idempotency key was supplied and the API guarantees
duplicate requests with the same key are not processed twice.

Retry?

A developer will probably immediately say:

YES_AFTER_DELAY

The important part is not only the 503. The context tells us that an idempotency key was supplied and repeated requests with the same key will not process the payment twice. But will an AI model notice the same thing? And more importantly, what happens when the scenario is less obvious?

For this small experiment, I prepared scenarios where the answer depends on details such as HTTP method, status code, idempotency, rate limiting etc.

Every model gets the same response format:

Decision: YES | NO | YES_AFTER_DELAY
Reason: <one sentence>

For scoring, I only use the Decision. This keeps the benchmark simple and deterministic. The Reason does not affect the score. I collect it because it can show whether the model actually understood the scenario or simply arrived at the correct answer for the wrong reason. That also makes the benchmark easy to compare between models. Each scenario has an expected decision, so the final result can simply be calculated as the percentage of retry decisions the model got right.

But why benchmark this at all?

Imagine that you are integrating an external service and want to make the call more resilient. In today's world of AI-assisted coding, there is a very good chance that a coding agent will do the work. The AI can easily generate a retry policy. The more interesting question is: Will it retry the right requests? Because retrying something that should not be retried can be much worse than not retrying at all.

That's what I wanted to measure. Now let's have a look at the scenarios.

Scenarios

I prepared 14 scenarios, each based on an actual task used in the Kaggle benchmark. Originally, all of them were part of the article, but that made it too long for a small experiment. So I decided to move the full scenarios into a standalone app, where you can browse every task together with its expected answer and explanation. And if you want to try them yourself first, there is also a test for humans. After all, why not benchmark some humans too? 😁

Try the human benchmark or browse all scenarios: To Retry or Not to Retry?

Here are the scenarios used in the experiment:

Safe Payment Retry - A payment request fails with 503 Service Unavailable, but an idempotency key guarantees that retrying cannot create a duplicate payment.
Unsafe Payment Retry - A payment request returns 503 Service Unavailable with Retry-After, but there is no idempotency key, so retrying could create a duplicate charge.
Idempotent PUT - A PUT request is sent successfully, but the connection is lost before the response arrives.
Rate-Limited Order - An order request is rate-limited before processing and returns 429 Too Many Requests with Retry-After.
Payment Details Conflict - A multi-step payment flow reaches /payments/details, which returns 409 Conflict with transient-error: false.
Non-Idempotent PATCH - A PATCH request increases inventory, but the connection is lost before the client knows whether the change was already applied.
Idempotent DELETE - A session deletion request is sent, but the connection is lost before the response arrives.
Service Unavailable - A GET request receives 503 Service Unavailable together with a Retry-After header.
Stale Resource Version - A resource is updated by another client, so a PATCH using an old ETag fails with 412 Precondition Failed.
Rate Limit Without Retry-After - A safe GET request repeatedly receives 429 Too Many Requests, but the server does not provide a Retry-After header.
I'm a Teapot - A coffee request receives the legendary 418 I'm a Teapot response.
Eventual Consistency - A newly created resource immediately returns 404 Not Found when another service tries to use it.
Expired Filter Workflow - A temporary filter times out several times and eventually returns 404 Not Found, so the original filter can no longer be used.
Cached Cart Options - A request for cart options fails with 504 Gateway Timeout, but a recently expired cached response is still available through stale-if-error.

Models Tested

Picking the models was pretty straightforward. First, I picked models I use a lot while working: GPT-5.6 Luna and GPT-5.6 Sol. From my experience, Luna is very efficient. It makes more mistakes than Sol, but it also uses significantly fewer tokens.

Then I added Gemini 3.7 Flash and Gemini 3.1 Pro Preview. I’ve used both quite a lot for text generation and CSS styling.

I also included Claude Sonnet 5 and Claude Haiku 4.5. I used Claude a lot for coding before, but these days I’ve mostly switched to GPT-5.6 because it feels more efficient for my workflow.

Lastly, I added GLM-5 and DeepSeek-R1 mostly out of curiosity to see how well they would perform.

I also tried to include Grok, but I immediately hit 404 Not Found errors with both Grok 4.5 and Grok 4.6, so they are not included in the results.

The goal wasn’t to test every available model, but to compare a mix of models I already use with a few I was curious about.

Findings

Okay, first let's have a look at the leaderboard and the results from the first run.

We can see that the best model, with a score of 1.00, was GPT-5.6 Sol, followed by Gemini 3.7 Flash with one mistake. Then came four models with two mistakes each, DeepSeek-R1 with three, and Claude Haiku 4.5 finished last with five.

When we look closer, we can see that most of the models made a mistake in the Unsafe Payment Retry task. The task itself is tricky because of the Retry-After header, but repeating that request could result in a duplicate charge. Only GPT-5.6 Sol and Gemini 3.1 Pro Preview answered correctly. The rest of the models returned something similar to:

Decision: YES_AFTER_DELAY
Reason: The server explicitly requests waiting 10 seconds before attempting the request again.

So most of the models fell into the trap of following the obvious HTTP signal, even though it conflicted with the wider context. Retry-After says “retry,” but a payment without idempotency says “maybe don't.” And to be honest, I am glad that most of the models failed. A small win for the author, who can still trick AI sometimes. 😄

I was also surprised that some models failed on tasks with idempotent HTTP methods: Idempotent PUT and Idempotent DELETE. But they did not fail completely. Most of them answered YES_AFTER_DELAY because they assumed a temporary network issue that could be resolved after a delay.

These YES versus YES_AFTER_DELAY cases show that a model can understand that retrying is safe but disagree about when to retry. That is different from misunderstanding the scenario. For version 2, I could therefore allow multiple valid Decision values for some scenarios. So in these cases, AI actually trained me a little.

Three Runs, Not Just One

That was only the first run, but I didn't want to build the whole experiment around a single run, so I ran the same benchmark two more times to check model stability and collect more data.

Model	Run 1	Run 2	Run 3	Avg.
GPT-5.6 Sol	14/14	14/14	13/14	13.67
Gemini 3.7 Flash	13/14	13/14	13/14	13.00
Gemini 3.1 Pro Preview	12/14	12/14	13/14	12.33
GLM-5	12/14	13/14	12/14	12.33
Claude Sonnet 5	12/14	12/14	12/14	12.00
GPT-5.6 Luna	12/14	12/14	12/14	12.00
DeepSeek-R1	11/14	10/14	10/14	10.33
Claude Haiku 4.5	9/14	9/14	9/14	9.00

Overall, the results were actually quite stable. Out of the 112 model-scenario combinations (8 models × 14 scenarios), 102 had the same correct/incorrect outcome in all three runs, which is about 91%. But the interesting part is that the same score did not always mean the same behavior. Some models were stable in the number of correct decisions while changing which scenarios they got wrong. A score of 12/14 in all three runs does not necessarily mean that the model made the same decisions every time.

This was especially visible in Expired Filter Workflow, where four models changed their result between runs: GPT-5.6 Sol, Gemini 3.1 Pro Preview, GLM-5, and DeepSeek-R1. Even GPT-5.6 Sol, which scored 14/14 in the first two runs, changed its answer in the third run from YES to YES_AFTER_DELAY. It still decided that the request should be retried, but disagreed about when. This is exactly the type of scenario that made me question whether exact YES versus YES_AFTER_DELAY scoring is always the right approach.

The additional runs also made the Unsafe Payment Retry finding much stronger. It was answered correctly only 6 times out of 24 attempts, just 25%. Even more interestingly, the result was completely consistent across runs. GPT-5.6 Sol and Gemini 3.1 Pro Preview got it right all three times, while the other six models missed it in every run. So this looks less like random model variation and more like a systematic trap in how the models interpreted the scenario.

On the other hand, seven of the 14 scenarios were answered correctly in all 24 attempts. The straightforward retry cases were therefore not really what separated the models. The differences started to appear when retry timing, wider context, or multi-step state became important.

Model Efficiency

Now let's have a look at efficiency. I will use the graph from the third run because the models ended up in roughly the same areas of the chart across all three runs.

GPT-5.6 Luna seems to be the most efficient model, and I am not surprised. I mostly use it at work because it is cheap and usually gets me close to the final solution.

Claude Haiku 4.5 is also in the efficient corner, but it had the worst results of all the tested models and was still more expensive than GPT-5.6 Luna.

The rest of the models are in the upper-right corner, and I was really surprised that DeepSeek-R1 ended up as the second most expensive model. So I looked at its output and found that DeepSeek-R1 answered with anywhere from 4,000 to 9,000 characters, even though it was supposed to answer only with Decision and Reason. All of the other models followed that instruction, so in this case the cost difference wasn't only about token pricing, but also about how well the model followed the requested output format.

What I Learned

When I designed the experiment, I was actually worried that the scenarios would be too easy for today's AI models. The results showed that this is not always the case. Yes, I could definitely improve the benchmark, especially the ambiguity between YES and YES_AFTER_DELAY. But even the strongest models still made mistakes once the decision depended on more than just the obvious HTTP signal. Retry decisions in real systems are not always simple. AI can definitely help us reason through the difficult cases, but the wider context still matters, and blindly following the model's answer can be risky.

My Benchmark

To Retry or Not to Retry? Benchmark

Kaggle was completely new to me and, to be honest, I am glad that I discovered it through the DEV.to challenge. I expected the setup to be much more complicated, but creating this small experimental benchmark directly in the UI was surprisingly straightforward. I will definitely explore Kaggle more, especially after seeing how much there is to explore beyond traditional ML competitions.

Polly Introduces an Open Source Maintenance Fee

Daniel Balcarek — Thu, 24 Sep 2026 07:07:21 +0000

A few weeks ago, I wrote about open-source projects moving toward paid or dual-licensing models, and whether AI is accelerating that shift.

Code got cheap while maintenance didn't

Daniel Balcarek

Jul 30

From Open Source to Paid Product: Is AI Accelerating the Shift?

#discuss #ai #opensource #programming

3 min read

Now Polly, one of the most popular .NET resilience libraries, is taking a slightly different approach.

Polly is introducing an Open Source Maintenance Fee (OSMF). The source license stays the same and Polly remains open source, but companies earning at least $20,000 from a product or project using Polly will be required to pay $20/month per organization for its maintained releases.

It's an interesting approach to the open-source sustainability problem. You can read the Polly announcement.

OSMF itself is actually an interesting model for open-source maintainers. Instead of changing the open-source license or putting the source code behind a commercial license, maintainers can charge a small maintenance fee for organizations using their maintained releases in revenue-generating products.

GitHub Sponsors can be used to collect the fee, with projects able to define their own pricing or tiers. The source code itself still remains available under its open-source license.

You can read more on the OSMF page.

In Polly's case, $20 per month - $240 per year, is a pretty small amount for a company generating at least $20,000 from a product using it. The administrative side might actually be more annoying for some companies than the price itself. We all know how it works in corporate when it comes to project license purchases, right? 😄

I find this especially interesting because it's another possible answer to the problem I wrote about earlier: how do you fund long-term open-source maintenance without simply turning the project into a commercial product?

What do you think about OSMF? Or do you know another interesting approach to making open-source projects sustainable in the AI era?

API Performance Testing: How to Design Realistic Tests

Daniel Balcarek — Thu, 17 Sep 2026 06:56:32 +0000

Most of us have heard the term performance testing, whether before releasing a big new feature, launching a new application or simply checking whether an application can handle a specific load.

Performance tests help us understand how our application behaves under load and whether it can handle the expected pressure. However, they need to be designed properly. Otherwise, the results can be misleading and lead us to the wrong conclusions.

Properly designed performance tests, on the other hand, can help us identify bottlenecks, understand the limits of our application and give us more confidence before a release.

In this article, we will first look at the basic concepts and different types of performance tests. Then we will move to the more practical part: how to design realistic test scenarios, how to determine the load our application should handle, how to deal with external services and how closely our test environment should match production.

The goal is not just to generate a large number of requests, but to create performance tests that actually tell us something useful about how our application will behave in the real world.

Basic Definition
- Types of Tests
How to Properly Design Performance Tests
- Defining the Expected Load
Performance Testing and External Services
Environment Configuration
Metrics and Results
Summary

So, let's start with the basic definition and different types of performance tests.

Basic Definition

We can summarize performance testing as a non-functional software testing method that evaluates an application's speed, stability, scalability and responsiveness under a specific workload.

To simplify it, let's use an API as an example. We prepare tests that call the endpoints we want to test under load, usually in a specific order that represents how the application is actually used. The main idea behind performance testing is to avoid releasing an application that is not prepared for the expected load.

Poor performance can lead to production outages, slow response times, or situations where the application is unable to process a job within the required time. All of these problems can eventually lead to lost customers, lost revenue, or damage to the product's reputation.

We can divide performance tests into different types depending on their configuration, purpose, and the metrics we want to observe.

Types of Tests

I think the picture says it all, but let's briefly describe each type:

Load tests verify how the application behaves under an expected or normal level of traffic. The goal is usually to confirm that the system can handle the required number of users or requests while keeping acceptable response times, error rates, and resource usage.

Stress tests push the application beyond its expected limits to find out where it starts to degrade or fail. They help us identify the maximum capacity of the system and observe how it behaves when resources such as CPU, memory, database connections, or threads become exhausted.

Endurance (Soak) tests run the application under sustained load for a longer period of time. Their purpose is to uncover problems that may not appear during shorter tests, such as memory leaks, connection leaks, resource exhaustion, or performance degradation over time.

Spike (Peak) tests simulate a sudden and significant increase in traffic. They help us verify how the application reacts to rapid changes in load and whether it can recover once the traffic returns to normal.

Volume tests focus on how the application behaves when it needs to process or work with a large amount of data. For example, we may test how database queries, imports, exports, or batch operations behave when the data volume is much larger than usual.

Scalability tests verify how the application's performance changes when we increase the workload and add more resources. The goal is to understand whether the system can scale efficiently, for example by adding more application instances, CPU, memory, or database capacity.

You don't necessarily need to implement a completely different test for each type. In many cases, you can reuse the same performance test scenario and change its configuration depending on what you want to measure, for example, the number of concurrent users, duration, request rate or workload pattern. You then observe different metrics depending on the goal of the test.

Not every application needs every type of performance test either. Some applications may mainly need load and stress tests, while others may benefit more from load and spike tests. It really depends on the application's requirements and, more importantly, on how users actually use it.

How to Properly Design Performance Tests

Properly designed performance tests are very important because, most of the time, we don't want to simply fire requests at random endpoints. That usually doesn't tell us much about the real behavior of the application or where its bottlenecks are.

What has worked well for me over time is identifying typical user behavior and simulating it in performance tests. For example, imagine an e-commerce application with an ordering system.

A typical user might:

Search for a few products.
Add products to the shopping cart.
Go through the checkout process.
Complete the payment.

Instead of testing each endpoint in isolation, I would design a performance test that simulates this whole flow and calls the same endpoints that the frontend normally calls.

Another example could be a business application with multiple types of users, where each user type has different permissions and uses the application differently. In that case, we can design a typical workflow for each user type and call the API endpoints in the same order that the frontend does. The benefit of this approach is that we simulate realistic user behavior. We can then change the test configuration: for example, by increasing the number of concurrent users, while keeping the same realistic workflows.

Another example could be API-to-API communication. Imagine that we have a POST endpoint followed by a GET endpoint. In that case, we can simulate different input parameters and request patterns under a specific load and observe how the system behaves.

Let's say we have designed our user paths. There are still a few important things we should consider when building the actual test flow. The image below summarizes some of the key ideas:

Real users don't click as fast as a performance test can send requests, so we should introduce realistic think time between operations.
Not every user follows the same path. In an e-commerce application, some users complete an order, while others only browse products or add items to the cart and return later. We should therefore simulate multiple user paths with different behavior.
Users usually don't all connect at exactly the same moment, so for a normal load test we should ramp up the load gradually.

A realistic user journey tells us what to test. The next question is how much load the system needs to handle.

Defining the Expected Load

Designing a realistic workload is only one part of the job. Before running the test, we also need to define what a successful result actually looks like. Not every application needs to handle 1,000 requests per second. Every system has its own expected workload and performance requirements.

For example:

Expected load: 150 RPS

p95 < 400 ms
p99 < 1 s
Error rate < 0.5%
Required throughput maintained
No continuously growing queues/connections

So how can we determine those numbers?

Let's return to our e-commerce example. Many applications have periods when traffic is significantly higher than usual. For an e-commerce application, this could be Christmas, Black Friday, or another major sales event. If the company already has good observability, historical production metrics can give us a useful starting point. We can check tools such as Grafana and determine the peak request rate, number of concurrent users, order volume, CPU usage, memory consumption, and other relevant metrics. We can then estimate future load. For example, if we expect traffic to grow by 10% next year, we may decide to test the system with an additional safety margin above that expected load.

Another way to estimate the required load is to start from a business requirement. For example, let's say the business expects our e-commerce application to process 10,000 orders during a two-hour peak period. We can look at a typical order flow and estimate how many HTTP requests are generated while a user searches for products, adds or removes items from the cart, goes through checkout and completes the order. If one completed order generates, for example 20 requests on average, then 10,000 orders mean roughly 200,000 requests during those two hours.

From there, we can calculate the average request rate:

200,000 requests / 7,200 seconds ≈ 28 requests per second

This gives us an average of roughly 28 RPS. It does not mean that 28 RPS should automatically become our test target. This calculation only estimates the traffic generated by completed order flows. Real application traffic will usually be higher because browsing, abandoned carts, background requests and other user journeys also contribute to the total workload. Real traffic is also rarely distributed evenly, so we should account for shorter traffic peaks and add an appropriate safety margin.

This approach gives us another way to estimate the required load when reliable production metrics are not available, showing that we can derive performance targets from both technical data and business requirements.

Performance Testing and External Services

External services require special attention during performance testing.

In some cases, we can mock an external service because we simply don't need or want to test it for several reasons. A good example is a paid API behind our endpoint, such as an LLM API or another paid third-party service. Cost is a valid concern because during performance testing our application may generate a large number of requests in a relatively short period of time.

Another scenario is when we simply don't need to call the external API at all. For example, it could be a simple reference-data API or a payment provider whose performance is outside the scope of our test. Instead, we can replace it with a controlled dependency using a tool such as WireMock and return the responses we expect during the test. This allows us to focus on the performance of our own application without having the external service's performance, rate limits or availability influence the results and make it harder to identify the actual bottleneck.

On the other hand, if communication with the external service is an important part of the system's real-world performance, we may want to test it separately or include it in the performance test.

So, whether we mock an external service should depend on the behavior we want to simulate and what exactly we want to measure.

Environment Configuration

Environment configuration is another important part of performance testing because, ideally, we want our performance test environment to be as close to production as possible. If the environment differs significantly from production, the results can become misleading, especially when we want to estimate how the application will behave under real production load.

So, what should we configure?

First, the application itself should use the same or very similar configuration as production. The server or cluster where the API is running should also have comparable CPU, memory, scaling rules and other resource limits.

The same applies to the database. It is not only about using similar database resources, though. We should also avoid testing against an almost empty database. The amount and distribution of data can have a significant impact on performance. Under high load, CRUD operations, joins, filtering, and sorting can behave very differently when tables contain millions of rows compared to just a few test records. Indexes, query execution plans, statistics and caching can all behave differently depending on the size and structure of the data.

For that reason, the test database should contain a realistic amount of representative data whenever possible.

We should also pay attention to caching configuration, for example Redis or in-memory caching. A different cache configuration, or testing with a permanently warm cache, can produce results that do not represent real production behavior.

Network conditions are another important factor. For example, if an external service is mocked locally, requests may complete almost instantly, while the real service in production could add tens or hundreds of milliseconds of network latency. Depending on what we want to measure, we may need to simulate this latency to get more realistic results.

And finally, there is the load generator itself. This one is easy to forget. The machine generating the load must have enough CPU, memory, network capacity and available connections to generate the required workload. Otherwise, the load generator can become the bottleneck instead of the application we are actually testing.

Metrics and Results

Once we run our performance tests, we need to evaluate the results and usually create some form of report. The metrics we focus on depend on the type of test, because different test types answer different questions.

Let's return to our e-commerce application and say that we decided to run both load and stress tests.

For a load test, we already know the expected workload, for example a specific number of requests per second or concurrent users. Now we want to verify that the application can handle this load while maintaining acceptable performance.

Some of the most important metrics are:

Response time, especially percentiles such as p95 or p99.
Error rate — what percentage of requests failed.
Throughput — whether the application actually processed the expected number of requests.
Resource usage — CPU, memory, database connections, connection pools and other relevant resources.

For example, if the p95 response time of a particular endpoint is much higher than expected, we can start investigating where the bottleneck is. Similarly, if the error rate exceeds our acceptable limit, we need to find out which requests are failing and why.

For a stress test, our goal is slightly different. We intentionally increase the load beyond the expected level and try to find the point where the application starts to degrade. Here, we watch how response times and error rates change as the load increases, together with CPU, memory, database connections, queues and other limited resources. We are looking for the point where the system becomes saturated, starts producing too many errors or can no longer maintain the required throughput.

It is also useful to observe how the application behaves after the load decreases. A system that slows down under extreme load but recovers afterwards behaves very differently from one that remains stuck or requires a restart.

The image below shows the metrics we monitored in our examples and highlights why we need to look at multiple graphs together to identify a specific bottleneck or saturation point.

The final report should therefore not contain only a single number such as average response time. It should connect the generated workload with latency, throughput, errors and resource utilization so that we can understand not only whether the application failed to meet our expectations, but also why.

Summary

In this article, we covered some performance testing basics and then focused on how to design tests for real-world scenarios.

The key is to understand how the application is actually used, prepare a realistic test environment, generate a representative workload and monitor the right metrics. When these parts are designed properly, performance tests can give us useful information about bottlenecks, system limits and overall application behavior under load.

There are already many great articles explaining performance testing theory and individual test types. My goal here was not to repeat all of that, but to look at performance testing from a more practical point of view and show how I approach designing realistic tests.

In the end, a performance test is only useful when its workload, environment and metrics are realistic enough to make the results meaningful.

How I Smashed a Bug in a Shared Authentication Library

Daniel Balcarek — Wed, 05 Aug 2026 06:58:57 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

This happened a while ago at one of the corporations where I worked.

I was working on a web application as a full-stack developer, so I was responsible for both the frontend and the backend.

Because the corporation was huge, there were several libraries and services shared across multiple teams and maintained by dedicated developers. It was basically open source inside a corporation. 😄

And of course, we used some of those libraries and services, because why reinvent the wheel, right?

So, after we released the first version of our web application, an interesting bug appeared.

When a user opened the application in multiple browser tabs, authentication would sometimes randomly break in one of them. Once that happened, the tab could not recover until the user pressed F5 or closed it completely.

Interesting.

As the senior developer on the team, I took the bug and started investigating.

After some time and a lot of attempts, I found that when the frontend tried to refresh the authentication token, it received a 403 Forbidden HTTP response, and the authentication flow broke completely.

So I played around with session storage and local storage in Chrome and tried changing the authentication configuration. It did not help much, but one thing was clear: the bug appeared to be inside the shared frontend authentication library.

Okay.

I collected all the logs and everything I had learned about the bug and went to the frontend team responsible for maintaining the authentication library.

After an hour-long discussion, they concluded that it was not their fault because the backend team maintaining the authentication service was not supposed to return that particular response code.

Yes, the frontend library and the backend authentication service were maintained by completely different teams.

I was not fully convinced, but there were more of them. 😁

So I collected all the logs again and went to the backend team.

We had another discussion and found that they were returning a valid response code because the frontend authentication library was sending a refresh token that had already been invalidated. The underlying problem was a race condition between multiple tabs. One tab refreshed the token and invalidated the previous refresh token while another tab was still trying to use it.

Okay...

So, once again, I grabbed all the logs and went back to the frontend team.

And in case you are wondering why the two teams did not simply communicate with each other, both teams gave me approximately the same answer:

This is a problem in your application, so your team has to solve it.

Back to the frontend team.

I presented the backend team’s conclusion, but they were still not convinced.

At that point, I was starting to get a little angry, so I created a single ticket, added both teams to it, and included all the logs, requests, responses, timestamps, and everything else I had collected.

Weeks passed.

Conversations continued in the ticket and in chat.

But the bug resolution still looked far, far away.

So I decided to arrange a meeting for everyone involved.

And finally, something happened.

During the meeting, we agreed that the problem was in the frontend authentication library and that the frontend team would fix it.

Success!

Or so I thought.

Two weeks later, while testers and users were getting increasingly angry because the application randomly failed to refresh authentication tokens, the frontend team came back with their final conclusion:

They were unable to reproduce the problem.

And users should not open the application in multiple tabs.

Until that moment, opening multiple tabs had been considered a perfectly normal user flow...

At that moment, I closed the ticket, completely removed the corporate frontend authentication library from our project, and reimplemented the entire client-side authentication flow directly against the existing corporate authentication service.

The main changes were in the Angular HTTP interceptor and the token refresh flow. I updated the interceptor to handle authentication-related responses, including 403 Forbidden, without leaving the entire tab stuck in a broken state.

I also reworked how refreshed tokens were handled and stored in session storage. Invalidated tokens and failed refresh attempts were now handled explicitly instead of causing the authentication flow to stop completely.

Yes, it took two days and one night. And yes, I took a few ideas from the corporate authentication library, because otherwise it would have taken much longer. 😄

But I only have one set of nerves.

And you know what?

From that moment on, it worked like a charm. And whenever another bug appeared, it was fixed immediately because, this time, we actually owned the code.

And that is my Bug Smash story where corporate life can sometimes be slightly ridiculous, and fixing one bug can mean rewriting the entire feature.

From Open Source to Paid Product: Is AI Accelerating the Shift?

Daniel Balcarek — Thu, 30 Jul 2026 06:40:31 +0000

I think many of us have already noticed that a growing number of open-source projects and libraries are moving towards commercial or dual-licensing models.

In the .NET ecosystem, several widely used libraries have taken this path over the past year or so. AutoMapper and MediatR introduced commercial editions under a dual-licensing model, Fluent Assertions began requiring a paid licence for commercial use with version 8, and MassTransit 9 became a commercial product.

These libraries were widely used in .NET applications and I mean widely used. Many projects treated them almost as a standard part of the ecosystem.

Now, the same change is reaching the frontend world. PrimeTek recently announced that future major versions of PrimeNG, PrimeReact and PrimeVue will no longer be released as open source.

All these projects were widely adopted, and many commercial applications depended heavily on them. Their licensing changes were primarily driven by the cost of long-term maintenance, but this raises a broader question:

Is AI also changing the world of open source?

You have probably already read many articles about code inflation. With AI, we can generate a huge amount of code in a very short time, even if the quality is sometimes questionable.

The same thing is happening in open source. Maintainers can now receive more AI-generated issues, pull requests and feature requests than they can realistically review. Producing code has become cheaper, but understanding, testing and maintaining that code still requires significant human effort. Maintainers can become overwhelmed very quickly.

AI may also discourage some developers from publishing their work publicly. Even small experiments, educational repositories and proof-of-concept projects can become training material for large language models. Some authors may therefore decide to keep their repositories private because they do not want AI companies learning from their work without permission, attribution or compensation.

Licensing creates another difficult question. Imagine that an author spends months building and publishing a project under the GNU GPL. An LLM reads the code and documentation and then helps create a competing closed-source implementation in a fraction of that time.

Proving that an AI-generated implementation was influenced by GPL-licensed code may be almost impossible for an individual maintainer.

Security is another concern. AI makes it easier to generate contributions, but it also makes it faster to discover vulnerabilities and incorrect code. Of course, finding vulnerabilities is generally a good thing. AI can help improve security and identify problems that might otherwise remain unnoticed. However, there is another side to this. Attackers can use the same tools to analyse publicly available source code, discover vulnerabilities much faster and exploit them for their own benefit. Without AI, this kind of analysis could require considerable time, expertise and effort.

None of these problems started with AI. Open-source maintainers have struggled with funding, burnout, cloud providers and commercial exploitation for years. However, AI may be accelerating all of these problems very quickly.

I am curious whether the next generation of developers will still be willing to publish their work in the same way. Even if much of the code is generated by AI, it will still require human effort to make it reliable, maintainable and useful.

Open source will probably not disappear. However, we may see more projects moving towards stricter licensing, free-to-use products with closed source code, or completely commercial development.

What do you think?

What about other major ecosystems, such as Java or Python? Is the same thing happening there too?

And if you were starting a valuable project today, would you still release it as open source?

How AI Endpoints Change the Traditional API Flow

Daniel Balcarek — Thu, 23 Jul 2026 06:59:35 +0000

As a backend developer, I have built hundreds of endpoints, so the typical endpoint flow is deeply ingrained in how I think about web applications. But when I started building AI-powered endpoints, I noticed an interesting shift.

At first, AI endpoints looked like simple proxy endpoints with some configuration for connecting to a model:

API receives request
↓
send prompt to model
↓
receive response
↓
return it to the client

And it worked well until I found out that passing a prompt directly from the client was not a good idea. The endpoint could be misused for a completely different purpose, allowing someone else to consume my AI usage credits.

Then I realized that the input also needed limits. Sending a large context for a specific task costs more and may produce unexpected results.

So when I started looking closer, especially when I needed reliable structured output and predictable application behavior, I quickly realized that it was not that simple. Validation was no longer only guarding execution, it had also become a post-processing step. AI models are probabilistic. Even with the same input, they may return different outputs, omit required information, misunderstand instructions or return something that is technically valid but logically wrong. And because every token has a price, I cannot simply retry the request and hope for a better result.

That was when I started questioning whether AI endpoints should be designed in the same way as conventional Web API endpoints.

Conventional Web API Endpoint Flow
AI-powered Web API Endpoint Flow
What This Difference Changes
- Unpredictable Latency
- Retry Logic
- Idempotency and Side Effects
- Testing AI Endpoints
- The Output Contract
- Observability and Cost
Summary

Conventional Web API Endpoint Flow

A conventional Web API endpoint usually follows a similar flow:

validate request
↓
execute business logic
↓
return representation

The first phase is request validation. We validate the incoming data against property constraints, API contracts, authorization rules and application-specific business rules.

The second phase is execution. The application processes data, performs I/O operations or executes business logic.

The final phase is returning a representation of the result. The code executed by a conventional endpoint is normally deterministic within a known application state. When the same code runs against the same state, we generally get the same result.

And that is basically it.

The general flow of a conventional Web API endpoint is relatively simple, although the individual steps can, of course, be very complex. But AI models do not work in exactly the same way. They do not simply execute a predefined sequence of instructions and always produce the same result.

AI-powered Web API Endpoint Flow

The internal flow of an AI-powered endpoint is usually more complicated:

validate request
↓
prepare prompt, tools and context
↓
generate probabilistic output
↓
validate schema, meaning and safety
↓
retry, repair, reject or fall back
↓
return representation

We still start by validating the incoming request. Standard property constraints and business rules are still important, but AI endpoints may also require additional controls. The application may need to restrict the requested topic, limit input size, apply controls against suspicious instructions, isolate untrusted retrieved content or decide which tools the model is allowed to call.

The next step is preparing the prompt and settings for the model call. The application prepares the instructions, conversation history, retrieved context, tool definitions and generation settings.

Then the model produces an output. But unlike the result of conventional business logic, we cannot automatically assume that the output is correct just because the model call succeeded. A successful HTTP response from the model provider only tells us that the model generated something. It does not tell us whether the result is complete, safe, grounded or even useful.

So validation appears again after generation. For example, we may validate the JSON schema in a similar way to a response from a conventional external service. But even when the schema is correct, the result may still be logically wrong for the business domain. The model may also omit properties that are not technically required by the schema but should be present based on the provided context.

When the output fails these checks, the application must decide what to do next. It may try to repair the response, ask the model to generate it again, use a fallback model, return a controlled error or send the request for human review. But every decision has its own cost. A retry consumes more tokens, while human intervention costs both time and money.

All of this turns the endpoint into an orchestration pipeline instead of a simple proxy around a model call.

What This Difference Changes

With a conventional Web API, the application explicitly defines how the result is created. This means that the execution path is controlled by code and we know what result to expect.

With an AI-powered Web API, the application delegates part of the result creation to a probabilistic system. This means that we no longer fully control how the result is generated. To achieve the expected result, we need to add extra steps to the flow, such as post-processing and output validation.

We can simplify it like this:

Conventional Web API: the backend executes the rules.
AI-powered Web API: the backend orchestrates and evaluates the result.

But this difference affects much more than validation. It also changes how we think about latency, retries, idempotency, testing, observability, cost and output contracts.

There are definitely more differences, but let’s have a look at the ones I discovered along the way.

Unpredictable Latency

The latency of a conventional endpoint is usually determined by business logic, I/O operations, data processing and similar operations. These operations are not always fast or perfectly predictable, but we can usually measure them separately and optimize the slowest parts by improving the code, optimizing database queries or adding caching.

AI endpoints introduce another level of variability.

Generation time may depend on the selected model, prompt and context size, output length, provider load and other factors. One request may finish after a single model call, while another may require several tool calls, validation attempts or regeneration steps.

So latency is no longer determined only by the operations we explicitly execute. It may also depend on decisions made during model generation.

That makes timeouts, cancellation, streaming, asynchronous processing and latency budgets even more important.

One of the easiest ways to improve the latency of an AI-powered endpoint is to improve the prompt. We can make it more specific, reduce unnecessary context and limit the expected output.

Another example is avoiding the need for the model to return full objects.

For example, we may provide data like this:

{
  "data": [
    {
      "id": 1,
      "name": "john doe",
      "address": "Mordor",
      "category": "Nazgûl"
    },
    {
      "id": 2,
      "name": "joe doe",
      "address": "Gondor",
      "category": "soldier"
    }
  ]
}

Then we can instruct the model to return only the selected IDs instead of repeating the full objects.

The backend can map those IDs back to the original data after generation. This reduces the number of output tokens and may improve both latency and cost.

The main point is that we approach latency optimization differently. With conventional endpoints, we usually optimize code, database access or caching. With AI endpoints, we also need to optimize prompts, context size, model selection and generated output.

Retry Logic

In conventional Web APIs, we often retry I/O operations under specific conditions. For example, we may retry when a dependency is temporarily unavailable, a connection is interrupted or an external service returns a transient status code. These retries are usually based on technical failures.

AI endpoints introduce another type of retry. The request may complete successfully at the transport level, but the generated output may still be unusable. For example, it may miss a required field, break the expected schema, contradict the supplied context or fail a business rule.

Every retry increases latency and consumes additional tokens, which means additional cost. The next attempt may return a different but still incorrect response.

Because of that, AI retries should not be treated like ordinary network retries. They need explicit limits, and we should also consider additional constraints such as the token and monetary budget, the reason for the failure, whether another attempt is likely to help, and whether a fallback model or deterministic alternative is available.

Let’s have a look at this C# retry pipeline, which I used with a local model exposed through Ollama:

private static class RetryPipeline<T>
{
    public static readonly ResiliencePipeline<Result<T>> Instance = new ResiliencePipelineBuilder<Result<T>>()
        .AddRetry(new RetryStrategyOptions<Result<T>>
        {
            MaxRetryAttempts = 2,
            Delay = TimeSpan.FromSeconds(2),
            BackoffType = DelayBackoffType.Exponential,
            UseJitter = true,
            ShouldHandle = new PredicateBuilder<Result<T>>()
                .Handle<HttpRequestException>()
                .Handle<JsonException>()
                .Handle<TaskCanceledException>(ex =>
                   !ex.CancellationToken.IsCancellationRequested)
                .HandleResult(r => r.IsFailed)
        })
        .Build();
}

The pipeline retries when it receives an HttpRequestException, JsonException or TaskCanceledException. It allows a maximum of two retry attempts and uses exponential backoff with an initial delay of two seconds.

So far, this looks like a typical resilience pipeline for a conventional API endpoint.

The important difference is this condition:

.HandleResult(r => r.IsFailed)

It also retries when the operation does not throw an exception but still returns a failed result.

Inside the action executed by this pipeline, I validate the AI output. If the response is technically valid but logically wrong, I return a failed result and let the pipeline try again.

Note: Simply retrying may not be enough. To prevent the model from producing another invalid result, the validation failure should be included in the next generation attempt so that the model knows what was wrong with the previous response. Without this feedback, the model may repeat the same mistake.

This approach may not be ideal when using a paid model provider because every retry consumes additional tokens and increases the cost. But for a local or free model, a small and strictly limited number of retries may be sufficient.

Sometimes the correct decision is not to retry. It may be better to reject the output, return a controlled error or ask the user for more information.

Idempotency and Side Effects

Idempotency means that executing the same operation multiple times has the same effect as executing it once.

A simple example is a conventional GET endpoint:

GET /api/orders/123

We can call this endpoint several times without changing the order. The returned representation may change if the underlying data changes, but the request itself does not produce additional side effects.

With AI endpoints, idempotency becomes more complicated when the model can call tools.

Sending the same prompt multiple times may produce different outputs or slightly different wording. For read-only endpoints, this may be acceptable because no server state is changed.

But it becomes much more dangerous when the endpoint can perform actions. For example, the model may create an order, send an email or update data through a tool. If output validation later fails and the whole operation is retried, the model may call the same tool again and create a second order.

That is why actions triggered by AI endpoints should use protections such as idempotency keys, persisted operation results and unique constraints. Repeating the same action with the same operation ID should return the original result instead of executing the side effect again.

Testing AI Endpoints

Testing conventional endpoints is relatively straightforward when the application state and dependencies are controlled.

We prepare the data, execute the endpoint and assert the expected result, such as the status code, expected response values, an updated application state or whether an external dependency was called.

With AI endpoints, exact-output assertions are often fragile. The same valid answer may be written in many different ways. A model update may also change the wording while keeping the same meaning. But asserting only the response status or checking that fields are not null is too weak.

Instead of always comparing the exact response, we can verify the required properties of the result. Depending on the use case, we may assert that values are within an allowed range, forbidden content is not present, tool calls respect the allowlist and the response follows the expected business rules.

For example, asserting the complete response with Assert.Equal would be fragile:

var result = await endpoint.GeneratePlanAsync(request);

// Fragile assertion
Assert.Equal("Family Day in Brno", result.Title);
Assert.Equal(
    "Visit the science centre and have lunch nearby.",
    result.Description);
Assert.Equal(1_500, result.TotalCost);

The model may return a different title or description while still producing a completely valid plan.

Instead of checking the exact response, we can assert the properties that matter to the application using methods such as InRange, Contains and DoesNotContain:

var result = await endpoint.GeneratePlanAsync(request);

Assert.NotNull(result);
Assert.NotEmpty(result.Activities);

//Assert
Assert.InRange(result.TotalCost,0,request.Budget);

Assert.All(
    result.Activities,
    activity =>
    {
        Assert.Contains(
            activity.Type,
            request.AllowedActivityTypes);

        Assert.InRange(
            activity.TravelTimeMinutes,
            0,
            request.MaximumTravelMinutes);

        Assert.False(
            string.IsNullOrWhiteSpace(activity.Name));
    });

Assert.DoesNotContain(result.Activities, activity => activity.IsClosed);
Assert.All(result.Activities,activity => Assert.NotEmpty(activity.SourceIds));

The title, description or order of activities may change, but the generated plan must still respect the budget, travel-time limits, allowed activity types and supplied source data.

A large part of the endpoint can still be tested deterministically. Schema validation, authorization, tool permissions, parsing, fallback logic and side-effect handling should still be tested like normal application code, but we should change how we assert the generated result.

The Output Contract

When a conventional endpoint calls an external service, we usually rely on a JSON parser and a clearly defined contract. When the service returns invalid JSON or a response that does not match the expected schema, deserialization fails and the application handles the error.

AI output creates a more subtle problem.

A model may return perfectly valid JSON that matches the expected schema but is still logically wrong.

For example:

{
  "approved": true,
  "reason": "The customer meets all required conditions.",
  "failedConditions": [
    {
      "name": "age",
      "value": 13,
      "description": "The customer is under the required age."
    }
  ]
}

This response is valid JSON and may also match the expected schema. But it contradicts itself. The customer is marked as approved even though one of the required conditions has failed.

So schema validation is necessary, but it is not enough.

AI output may require additional levels of validation, such as business-rule validation, logical consistency checks and safety validation.

The endpoint must be able to tell the difference between a response that can be parsed and a response that can actually be trusted.

Observability and Cost

Traditional endpoint monitoring usually focuses on metrics such as request count, latency, errors, dependency calls and resource usage.

AI endpoints need these metrics too, but they also introduce model-specific ones:

input and output token usage
model and model version
number of generation attempts
tool calls
validation failures
repair success rate
estimated cost
output quality or evaluation score

Without these metrics, it is difficult to understand why an endpoint became slower, more expensive or less reliable.

A provider may change the model behind an alias. Prompts may grow over time, retrieved context may become larger and retry frequency may increase. The endpoint may still return 200 OK while its cost increases and the quality of its output slowly gets worse.

Summary

Traditional endpoints execute business logic that is defined and controlled by code.

AI endpoints are different. They orchestrate probabilistic generation, validate the result and decide whether it is reliable enough to return.

That changes how we should think about and design endpoints that use AI models.

An AI endpoint should not be just a thin proxy around a model call. The model generates the output, but the backend still decides whether it should become the final response.

These are some of the biggest differences I discovered while creating, debugging and maintaining AI endpoints. There are definitely more, but even these few examples show that adding an AI model behind an endpoint can significantly change its flow.

PrimeTek announced PrimeUI licensing for future PrimeNG, PrimeReact and PrimeVue versions. Existing MIT versions stay MIT. Big change for frontend teams. https://primeui.dev/nextchapter

Daniel Balcarek — Thu, 09 Jul 2026 15:45:56 +0000

PrimeUI

PrimeUI is a complete UI ecosystem — premium component libraries, advanced pro components, UI kit, and design resources to build modern web applications.

primeui.dev

Build a Minimal WebMCP Agent with Playwright and Gemini

Daniel Balcarek — Wed, 01 Jul 2026 06:58:36 +0000

WebMCP lets a web page expose tools that AI agents can discover and execute inside the browser. That sounds simple until you want to test those tools with a model outside the Model Context Tool Inspector Chrome extension.

A while ago, I built a small puzzle game that exposes WebMCP tools. I tested and debugged those tools using the Model Context Tool Inspector, which is great for quick experiments, the limitation is that it only gives access to a small set of lightweight Gemini models and I wanted to test the same WebMCP tools with stronger ones.

My first idea was to build another Chrome extension, but that felt like overkill. WebMCP tools need a real browser context: the browser must open the page directly, discover the tools and execute them inside the page. So instead of building another extension, I looked for something that could simply open Chrome and control the page.

And that is where Playwright fits nicely.

So in this article, I will show how to create a simple agent that wires up the Gemini API with WebMCP through Playwright. Gemini requests a tool call and Playwright executes the matching WebMCP tool inside a real Chrome browser.

Prerequisites
Prepare the Solution
Check if modelContext Exists
Read Exposed WebMCP Tools
Execute a WebMCP Tool
Create a Minimal Agent Proof of Concept
- Gen AI SDK
- Agent Creation
What This Proves
- Repositories
Summary

Prerequisites

For this example, you need:

Node.js 20+
Google Chrome
A Gemini API key

Prepare the Solution

The first thing we need to do is enable WebMCP in Chrome. WebMCP is still experimental, so for local development it must be enabled through a Chrome flag:

Open Chrome and navigate to chrome://flags/#enable-webmcp-testing
Set the flag to Enabled.
Relaunch Chrome to apply the changes.

After that, we can create a small Node.js project:

mkdir custom-agent
cd custom-agent
npm init -y

Next, install Playwright as a development dependency. I also use tsx to run TypeScript files directly and dotenv to read environment variables from a .env file:

npm install -D playwright tsx dotenv typescript @types/node

This gives us everything we need to run TypeScript code, open Chrome and access environment variables.

Because the agent will also call an AI model, we need to install the Gemini SDK. For this example, I use @google/genai:

npm install @google/genai

The last preparation step is to add a script to package.json:

{
  "scripts": {
    "agent": "tsx agent.ts"
  }
}

This command will run the agent.ts file, where we will put the main logic.

Check if modelContext Exists

Now that the project is prepared, let’s create the first version of agent.ts. At this stage, I only want to check whether modelContext is available inside the browser page.

import { chromium } from "playwright";

const gameUrl = process.argv[2] ?? "http://localhost:5173";

async function main() {
  const context = await chromium.launchPersistentContext(
    "./.chrome-agent-profile",
    {
      channel: "chrome",
      headless: false,
      args: ["--enable-experimental-web-platform-features"],
    },
  );

  const page = await context.newPage();

  await page.goto(gameUrl, { waitUntil: "networkidle" });

  const result = await page.evaluate(() => ({
    userAgent: navigator.userAgent,
    hasNavigatorModelContext: "modelContext" in navigator,
    hasDocumentModelContext: "modelContext" in document,
  }));

  console.log(result);
}

main().catch((error) => {
  console.error(error);
  process.exit(1);
});

This code opens Chrome, navigates to the game page, and checks if modelContext exists on navigator or document.

One important detail is that I am not using the bundled Chromium from Playwright. Instead, I am opening the real Chrome installed on my machine by using launchPersistentContext with channel: "chrome". This matters because WebMCP is still experimental. In my case, the isolated Chromium browser did not discover the WebMCP tools correctly, while real Chrome with the enabled flag worked.

Note: Because launchPersistentContext creates a local Chrome profile, do not forget to add this folder to .gitignore:
.chrome-agent-profile/
The profile can contain local browser data such as cache, cookies, and other Chrome state. It should not be committed to the repository.

Read Exposed WebMCP Tools

The first check only tells us whether modelContext exists. The next step is to read the tools exposed by the page.

We can do that by calling modelContext.getTools() inside the page.evaluate() method:

  const result = await page.evaluate(async () => {
    const modelContext = navigator.modelContext;

    if (!modelContext) {
      return {
        hasModelContext: false,
        tools: [],
      };
    }

    const tools = await modelContext.getTools();

    return {
      hasModelContext: true,
      tools: tools.map((tool) => ({
        name: tool.name,
        description: tool.description,
        inputSchema: tool.inputSchema,
        origin: tool.origin,
      })),
    };
  });

This code returns the list of tools exposed by the current page. For each tool, I print basic metadata such as the name, description, input schema and origin.

At this point, it is useful to print the result as formatted JSON:

console.log(JSON.stringify(result, null, 2));

This makes it easier to verify that Chrome discovered the WebMCP tools correctly.

Execute a WebMCP Tool

Reading tools is useful, but the real goal is to execute them. In my game, one of the exposed tools is called getGameState. It returns the current state of the puzzle, including the map, remaining moves and collected wood. For the first test, I can find this tool by name and execute it directly:

const gameState = await page.evaluate(async () => {
    const modelContext = (navigator as any).modelContext;

  if (!modelContext) {
    throw new Error("modelContext is empty");
  }

  const tools = await modelContext.getTools();

  const getGameStateTool = tools.find((tool: any) => tool.name === "getGameState");

  if (!getGameStateTool) {
    throw new Error("getGameState tool not found");
  }

  return await modelContext.executeTool(getGameStateTool, "{}");
});

This proves that Playwright can open the page, access modelContext, find a WebMCP tool and execute it inside the browser context.

However, hardcoding the tool execution like this is not ideal. The agent should be able to execute any tool by name, so I extracted the logic into a reusable helper function:

import type { Page } from "playwright";

export async function executeWebMcpTool<T>(
  page: Page,
  toolName: string,
  args: unknown,
): Promise<T> {
  return await page.evaluate(
    async ({ toolName, args }) => {
    const modelContext =
        (document as any).modelContext ?? (navigator as any).modelContext;
    if (!modelContext) {
        throw new Error("Model Context API is not available");
    }

    const tools = await modelContext.getTools();

    const tool = tools.find((tool: any) => tool.name === toolName);

    if (!tool) {
        throw new Error(`Tool not found: ${toolName}`);
    }

    const result = await modelContext.executeTool(
        tool,
        JSON.stringify(args),
    );

    return result;
    },
    { toolName, args },
);
}

This function receives a Playwright Page, the tool name and arguments. It then evaluates code inside the browser page, finds the matching WebMCP tool, serializes the arguments and executes the tool. With this helper, the Node.js code does not need to know the internal implementation of the page. It only needs the tool name and arguments.

That is the important bridge: Playwright controls Chrome, Chrome sees the WebMCP tools and our Node.js code can execute them.

Note: In my setup, navigator.modelContext worked reliably, but WebMCP is still experimental, so in the reusable helper I check both document.modelContext and navigator.modelContext.

Create a Minimal Agent Proof of Concept

Now we can connect the WebMCP tool execution with an AI model.

For this article, I want to keep the example small. The goal is not to build the full game-playing agent here. The goal is to prove the basic flow:

Send tool definitions to Gemini.
Let Gemini decide which tool it wants to call.
Execute that tool through WebMCP.
Print the result.

The full agent can build on top of this by sending the tool result back to the model and continuing the loop.

Gen AI SDK

For this example, I use the @google/genai package. We already installed it earlier, so now we can create a small service for communicating with Gemini.

Create a new file called genai.service.ts:

import "dotenv/config";
import {
  GoogleGenAI,
  type Content,
  type GenerateContentConfig,
  type GenerateContentResponse,
} from "@google/genai";

export type GenerateRequest = {
  contents: Content[];
  config?: GenerateContentConfig;
};

export class GenaiService {
  private readonly ai: GoogleGenAI;
  private readonly model: string;

  constructor(model: string = "gemini-2.5-flash-lite") {
    this.model = model;
    const apiKey = process.env.GEMINI_API_KEY;
    if (!apiKey) {
      throw new Error("Missing GEMINI_API_KEY in .env");
    }

    this.ai = new GoogleGenAI({ apiKey });
  }

  public async generateContentAsync(
    request: GenerateRequest,
  ): Promise<GenerateContentResponse> {
    const response = await this.ai.models.generateContent({
      model: this.model,
      contents: request.contents,
      config: request.config,
    });

    return response;
  }
}

The implementation is straightforward. The service reads GEMINI_API_KEY from the .env file, creates an instance of GoogleGenAI and exposes one method called generateContentAsync.

I also created a small GenerateRequest type. The reason is simple: I only want to expose the properties that this example needs. The original SDK request type contains more options and for this proof of concept that would make the code harder to read.

You also need to create a .env file:

GEMINI_API_KEY=your-api-key

Do not forget to add the .env file to .gitignore, so you do not commit your API key to the repository.

Agent Creation

Now we can put everything together in agent.ts.

In this example, the tool definition is hardcoded. That keeps the proof of concept simple and easier to understand. In a more generic version, we could read WebMCP tools from the page and map them into Gemini tool declarations automatically. But that would add more code and I want this article to stay focused on the core idea.

import { chromium, type Page } from "playwright";
import { GenaiService } from "./genai.service";
import {
  FunctionCallingConfigMode,
  type Content,
  type Tool,
} from "@google/genai";

export const tools: Tool[] = [
  {
    functionDeclarations: [
      {
        name: "getGameState",
        description:
          "Get the current board. visibleMap rows run top-to-bottom; each character is x=0 onward. P=player, .=land, W=tree, ~=water, B=bridge, R=rock, and G=goal.",
        responseJsonSchema: {
          type: "object",
          properties: {
            remainingMoves: { type: "number" },
            wood: { type: "number" },
            visibleMap: {
              type: "array",
              items: { type: "string" },
            },
          },
          required: ["remainingMoves", "wood", "visibleMap"],
        },
      },
    ],
  },
];

const gameUrl = process.argv[2] ?? "https://tower-before-dusk.gramli.workers.dev";

async function main() {
  const aiService = new GenaiService();
  const context = await chromium.launchPersistentContext(
    "./.chrome-agent-profile",
    {
      channel: "chrome",
      headless: false,
      args: ["--enable-experimental-web-platform-features"],
    },
  );

  const page = await context.newPage();
  await page.goto(gameUrl, { waitUntil: "networkidle" });

  const contents: Content[] = [
    {
      role: "user",
      parts: [
        {
          text: "Inspect the current Tower Before Dusk game state.",
        },
      ],
    },
  ];

  const response = await aiService.generateContentAsync({
    contents,
    config: {
      tools,
      toolConfig: {
        functionCallingConfig: {
          mode: FunctionCallingConfigMode.ANY,
          allowedFunctionNames: ["getGameState"],
        },
      },
    },
  });

  const functionCall = response.functionCalls?.[0];
  if (!functionCall?.name) {
    throw new Error("Gemini did not return a tool call");
  }
  if (functionCall.name !== "getGameState") {
    throw new Error(`Gemini requested an unknown tool: ${functionCall.name}`);
  }

  console.log("Gemini tool call:", functionCall);

  const gameState = await executeWebMcpTool(
    page,
    functionCall.name,
    functionCall.args ?? {},
  );

  console.log("Tool result:", gameState);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

export async function executeWebMcpTool<T>(
  page: Page,
  toolName: string,
  args: unknown,
): Promise<T> {
  return await page.evaluate(
    async ({ toolName, args }) => {
      const modelContext =
        (document as any).modelContext ?? (navigator as any).modelContext;
      if (!modelContext) {
        throw new Error("Model Context API is not available");
      }

      const tools = await modelContext.getTools();

      const tool = tools.find((tool: any) => tool.name === toolName);

      if (!tool) {
        throw new Error(`Tool not found: ${toolName}`);
      }

      const result = await modelContext.executeTool(tool, JSON.stringify(args));

      return result;
    },
    { toolName, args },
  );
}

The flow is simple:

First, the script opens Chrome and navigates to the game page. Then it sends a prompt to Gemini together with the available tool definition. In this example, Gemini is allowed to call only one function: getGameState.

After Gemini returns a function call, the script validates that the requested function is really getGameState. This is important because the application should never blindly execute arbitrary tool names returned by the model. Then the script passes the function name and arguments to executeWebMcpTool. The tool is executed inside the browser page through WebMCP and the result is printed to the console.

And that is the proof of concept.

Our Node.js script does not call the game directly. It opens the game in Chrome, lets Chrome discover the WebMCP tools, lets Gemini request a function call and then executes that function call against the page.

What This Proves

This small example proves that Playwright can be used as a bridge between an AI model and WebMCP tools.

The browser still owns the WebMCP context. The page still exposes the tools, but our external Node.js process can orchestrate the flow and connect those tools to a stronger model.

This is useful when the existing browser-based tooling is too limited, or when you want to experiment with your own agent loop.

The example in this article only executes one tool call. A real agent would need a loop:

Ask the model what to do.
Execute the requested WebMCP tool.
Send the tool result back to the model.
Let the model decide the next step.
Repeat until the task is finished.

That full implementation would make this article much longer, so I kept the article focused on the proof of concept.

You can find the source code here:

Repositories

Proof of Concept agent - the minimal implementation used in this article.
Full agent repository - the extended implementation for Tower Before Dusk. It can already play through the first two levels.

Summary

In this article, I showed how to use Playwright to create a custom proof of concept agent for WebMCP. First, I checked whether modelContext is available, then I discovered the exposed tools, executed one of them and finally connected the flow with Gemini function calling.

Of course, this is not a fully autonomous agent yet, but it is the foundation for one.

WebMCP is still experimental and the Model Context Tool Inspector is great for debugging. However, the available models can feel limiting for some types of web apps. I hope this approach can help others test WebMCP tools with stronger models without the need to create another Chrome extension.

Tower Before Dusk: I Built a Puzzle Game for Humans and AI

Daniel Balcarek — Thu, 18 Jun 2026 06:49:04 +0000

This is a submission for the June Solstice Game Jam

It's interesting how the most exciting ideas always arrive when I have basically no time to work on them.

A few weeks earlier, I had finished my submission for the GitHub challenge by bringing an old WinForms game back to life. That project turned out to be a lot of fun. Then Sylwia Laskowska published a great article about Google's WebMCP. The idea fascinated me, but I wasn't sure where I could actually use it. Then the June Solstice Game Jam was announced. The idea hit me like a lightning bolt: What if I made a game that both humans and AI could play?

Let's do it.

What I Built

I created a puzzle game with a solstice theme called Tower Before Dusk. The goal is simple: reach your home tower before sundown. Every action costs time. Every step brings sunset a little closer. Rivers block your path, rocks force detours and the only way across water is to collect enough wood and build bridges. Move too much, collect unnecessary resources, or choose the wrong path, and night will arrive before you make it home.

The challenge isn't just solving the puzzle. It's solving it efficiently.

And apparently, that's difficult for both humans and AI.

Video Demo

In this demo, Gemini 3.1 Flash-Lite tries to solve the level using the exposed game tools. It fails, then I restart the level and solve it manually. That failure is part of the point: the tools worked, but reasoning through the puzzle was still hard for the lightweight model.

tower-before-dusk.gramli.workers.dev

Code

Gramli / tower-before-dusk

A TypeScript puzzle game demonstrating WebMCP, where humans and AI solve the same challenges under the same rules.

Tower Before Dusk

Tower Before Dusk is a tile-based puzzle game about reaching the tower before sunset. Plan each route carefully: every move spends daylight, trees provide wood, and water can only be crossed by building bridges.

The game is built as a modern browser app with TypeScript, HTML canvas, and Vite. It also exposes a small model-context interface so an assistant can read the current map, validate a route, and submit a complete action plan for replay in the UI.

Features

Eight handcrafted puzzle levels with different tower layouts and move limits
Daylight system that tracks the move budget from morning through sunset
Trees that are collected automatically for wood when entered
Bridge building over water, consuming two wood per water tile
Rocks, water, bridges, towers, and sprite-based terrain rendering
Responsive canvas scaling for different browser sizes
Keyboard-driven play with restart and help shortcuts
HUD for level name, wood…

View on GitHub

How I Built It

Since WebMCP was completely new to me, I didn't want to jump straight into building a game without understanding how it worked first.

So I generated a simple Vite application and experimented with a tiny counter tool:

const incrementCounterTool = {
  name: "incrementCounter",
  description: "Increments the counter by a specified value.",
  inputSchema: {
    type: "object",
    properties: { value: { type: "number" } },
  },
  execute: async ({ value }: { value: number }) => {
    const counter  = document.getElementById('counter') as HTMLElement;
    if (counter) {
      const currentValue = parseInt(counter.innerText, 10) || 0;
      counter.innerText = (currentValue + value).toString();
    }
  },
  annotations: {
    readOnlyHint: false,
    untrustedContentHint: true
  },
};

When the AI successfully incremented the counter and I saw the value changing in the browser, I knew I could continue.

Of course, my game would be a little more complicated than a counter. At first, I considered letting the AI inspect the game state after every move, but then I realized I would burn through tokens incredibly fast. So I came up with another approach.

Instead of playing move by move, the AI would receive the entire game state, understand the rules, and generate one complete plan to reach the goal, but then another thought appeared:

"How do I make it look like the AI is actually playing?"

The answer was surprisingly simple. The AI would return a sequence of actions and my game loop would replay them with a short delay between moves. From the player's perspective, it would look like the AI was thinking and playing in real time.

Even better, it fit perfectly with the game's architecture, because human players already interact through keyboard actions that modify the game state.

With that idea in mind, I built the MVP.

I did it the "old-fashioned" way: player first. (Almost like mobile-first, except with fewer trendy conference talks.)

I also have to admit that I stole some core ideas from my previous EasterGame project. At this point, I'm starting to suspect I accidentally built the beginnings of a tiny puzzle game engine.

The first playable level looked like this:

The game worked, You could reach the tower and win. It was finally time to bring AI into the picture.

Based on the original idea, I created two MCP tools:

getGameState
submitPlan

getGameState provides the complete state of the current level, including objectives, rules, available actions, and the visible map:

export const gameState: GameState = {
  objective:  "Reach G before sunset using as few moves as possible. Do not collect unnecessary wood.",

  legend: {
    P: "player start position",
    ".": "land / walkable tile",
    W: "wood / walkable tile, can be collected",
    "~": "water / blocked unless player has enough wood",
    R: "rock / blocked tile",
    B: "bridge / walkable tile created after entering water",
    G: "goal / walkable tile",
  },

  rules: {
    map:
      "visibleMap is an array of map rows from top to bottom. The first symbol in each row is x=0, and rows start at y=0. Symbols are separated by spaces for readability.",

    movement:
      "The player can move one tile up, down, left, or right. Each movement costs 1 move.",

    rock:
      "Rock tiles marked R are blocked and cannot be entered.",

    wood:
      "Tree tiles marked W are walkable, but entering W automatically collects the tree. This costs 1 extra move, adds 1 wood, and removes W from the map. Because collecting wood costs an extra move, avoid W unless the wood is needed to cross water.",

    water:
      "Water cannot be entered unless the player has at least 2 wood.",

    bridge:
      "When the player moves into a water tile with at least 2 wood, a bridge is built automatically on that single water tile. This costs 1 extra move, consumes 2 wood, and changes only that one water tile to B. Other connected water tiles remain water.",

    bridgeLimit:
      "Each bridge covers only one water tile. If there are multiple water tiles in a row, the player needs enough wood to build one bridge per water tile.",

    strategy:
      "Use the minimum number of actions needed to reach G. Do not collect wood unless it is required to build enough bridges. Avoid stepping on W unless that wood is necessary. Extra wood has no value at the end.",

    goal:
      "The player wins immediately when reaching G using no more than the maximum allowed moves.",

    lose:
      "The player loses if the move budget is exhausted before reaching G, or if no valid action can reach G.",
  },

  actions: [
    "MOVE_UP",
    "MOVE_DOWN",
    "MOVE_LEFT",
    "MOVE_RIGHT",
  ],

  remainingMoves: 30,
  wood: 0,

  visibleMap: [
    "P . W W W W ~ ~ G",
  ],
};

The second tool, submitPlan, accepts the AI's proposed solution:

    inputSchema: {
      type: "object",
      properties: {
        actions: {
          type: "array",
          items: {
            type: "string",
            enum: [
              "MOVE_UP",
              "MOVE_DOWN",
              "MOVE_LEFT",
              "MOVE_RIGHT",
            ],
          },
        },
        summary: { type: "string" },
      },
      required: ["actions"],
      additionalProperties: false,
    },

The AI returns an array of actions such as:

["MOVE_UP","MOVE_DOWN","MOVE_LEFT","MOVE_RIGHT"]

Then submitPlan feeds those actions into the game loop, which replays them with a short delay so players can watch the AI attempt to solve the puzzle.

Pretty neat, right?

Well... It worked. The AI successfully called both tools and then it immediately exposed another problem: my level design was too difficult. Even Level 1 turned out to be surprisingly challenging for the models I tested.

For development and testing, I used the WebMCP Inspector with the Gemini models available through the free API tier:

Gemini 3 Flash Preview
Gemini 3.1 Flash-Lite
Gemini 3.5 Flash

All three models correctly called both tools, but none of them managed to generate a valid solution for just Level 1. At that moment, I realized that perhaps I had been a little too optimistic about my puzzle design, so I lowered the difficulty. Eventually, AI finally managed to reach the tower and complete the first level.

Victory ...Well... a small victory. I'm fairly sure stronger models would perform better on the harder levels, but I also didn't want to discover how much puzzle-solving curiosity could cost in API tokens.

If you'd like to try it yourself, this is the prompt I used:

You are playing Tower Before Dusk.

First call getGameState. Study the objective, legend, rules, remainingMoves, wood, and visibleMap.

Create one complete plan to reach G before sunset. Use only the listed actions. Account for move costs, automatic bridge building, wood collection, rocks, water, and remainingMoves.

Then call submitPlan exactly once with the full action list. Do not submit partial plans.

Interesting Thoughts

Going into this project, I assumed the hardest part would be integrating WebMCP into the game, but it wasn't.

The real surprise was discovering that even simple puzzle levels weren't trivial for AI models. The tools worked almost immediately, but designing levels that felt straightforward to humans while making AI struggle turned out to be an interesting challenge.

It made me realize that puzzles we consider "easy" often rely on intuition and reasoning patterns that aren't as obvious to language models as I had expected.

The Sunset Arrives

And that's how Tower Before Dusk came to life. I set out to build a game for the June Solstice Game Jam and explore an experimental technology, discovering that simple-looking puzzle games aren't necessarily simple for AI and creating something that humans and language models can both struggle to beat.

Honestly, I think that's a pretty fitting result for a game about racing against the setting sun.

I Used My Last 7% of Copilot Tokens to Bring a 2014 WinForms Game Back to Life

Daniel Balcarek — Tue, 02 Jun 2026 07:06:53 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

Originally, I didn't plan to join this challenge because I'm moving away from Copilot due to its recent pricing changes.

Don't get me wrong, I’m not upset with the provider at all. I used Copilot on hobby projects for a long time and was generally very satisfied with it. However, it has simply become too expensive for the way I use it.

But I still had 7% of my premium tokens left before June 1st and one free afternoon. Then an idea came to mind: Challenge accepted. (Sorry, Gemma 4 article, you'll have to wait a little longer.)

And honestly, I'm glad I did it.

What I Built

This project is less about the code and more about nostalgia, bringing an old university student game into the modern era.

I originally created this game for a developer community competition in my country. The original version is still available online: www.itnetwork.cz - EasterGame.

The game actually ended up as one of the winners. I won a few stickers and wore them proudly 😄

So I decided to spend my remaining Copilot tokens bringing this nostalgic game back to life and making it accessible to a much wider audience.

What is the game about?

It's a puzzle game where a rabbit must collect all the Easter eggs and reach the exit door. The catch is that after every move, the ground behind the rabbit turns into water, so you need to plan your route carefully or you'll get stuck.

There are also a few additional mechanics:

Teleports connected in pairs
Carrots that grant the ability to jump over rocks
Obstacles that force you to think several moves ahead

The original version contained seven levels, and even back then the code was designed to make adding new levels relatively easy.

Demo

Try Both Versions

If you're curious how close the browser version is to the original, I've included the original WinForms executable in the repository.

Original WinForms version (2014): GitHub Repository
Browser version (2026): Play Online

Feel free to compare them side by side.

The Comeback Story

Well... my original project was a Windows Forms game written in .NET Framework 4.5:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

That's from around 2014 😊

Back then I wasn't even using English for class names or methods. The entire project was written in Czech. Looking at it today, I don't think the code I produced as a university student was actually that bad. I built the project mainly to better understand object-oriented programming, and looking back, I think that goal was achieved.

What surprised me most, however, was the architecture I designed back then.

I introduced inheritance for both game objects and levels, which made it surprisingly easy to add new entities and levels. The game state itself was managed by a single central class of roughly 430 lines of code.

It wasn't perfect, but looking back, simplicity was one of its strengths. It worked, and more importantly, it was easy to extend.

So what did I do?

First, I ported the game to TypeScript, keeping both the good and the bad parts of the original design. Then I gradually refactored it to better fit a browser environment.

Architecture Change

The original WinForms version was already largely event-driven. Keyboard events updated the game state and refreshed the form, while a one-second timer updated the elapsed-time display.

I kept that turn-based model in the browser. Player input updates the game state and redraws the canvas, while a lightweight timer updates the elapsed-time display. There is still no need for animations, delta-time calculations, or a requestAnimationFrame loop.

The browser version follows almost the same approach:

Player input updates the game state and triggers rendering
A one-second timer updates the elapsed-time display and refreshes the UI
No gameplay logic runs between turns

This works because EasterGame is a purely turn-based puzzle game. The gameplay state changes only when the player makes a move. There are no animations, physics calculations, or continuously moving objects that require continuous updates between turns.

As a result, there is no need for:

a frame budget
delta-time calculations
an Update() / Draw() game loop
requestAnimationFrame

In the browser, addEventListener('keydown', ...) maps naturally to the original input-driven design. Rendering only occurs in response to player actions or periodic UI updates, which keeps the implementation simple and avoids the overhead of a continuous rendering loop.

Responsive Design & Game Control

The second biggest improvement was making the game responsive across all screen sizes while keeping it fully playable.

In the original WinForms application, I rendered everything using System.Drawing.Graphics, while the browser version uses HTMLCanvasElement. Since I wanted to preserve the look and feel of the original game, I reused the same PNG tiles. To make the game responsive, I calculate the optimal tile size based on the available screen space and then derive the canvas dimensions from it.

I also needed to detect whether the game was running on a touch device and introduce a separate input layer for touch controls. Movement is handled through on-screen controls, while starting a new game or level only requires a tap on the main menu.

One problem I actually struggled with was the embedded preview on DEV. My algorithm detected small devices and displayed touch controls, but the game grid was large enough to cause a vertical scrollbar to appear.

The solution was to use window.self !== window.top; to detect whether the game was running inside an embedded frame and adjust the controls accordingly.

My Experience with GitHub Copilot

I started this project with an unusual constraint: only 7% of my premium tokens were left before my subscription reset.

That meant I couldn't simply throw prompts at the problem and hope for the best. Every request had to count.

My first step was asking Copilot to analyze the original .NET Framework solution and create a migration plan for a TypeScript browser version. Surprisingly, this worked very well. Instead of immediately generating code, Copilot helped me understand the project structure and identify the pieces that needed to change.

The actual conversion was a different story.

When I asked Copilot to convert the entire game based on the migration plan it generated, it repeatedly hit response length limits:

Sorry, the response hit the length limit. Please rephrase your prompt.

At that point I had already spent some of my remaining tokens, so seeing that message wasn't exactly encouraging.

Instead of trying to convert the whole solution at once, I changed the prompt and asked Copilot to ignore most of the level definitions and focus on converting the core game together with the simplest level.

That worked much better, and it led to the biggest lesson of the migration: Copilot didn't struggle with converting the codebase itself; it struggled with the level definitions.

Once I had a working browser version with a single level, it became much easier to continue. The game architecture was already in place, so adding the remaining levels was mostly straightforward work.

Since Copilot struggled with level design, I decided to give it one last chance. I created a new level called Copilot Level and gave it complete freedom to design it, as long as the puzzle remained solvable and followed the existing game rules.

The struggle was real, though. Copilot managed to generate a valid level, but honestly? The Copilot Level is really easy to finish 😄

At that point I had a working browser version, but bringing it into the modern era also meant supporting touch devices. But wait, I only had 3% left. Time for one carefully crafted prompt to handle responsive tile sizing and touch controls.

The result wasn't bad at all. After a few manual fixes, Copilot even helped me solve issues related to the embedded DEV preview.

Copilot was at its best when acting as a coding assistant rather than a game designer.

It helped me modernize a project that was over a decade old, but the architectural decisions, validation, and final review still required a human in the loop.

In the end, I'm glad I brought this old desktop game into the browser era. And yes, I spent every remaining premium token doing it. It turned out to be a surprisingly fun farewell project for a tool I used for a year. 😊

Building with Gemma 4 E2B showed me that small models are more reliable when the backend handles orchestration.

Daniel Balcarek — Thu, 28 May 2026 05:44:07 +0000

Gemma 4 Challenge: Build With Gemma 4 Submission

Daniel Balcarek

May 22

How to Use Gemma 4 E2B the Smart Way: Family Trip Advisor

#devchallenge #gemmachallenge #gemma #ai

19 min read

How to Use Gemma 4 E2B the Smart Way: Family Trip Advisor

Daniel Balcarek — Fri, 22 May 2026 06:07:25 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

In a previous article, I benchmarked the Gemma 4 E2B and E4B models to see whether they are actually usable on my old 2015 PC, using specific prompt benchmarks for trip planning.

In this article, we will look at an application powered by the Gemma 4 E2B model. It is based on insights from the previous benchmark and reuses several of the tested prompts.

E2B is not the smartest model when it comes to reasoning, but with a well-designed architecture, it can still fit very well into practical applications and provide useful results. That’s why I chose it for this app. Combined with its speed, it can also run on older or less capable hardware while still returning results in a reasonable time.

First, we will look at the application itself. Then we will go through the architecture of the solution and most importantly: how I used the Gemma 4 E2B model in the smart way.

What I Built
Demo
Code
- Backend
- Frontend
How I Used Gemma 4
- Backend Orchestration
- Algorithm pseudocode
- Validation and Resilience
- Benchmark
MVP Scope and Next Steps
- Known Limitations
Summary

What I Built

For those who often go on trips, especially with kids, you know the drill: How will the weather be? Should we go indoors or outdoors? Where are we going to eat? Will there be enough playgrounds? Is there any parking?

Planning a simple trip often turns into a small chain of decisions that takes more time than expected.

This can be exhausting. That’s why I built Family Trip Advisor, a full-stack application that helps plan trips in one place.

Instead of visiting multiple websites to check weather, activities, restaurants, or parking, you can simply write a prompt like:

“We would like to go on a family trip this Saturday.”

Family Trip Advisor then responds with multiple suggestions for restaurants, activities and parking based on the weather conditions, selected date and your home location.

Sounds good? Let’s take a look at the demo.

Demo

Gramli / familly-trip-advisor

🗺️ Family Trip Advisor

Tell us where you'd like to go — and we'll plan the perfect day for your family.

Family Trip Advisor is an AI-powered trip planning assistant that runs entirely on your own computer. Just describe your trip in plain language, and the app will suggest activities, restaurants, and parking — tailored to the weather and your preferences.

How It Works

You describe your trip — type something like "We want to visit Vienna next Saturday with two kids"
The app understands your intent — it extracts the destination, date, and preferences
Weather is checked — the forecast for that day is fetched automatically
Places are found — nearby activities, restaurants, and parking are discovered
A full plan is generated — the AI puts it all together into a ready-to-follow itinerary

Everything runs locally on your machine. No data is sent to any external AI service.

Screenshots

…

View on GitHub

To run it locally, check the HOW-TO-RUN section in the GitHub repository, as there are prerequisites especially for API keys.

Code

For the backend, I chose ASP.NET, and for the frontend, Angular. I am already familiar with both frameworks, so I chose them mainly for development speed, but also to show that there are more alternatives than just Python and React when building AI applications.

Backend

I know that C# and ASP.NET are not currently the hottest language and framework choices on Dev.to or even globally, but I genuinely like the ecosystem, and for many REST APIs they are still an excellent choice. The Microsoft teams behind C# and ASP.NET continuously improve both performance and developer experience every year.

Architecture

For the solution architecture, I chose Vertical Slice Architecture because it fits very well for fast feature development.

In Vertical Slice Architecture, features are separated into “slices,” where every slice contains everything needed to return a result from the API. This usually includes the endpoint, business services, HTTP clients for third-party APIs and database access.

These slices help implement features more independently, which reduces the risk of introducing bugs or side effects into other parts of the solution. When you follow a good feature structure, understanding the solution is faster and code navigation becomes much easier.

The downside is that some duplication between slices can appear over time, but for smaller and fast-moving applications I consider this tradeoff acceptable.

Structure of the Solution with Vertical Slice Architecture:

familly-trip-advisor           .NET 10 Minimal API
├── Features/                   ← vertical slices live here
│   └── TripPlanner/            one slice = one feature
├── Infrastructure/             shared HTTP clients (cross-cutting)
├── Shared/                     shared utilities (cross-cutting)
└── Program.cs                  composition root

Engineering notes

When you look at the code more closely, you can spot many best practices applicable across frameworks and programming languages, not only in C# and ASP.NET:

For control flow, I chose the Result Pattern instead of using exceptions for expected failures. It returns a structured object containing both the operation result and possible error details. This keeps API responses more predictable and error handling explicit.

For unexpected exceptions, there is exception middleware. Having one central point for handling unexpected exceptions helps keep the code clean and predictable instead of catching general exceptions in many different places.

DateTimeProvider class - one central point for returning DateTime. This is useful for unit testing because time can be mocked easily. Since DateTime is often used across the solution, changing its behavior in one place is also much simpler.

Interfaces and internal sealed classes - hiding implementation behind interfaces simplifies mocking in unit tests and reduces coupling because implementation details can change without affecting dependent classes.

Clean endpoints - this is very important for me. I try to keep endpoints thin and readable, with business logic delegated to handlers or services. This improves maintainability and simplifies testing.

Immutable DTO and request objects - I prefer immutable DTO and request objects because they reduce accidental state changes when objects are passed through multiple layers.

Use a maximum of 3 parameters in public methods - this improves readability and unit testing. Methods with too many parameters are harder to mock and maintain. Encapsulating parameters into a properly named object makes the code easier to read and test.

I apply these best practices in every API I create, and they have proven very valuable over time. The time spent implementing them has paid off many times in the future.

The application is still relatively small, so I intentionally avoided introducing unnecessary abstractions or enterprise-level complexity. My goal was to keep the architecture simple, feature-oriented, and easy to evolve while still following solid engineering practices.

Frontend

The frontend is an Angular 21 SPA application designed mainly to show results and allow simple interaction with the user through a chat window. No fancy features yet.

Architecture

The frontend architecture follows the same approach as the backend. Features are organized into self-contained folders, and there is also a shared folder for reusable components that can be used across the application.

Structure of the solution similar to the backend:

familly-trip-advisor
└── src/app/                    Angular 21 SPA
    ├── features/               ← vertical slices live here
    │   └── trip-planner/       one slice = one feature
    └── shared/                 reusable UI primitives (cross-cutting)

One thing to admit: for styling, I intentionally did not use any CSS framework and instead let AI generate the design based on my preferences. When I use Bootstrap or PrimeNG, the result often feels too generic and lacks personality. UI design has always been my kryptonite 🙂

How I Used Gemma 4

As the title suggests, Gemma 4 E2B is used in a smart way, but what does that actually mean?

It means I do not rely heavily on the model to orchestrate complex workflows through multiple MCP tools, large schemas or RAG pipelines. Since E2B and even E4B are relatively small models, you should not expect to send a prompt like:

“Generate a family trip for Saturday”

and always get a high-quality response.

Instead, a much more reliable solution is to use these models with smaller and more specialized prompts, while letting the backend handle most of the orchestration logic.

This reduces complexity on the model side and makes outputs more predictable and consistent.

Backend Orchestration

So what does my backend actually do? Let’s say the user writes a prompt like:

“Generate a family trip for Saturday near Brno.”

The first thing the backend needs to do is extract the user intent. That means determining the actual date and location of the trip.

This is a perfect first task for E2B, so the backend uses the BuildIntentionPrompt method to generate an intention prompt like this:

public string BuildIntentionPrompt(string userPrompt)
{
    var home = _options.Value;
    var today = _dateTimeProvider.GetDateOnly();

    return $$"""
        You are a trip intent extractor. Analyze the user message and return ONLY a valid JSON object — no markdown, no explanation, no code fences.

        Today's date is {{today:yyyy-MM-dd}} ({{today:dddd}}).
        Home location: "{{home.HomeName ?? "Home"}}" at latitude {{home.HomeLatitude}}, longitude {{home.HomeLongitude}}.

        Rules:
        - "date": resolve relative expressions like "Saturday", "Friday", "next weekend" to the nearest upcoming date in yyyy-MM-dd format.
        - "destination": the place name the user mentioned, or null if none.
        - "latitude" and "longitude": GPS coordinates of the destination. If no destination is mentioned, use the home coordinates.
        - "isHomeLocation": true if home coordinates are used, false if a destination was detected.
        - "preferredActivity": if the user expresses a preference for indoor or outdoor activities (e.g. "prefer indoor", "something outside", "stay inside"), set this to "Indoor" or "Outdoor". Otherwise set it to null.

        Return exactly this JSON structure:
        {
          "date": "yyyy-MM-dd",
          "destination": "City name or null",
          "latitude": 0.0,
          "longitude": 0.0,
          "isHomeLocation": true,
          "preferredActivity": "Indoor or Outdoor or null"
        }

        User message: {{userPrompt}}
        """;
}

And the model should return structured JSON output, from which the backend extracts the trip date and trip location, like this:

{
  "date": "2026-05-23",
  "destination": "Brno",
  "latitude": 49.1951,
  "longitude": 16.6068,
  "isHomeLocation": true,
  "preferredActivity": null
}

Next step in the backend is to fetch weather conditions based on the trip location. For weather data, I am using WeatherBit through RapidApi.

In my previous article, I tested E2B and E4B models for extracting GPS coordinates. The results were close to the destination, but not fully precise. However, for weather data this is actually fine, since being off by 5–10 km does not make a significant difference.

Once the weather data is available, the backend determines whether the trip is better suited for indoor, outdoor, or mixed activities. This property is already included in the JSON above, but it is nullable. If the user does not specify it in the prompt, the activity type can be inferred from the weather conditions, which is another task well suited for the model.

Activity prompt:

public string BuildActivityPrompt(ForecastWeatherDto forecastWeather)
{
    return $"""
        You are a family trip activity advisor. Based on the weather forecast below, decide whether the trip day is better suited for INDOOR activities, OUTDOOR activities, or BOTH.

        Rules:
        - Prefer OUTDOOR when: temperature avg >= 15°C AND cloud coverage <= 40% AND wind speed <= 10 m/s.
        - Prefer INDOOR when: temperature avg < 15°C OR cloud coverage > 60% OR wind speed > 10 m/s.
        - Prefer BOTH when: temperature avg >= 15°C AND cloud coverage between 40–60% AND wind speed <= 10 m/s.
        - Return ONLY one word: either "Indoor", "Outdoor", or "Both". No explanation, no punctuation.

        Forecast:
          - Date: {forecastWeather.ValidDate:yyyy-MM-dd}, Temp: {forecastWeather.MinTemp}°C–{forecastWeather.MaxTemp}°C (avg {forecastWeather.Temp}°C), Clouds: {forecastWeather.CloudsPercentage}%, Wind: {forecastWeather.WindSpeed} m/s
        """;
}

This prompt returns a single word, which I then map to an Activity enum:

Indoor

This step could also be implemented directly in the backend using simple business rules, but I intentionally kept it as an AI task to test how consistently E2B handles smaller classification prompts.

At this point, the backend has weather conditions, location data and the activity type, but one thing is still missing: places to visit, places to eat and parking options for the car.

For place discovery, the backend uses the Geoapify places API. The API has a generous daily request limit, which allows the application to query multiple categories such as activities, restaurants and parking. Since the activity type is already known at this stage, the backend can pre-filter which categories and places should be requested.

At this point, the backend has all required data to generate the final trip plan. I could let the backend orchestrate the final step by pre-filtering the resulting data, but I want to see if E2B is actually capable of handling a larger prompt and returning usable results. So the final prompt is built using BuildTripPlanPrompt:

public string BuildTripPlanPrompt(BuildTripPlanRequest request)
{
    var sb = new StringBuilder();

    // ── System role ──────────────────────────────────────────────────────────
    sb.AppendLine("You are a family trip planner. Your job is to select the best places from the provided lists and write a short plan summary.");
    sb.AppendLine();

    // ── Trip context ─────────────────────────────────────────────────────────
    sb.AppendLine("## Trip Details");
    sb.AppendLine($"- Destination: {request.Intention.Destination ?? "Home area"}");
    sb.AppendLine($"- Date: {request.Intention.Date:dddd, MMMM d yyyy}");
    sb.AppendLine($"- Activity preference: {request.ActivityType}");
    sb.AppendLine($"- Weather: avg {request.Weather.Temp:F1}°C, min {request.Weather.MinTemp:F1}°C, max {request.Weather.MaxTemp:F1}°C, clouds {request.Weather.CloudsPercentage:F0}%, wind {request.Weather.WindSpeed:F1} m/s");
    sb.AppendLine();

    // ── Candidate places ─────────────────────────────────────────────────────
    AppendPlaceList(sb, "Activities", request.Places.Activities
        .Select((p, i) => $"[A{i + 1}] {p.Name} | {p.Category} | {p.ActivityType} | {p.DistanceMeters:F0} m | {p.Address}"));

    AppendPlaceList(sb, "Restaurants", request.Places.Restaurants
        .Select((p, i) => $"[R{i + 1}] {p.Name} | {string.Join(", ", p.Categories.Take(2))} | {p.DistanceMeters:F0} m | {p.Address}"));

    AppendPlaceList(sb, "Parking", request.Places.Parking
        .Select((p, i) => $"[P{i + 1}] {p.Name ?? "Unnamed parking"} | {p.ParkingType} | {p.DistanceMeters:F0} m | {p.Address}"));

    // ── Output rules ─────────────────────────────────────────────────────────
    sb.AppendLine("## Rules");
    sb.AppendLine("- Pick exactly 2 or 3 activities, 2 or 3 restaurants, and 2 or 3 parking spots.");
    sb.AppendLine("- Prefer places CLOSER to the destination (smaller distance is better).");
    sb.AppendLine($"- For activities, prefer {request.ActivityType} options that match the weather.");
    sb.AppendLine("- For restaurants, prefer variety in cuisine when possible.");
    sb.AppendLine("- For parking, prefer covered or multi-storey on cloudy/rainy days.");
    sb.AppendLine("- Write a 2-3 sentence plain-English summary of the day plan.");
    sb.AppendLine();

    // ── Required output format ────────────────────────────────────────────────
    sb.AppendLine("## Output format");
    sb.AppendLine("Return ONLY a JSON object. No explanation before or after it.");
    sb.AppendLine("Use the exact IDs from the lists above (e.g. A1, R2, P1).");
    sb.AppendLine();
    sb.AppendLine("```
{% endraw %}
json");
    sb.AppendLine("{");
    sb.AppendLine("  \"activities\": [\"A1\", \"A3\"],");
    sb.AppendLine("  \"restaurants\": [\"R2\", \"R4\"],");
    sb.AppendLine("  \"parking\": [\"P1\", \"P2\"],");
    sb.AppendLine("  \"summary\": \"A short description of the trip plan.\"");
    sb.AppendLine("}");
    sb.AppendLine("
{% raw %}
```");

    return sb.ToString();
}

And that’s it. The model returns a JSON response, which I deserialize and send to the frontend.

For places, there is a limit: I pass 10 places for each category, so the model selects from a pool of around 30 places in total.

Algorithm pseudocode

Above section was about prompts, but to better understand how the backend actually orchestrates the planning endpoint, there is a pseudocode example. This shows a smart way of using smaller LLM models:

FUNCTION HandleAsync(request, cancellationToken):

  // 1. Validate the incoming request
  validationResult = Validate(request)
  IF validation failed:
    RETURN 400 Bad Request with error messages

  // 2. Extract the user's travel intention from the prompt (AI call)
  intentionResult = ExtractIntention(request.Prompt)
  IF extraction failed:
    RETURN 500 Internal Server Error with error messages

  // intention now contains: location (lat/lon), travel date, preferred activity (optional)

  // 3. Get weather forecast for that location and date
  weatherResult = GetWeatherForecast(intention.Latitude, intention.Longitude, intention.Date)
  IF weather fetch failed:
    RETURN 500 Internal Server Error with error messages

  // 4. Determine the activity type (outdoor vs indoor)
  IF user specified a preferred activity:
    activity = intention.PreferredActivity
  ELSE:
    // Let AI decide based on weather conditions
    activitiesResult = GetActivityByWeather(weatherResult)
    IF activity suggestion failed:
      RETURN 500 Internal Server Error with error messages
    activity = activitiesResult.Value

  // 5. Find relevant places near the location for that activity
  placesRequest = { Latitude, Longitude, Activity, RadiusInMeters }
  placesResult = GetTripPlaces(placesRequest)
  IF places fetch failed:
    RETURN 500 Internal Server Error with error messages

  // 6. Generate the final trip plan (AI call)
  planResult = GenerateTripPlan({
    Intention = intentionResult,
    Weather   = weatherResult,
    Activity  = activity,
    Places    = placesResult,
    SessionId = request.SessionId
  })
  IF plan generation failed:
    RETURN 500 Internal Server Error with error messages

  // 7. Return the generated trip plan
  RETURN 200 OK with planResult

The prompt for the last step could be more orchestrated, for example, the backend could provide fewer places to choose from, but I think E2B handles it fairly well.

Validation and Resilience

One last thing I want to highlight is user prompt validation and resilience when calling the model itself. Both are extremely important in real-world AI applications.

Validating user prompts before sending them to the model improves reasoning quality and also helps prevent prompt injection attempts or unsupported input patterns. Below is a simplified example of the validation logic used for incoming prompts:

public Result Validate(CreateTripPlanCommand query)
{
    if (string.IsNullOrWhiteSpace(query.Prompt))
    {
        return Result.Fail("Prompt must not be empty.");
    }

    var trimmed = query.Prompt.Trim();

    if (trimmed.Length < MinLength)
    {
        return Result.Fail($"Prompt must be at least {MinLength} characters long.");
    }

    if (trimmed.Length > MaxLength)
    {
        return Result.Fail($"Prompt must not exceed {MaxLength} characters.");
    }

    if (!AllowedCharactersRegex.IsMatch(trimmed))
    {
        return Result.Fail("Prompt contains invalid characters.");
    }

    foreach (var pattern in PromptInjectionPatterns)
    {
        if (trimmed.Contains(pattern, StringComparison.OrdinalIgnoreCase))
        {
            return Result.Fail("Prompt contains content that cannot be processed.");
        }
    }

    foreach (var pattern in OffTopicPatterns)
    {
        if (trimmed.Contains(pattern, StringComparison.OrdinalIgnoreCase))
        {
            return Result.Fail("Prompt contains content that is not related to trip planning.");
        }
    }

    return Result.Ok();
}

Once the prompt passes validation, the backend can continue with the model call. However, another important question is: what happens if the model returns an invalid response or the request fails unexpectedly?

For this, I use a resilience pipeline with retries. In C#, this can be implemented using the Polly library.

private static readonly ResiliencePipeline RetryPipeline = new ResiliencePipelineBuilder()
    .AddRetry(new RetryStrategyOptions
    {
        MaxRetryAttempts = 3,
        Delay = TimeSpan.FromSeconds(2),
        BackoffType = DelayBackoffType.Exponential,
        UseJitter = true,
        ShouldHandle = new PredicateBuilder()
              .Handle<Exception>(ex => ex is not OperationCanceledException)
    })
    .Build();

public async Task<string> GetResponseAsync(string prompt, CancellationToken cancellationToken) =>
    await RetryPipeline.ExecuteAsync(async ct =>
    {
        var builder = new StringBuilder();
        await foreach (ChatResponseUpdate item in
            _chatClient.GetStreamingResponseAsync(
                [new(ChatRole.User, prompt)],
                ModelOptions,
                ct))
        {
            builder.Append(item.Text);
        }
        return builder.ToString();
    }, cancellationToken);

This pipeline catches exceptions and retries the request up to 3 times using exponential backoff with delay between attempts. Resilience pipelines are useful not only for model calls, but for any external API or infrastructure dependency, since temporary failures are common in distributed systems.

For LLM integrations specifically, retries can also improve output quality. Besides handling exceptions, the backend can validate the generated output and retry the request if the response is deformed, incomplete, or clearly hallucinated.

Both of these defensive backend patterns are used in the solution. The actual resilience implementation is more advanced, but the example above was intentionally simplified to focus on the core idea.

Benchmark

Architecture and Orchestration are important, but what really matters is how these decisions perform in practice.

Following the previous article I couldn’t leave out some reasoning and speed benchmarks. This time, however, the results come from real application usage during testing.

Generation tokens per second were measured using real prompts generated by the API and user requests. The values in the table represent the average of 5 runs for each prompt. Model warm-up was performed using 4 different prompts before benchmarking.

All tests were run using Ollama version 0.23.2 with default model settings on an Intel i5-6400, 24 GB RAM, and an NVIDIA GeForce GTX 950 with 2 GB VRAM.

	Intention prompt	Activity prompt	Plan prompt
Generation Tokens/s (avg)	9.64	12.65	8.65

Tested prompts are included below.

Intention prompt

Click to expand Intention prompt

You are a trip intent extractor. Analyze the user message and return ONLY a valid JSON object — no markdown, no explanation, no code fences.

Today's date is 2026-05-19 (Tuesday).
Home location: "Brno" at latitude 49.1951, longitude 16.6068.

Rules:
- "date": resolve relative expressions like "Saturday", "Friday", "next weekend" to the nearest upcoming date in yyyy-MM-dd format.
- "destination": the place name the user mentioned, or null if none.
- "latitude" and "longitude": GPS coordinates of the destination. If no destination is mentioned, use the home coordinates.
- "isHomeLocation": true if home coordinates are used, false if a destination was detected.
- "preferredActivity": if the user expresses a preference for indoor or outdoor activities (e.g. "prefer indoor", "something outside", "stay inside"), set this to "Indoor" or "Outdoor". Otherwise set it to null.

Return exactly this JSON structure:
{
  "date": "yyyy-MM-dd",
  "destination": "City name or null",
  "latitude": 0.0,
  "longitude": 0.0,
  "isHomeLocation": true,
  "preferredActivity": "Indoor or Outdoor or null"
}

User message: Plan a family day in Prague next Saturday with kids who love museums

Activity prompt

Click to expand Activity prompt

You are a family trip activity advisor. Based on the weather forecast below, decide whether the trip day is better suited for INDOOR activities, OUTDOOR activities, or BOTH.

Rules:
- Prefer OUTDOOR when: temperature avg >= 15°C AND cloud coverage <= 40% AND wind speed <= 10 m/s.
- Prefer INDOOR when: temperature avg < 15°C OR cloud coverage > 60% OR wind speed > 10 m/s.
- Prefer BOTH when: temperature avg >= 15°C AND cloud coverage between 40–60% AND wind speed <= 10 m/s.
- Return ONLY one word: either "Indoor", "Outdoor", or "Both". No explanation, no punctuation.

Forecast:
  - Date: 2026-05-22, Temp: 12.9°C–16.5°C (avg 14.4°C), Clouds: 70%, Wind: 4.4 m/s

Plan prompt

Click to expand Plan prompt

You are a family trip planner. Your job is to select the best places from the provided lists and write a short plan summary.

## Trip Details
- Destination: Prague
- Date: Saturday, May 23 2026
- Activity preference: Indoor
- Weather: avg 18.8°C, min 11.9°C, max 25.0°C, clouds 24%, wind 2.5 m/s

## Available Activities
[A1] Národní galerie v Praze - Palác Kinských | entertainment.museum | Indoor | 120 m | National Gallery in Prague - Kinský Palace, Old Town Square, 110 00 Prague, Czechia
[A2] Central Gallery | entertainment.museum | Indoor | 140 m | Central Gallery, Old Town Square 15, 110 00 Prague, Czechia
[A3] Sklářské muzeum Moser | entertainment.museum | Indoor | 142 m | Sklářské muzeum Moser, Old Town Square 15, 110 00 Prague, Czechia
[A4] Galerie Zlatá lilie | entertainment.museum | Indoor | 142 m | Galerie Zlatá lilie, Malé náměstí, 116 65 Prague, Czechia
[A5] Sex Machines Museum | entertainment.museum | Indoor | 145 m | Sex Machines Museum, Melantrichova 18, 110 00 Prague, Czechia
[A6] Madame Tussauds | entertainment.museum | Indoor | 182 m | Madame Tussauds, Celetná 6, 110 00 Prague, Czechia
[A7] Choco-Story Muzeum čokolády | entertainment.museum | Indoor | 213 m | Choco-Story Chocolat Museum, Celetná 557/10, 110 00 Prague, Czechia
[A8] Muzeum hlavního města Prahy - Dům U Zlatého prstenu | entertainment.museum | Indoor | 215 m | City of Prague Museum - House at the Golden Ring, Týnská, 110 00 Prague, Czechia
[A9] Památník Jaroslava Ježka (Modrý pokoj) | entertainment.museum | Indoor | 221 m | Jaroslav Ježek Memorial, Kaprova, 115 72 Prague, Czechia
[A10] Czech Beer Museum | entertainment.museum | Indoor | 229 m | Czech Beer Museum, Husova 156/21, 110 00 Prague, Czechia

## Available Restaurants
[R1] Ristorante San Remo | catering, catering.restaurant | 25 m | Ristorante San Remo, Mikulášská 6, 110 00 Prague, Czechia
[R2] Trdelník | catering, catering.fast_food | 28 m | Trdelník, Mikulášská 4, 110 00 Prague, Czechia
[R3] San Nicola | catering, catering.fast_food | 32 m | San Nicola, Mikulášská, 115 72 Prague, Czechia
[R4] Lippert | catering, catering.restaurant | 36 m | Lippert, Mikulášská 2, 110 00 Prague, Czechia
[R5] Trdelník | catering, catering.cafe | 51 m | Trdelník, Franz Kafka Square, 115 72 Prague, Czechia
[R6] Meet Burger | catering, catering.restaurant | 54 m | Meet Burger, Franz Kafka Square, 115 72 Prague, Czechia
[R7] Ambiente Brasileiro | catering, catering.restaurant | 56 m | Ambiente Brasileiro, U Radnice 8, 110 00 Prague, Czechia
[R8] Pauseteria | catering, catering.restaurant | 57 m | Pauseteria, U Radnice, 115 72 Prague, Czechia
[R9] Capriccio | catering, catering.restaurant | 58 m | Capriccio, Franz Kafka Square 7, 110 00 Prague, Czechia
[R10] Kotleta | catering, catering.restaurant | 68 m | Kotleta, U Radnice 2, 110 00 Prague, Czechia

## Available Parking
[P1] Unnamed parking | access | 66 m | Old Town Square, 110 00 Prague, Czechia
[P2] P1-0518 | access_limited | 75 m | P1-0518, U Radnice, 115 72 Prague, Czechia
[P3] P1-0281 | access_limited | 91 m | P1-0281, Kaprova, 115 72 Prague, Czechia
[P4] P1-0277 | access_limited | 94 m | P1-0277, Pařížská, 115 72 Prague, Czechia
[P5] P1-0276 | access_limited | 102 m | P1-0276, Old Town Square, 110 00 Prague, Czechia
[P6] P1-0277 | access_limited | 106 m | P1-0277, Pařížská, 115 72 Prague, Czechia
[P7] P1-0279 | access_limited | 116 m | P1-0279, Maiselova, 115 72 Prague, Czechia
[P8] P1-0319 | access | 124 m | P1-0319, Platnéřská, 115 72 Prague, Czechia
[P9] P1-0323 | access_limited | 127 m | P1-0323, Linhartská, 115 72 Prague, Czechia
[P10] P1-0319 | access | 129 m | P1-0319, Platnéřská, 115 72 Prague, Czechia

## Rules
- Pick exactly 2 or 3 activities, 2 or 3 restaurants, and 2 or 3 parking spots.
- Prefer places CLOSER to the destination (smaller distance is better).
- For activities, prefer Indoor options that match the weather.
- For restaurants, prefer variety in cuisine when possible.
- For parking, prefer covered or multi-storey on cloudy/rainy days.
- Write a 2-3 sentence plain-English summary of the day plan.

## Output format
Return ONLY a JSON object. No explanation before or after it.
Use the exact IDs from the lists above (e.g. A1, R2, P1).

json
{
  "activities": ["A1", "A3"],
  "restaurants": ["R2", "R4"],
  "parking": ["P1", "P2"],
  "summary": "A short description of the trip plan."
}

The results from the intention and activity prompts were consistently correct during testing. Looking at the performance numbers, the intention prompt achieved an average generation speed of 9.64 tokens/s, while the activity prompt reached 12.65 tokens/s. This difference is expected because the activity prompt is simpler and returns only a single-word response.

The planning prompt was the slowest at 8.65 tokens/s, but that was also expected since it is the largest prompt and requires more reasoning to select and summarize relevant places. Despite that, the generated outputs were consistently good and usable in practice.

I also measured the average API response time for the prompts like:

"Plan a family day in London next Saturday with kids who love museums"

The average response time was 30.66 seconds.

This number can be slightly misleading because it includes the full orchestration pipeline, not just the model reasoning time. The request performs 3 dependent model calls and 4 external API calls, but still I think it is interesting to see how quickly the complete response is generated under real application conditions.

MVP Scope and Next Steps

As this is still an MVP (Minimum Viable Product), the application is a work in progress, and there is plenty left to improve.

In the next release, I want to focus on long-term memory, where users can tell the application whether they liked a trip and save favorite places. Then, when planning future trips, the model could also recommend places the family already enjoys.

Another area I want to improve is short-term context handling, allowing users to refine the trip plan during the conversation or set preferences such as favorite cuisine.

For long-term memory, I would like to experiment with an MCP server, but I will see whether E2B can handle it well or whether I will end up using backend orchestration again.

I would also like to improve performance and reduce response times.

Most future features will probably come from real usage, since I am already using the application myself and plan to continue using it.

Known Limitations

Gemma 4 E2B is not deterministic, so outputs may occasionally be invalid or incomplete.

Location resolution and place selection are based on approximate GPS and point of interest data.

Place data quality depends on Geoapify coverage, which may be incomplete in rural or less populated regions.

The current average response time of ~30 seconds is acceptable for an MVP where correctness matters more than speed, but it would need significant reduction before this could feel like a polished product.

Summary

In this article, I showed my MVP of the Family Trip Advisor app powered by the Gemma 4 E2B model, implemented using best practices for API design and backend orchestration.

Family Trip Advisor tries to solve a common problem many people face when planning trips by generating useful suggestions from a single, simple prompt.

The core idea behind the app is that you do not need the most advanced reasoning models to build useful AI applications. With a well-designed architecture and proper task decomposition, you can achieve strong results without heavy hardware requirements or expensive models.

This approach relies on keeping the model focused on small, well-defined tasks while the backend handles orchestration and structure.

The main tradeoff of using small models is that output quality depends heavily on how well the backend structures the input data. Because of that, I recommend validating outputs.

I hope this article and the app itself demonstrate that the E2B model is not just “good enough,” but actually excellent for real-world usage when used correctly.

In the next version, I will experiment with MCP for long-term memory and continue improving performance and user experience.

DEV Community: Daniel Balcarek

To Retry or Not to Retry? That Is the Question.

What I Benchmarked

Scenarios

Models Tested

Findings

Three Runs, Not Just One

Model Efficiency

What I Learned

My Benchmark

Polly Introduces an Open Source Maintenance Fee

From Open Source to Paid Product: Is AI Accelerating the Shift?

API Performance Testing: How to Design Realistic Tests

Table of Contents

Basic Definition

Types of Tests

How to Properly Design Performance Tests

Defining the Expected Load

Performance Testing and External Services

Environment Configuration

Metrics and Results

Summary

How I Smashed a Bug in a Shared Authentication Library

From Open Source to Paid Product: Is AI Accelerating the Shift?

What do you think?

How AI Endpoints Change the Traditional API Flow

Table of Contents

Conventional Web API Endpoint Flow

AI-powered Web API Endpoint Flow

What This Difference Changes

Unpredictable Latency

Retry Logic

Idempotency and Side Effects

Testing AI Endpoints

The Output Contract

Observability and Cost

Summary

PrimeTek announced PrimeUI licensing for future PrimeNG, PrimeReact and PrimeVue versions. Existing MIT versions stay MIT. Big change for frontend teams. https://primeui.dev/nextchapter

PrimeUI

Build a Minimal WebMCP Agent with Playwright and Gemini

Table of Contents

Prerequisites

Prepare the Solution

Check if modelContext Exists

Read Exposed WebMCP Tools

Execute a WebMCP Tool

Create a Minimal Agent Proof of Concept

Gen AI SDK

Agent Creation

What This Proves

Repositories

Summary

Tower Before Dusk: I Built a Puzzle Game for Humans and AI

What I Built

Video Demo

Code

Gramli / tower-before-dusk

A TypeScript puzzle game demonstrating WebMCP, where humans and AI solve the same challenges under the same rules.

Tower Before Dusk

Features

How I Built It

Interesting Thoughts

The Sunset Arrives

I Used My Last 7% of Copilot Tokens to Bring a 2014 WinForms Game Back to Life

What I Built

Demo

Try Both Versions

The Comeback Story

Architecture Change

Responsive Design & Game Control

My Experience with GitHub Copilot

Building with Gemma 4 E2B showed me that small models are more reliable when the backend handles orchestration.

How to Use Gemma 4 E2B the Smart Way: Family Trip Advisor

How to Use Gemma 4 E2B the Smart Way: Family Trip Advisor

Table of Contents

What I Built

Demo

Gramli / familly-trip-advisor

🗺️ Family Trip Advisor

How It Works