DEV Community: Himanshu Kumar

The smolagents bug that made my agent retry the same valid code three times

Himanshu Kumar — Mon, 20 Jul 2026 07:19:13 +0000

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

Third entry in the DEV x Sentry Bug Smash. Entry 1 was a crash with a confusing message. Entry 2 was a freeze the timeout could not catch. This one is quieter and sneakier: valid Python that the sandbox rejects with an error pointing at the wrong thing entirely.

When the open issues run out, fuzz

By entry 3 every obvious open smolagents bug was already claimed or had a competing PR. So instead of reading the issue tracker I pointed a small fuzzer at the piece of smolagents that runs the most untrusted code: LocalPythonExecutor, the sandbox that executes model-generated Python.

The method is boring and effective: feed it ordinary, valid Python one snippet at a time, and flag anything that raises InterpreterError. Valid Python that the sandbox refuses to run is, by definition, a bug, because the model writes valid Python and expects it to work.

That surfaced four unreported bugs in one afternoon. This post is about the one I shipped: dict unpacking.

The bug

config = {**{"temperature": 0.7, "max_tokens": 512}, "top_p": 0.9}

Merging dicts with ** is one of the most common things an LLM writes. Under smolagents it fails with:

InterpreterError: NoneType is not supported.

There is no None anywhere in that line. The message sends you looking for a null value that does not exist.

Why it happens

In Python's AST, a dict literal keeps its keys and values in two parallel lists. For a normal entry the key is an AST node. For a **mapping spread entry, the key is literally None, a signal that says "this is a spread, not a key/value pair."

smolagents evaluated every key by walking expression.keys and calling evaluate_ast(key, ...) on each one. When the key is None, that call falls through every isinstance branch to the catch-all raise InterpreterError(f"{type} is not supported"). So the spread marker got evaluated as if it were an expression, and the model got blamed for a None it never wrote.

Why silence is the expensive part

Here is the part the Sentry view made obvious. The error is handled: the agent catches it and feeds it back to the model as "here is what went wrong, try again." But the message names NoneType, and the model's code has no None, so the model cannot act on it. It retries the exact same valid syntax. And again. Every step burns a real LLM call and a slot in the step budget until the run gives up.

One bug, one misleading message, three identical failures:

Three events on a single issue is not noise. It is the agent stuck in a loop, and without Sentry counting the events you would never see the loop, only a run that quietly underperformed. Sentry's Seer read the same event and reached the exact root cause:

smolagents' LocalPythonExecutor doesn't handle dict unpacking (**) syntax: None keys in ast.Dict cause an unsupported type error. [...] evaluate_ast(None, ...) matches no isinstance branch and falls to the else clause. The interpreter raises InterpreterError: NoneType is not supported, the agent retries with identical code, burning steps in a loop.

The fix

Evaluate the dict pairwise instead of evaluating keys blindly. A None key means "merge this mapping":

result = {}
for key_node, value_node in zip(expression.keys, expression.values):
    if key_node is None:
        value = evaluate_ast(value_node, *common_params)
        if not hasattr(value, "keys"):
            raise InterpreterError(f"'{type(value).__name__}' object is not a mapping")
        result.update(value)
    else:
        key = evaluate_ast(key_node, *common_params)
        result[key] = evaluate_ast(value_node, *common_params)
return result

This matches CPython exactly: spreads merge in order, later keys win, and unpacking a non-mapping raises 'list' object is not a mapping.

A reviewer caught my fix being too strict

I first gated the spread on isinstance(value, Mapping). Minutes after the PR opened, OpenAI's Codex reviewer flagged it (P2): CPython does not require the Mapping ABC, it only requires an object with a keys() method. Since the sandbox lets users define their own classes, a duck-typed mapping with keys() and __getitem__() would have been wrongly rejected. I switched the check to hasattr(value, "keys") and added a test for exactly that case. AI wrote the code, AI reviewed the code, I kept score.

After

On the patched build the same line just runs:

app: step 1 ok, config = {'temperature': 0.7, 'max_tokens': 512, 'top_p': 0.9}

One step, no loop, no phantom None.

Numbers

4 unreported bugs found by fuzzing valid Python through the sandbox; this is the first fix
Misleading NoneType error reproduced on current main and 1.26.0
3 wasted agent steps per occurrence, visible only because Sentry counts events
9 new tests: spreads, double spreads, override order both ways, a duck-typed mapping class, empty spread, non-mapping rejection
406 passing, ruff clean

Links

The pattern across all three entries: the worst agent bugs do not throw a red stack trace at you. They hand the model a plausible-but-wrong message and let it fail politely, on repeat. Count your events.

One line of math froze my AI agent forever. The timeout watched and did nothing.

Himanshu Kumar — Sun, 19 Jul 2026 07:54:58 +0000

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

This is my second entry for the DEV x Sentry Bug Smash challenge. Entry #1 was a crash with a confusing error message. This one is the opposite and it is scarier: no crash, no message, no event. Just silence.

The bug that sends you nothing

smolagents runs LLM-generated Python in a sandboxed executor with a timeout. Issue #2473 claims that one line of model-generated math defeats it completely:

from smolagents.local_python_executor import LocalPythonExecutor

executor = LocalPythonExecutor(additional_authorized_imports=[], timeout_seconds=2)
executor.send_tools({})
executor("10 ** 10 ** 8")  # 2 second timeout. Should be fine, right?

I ran this with a 2 second timeout and a faulthandler bomb set for 20 seconds. The timeout never fired. The process sat frozen until the external kill. An agent that generates this expression (and "compute this huge number" is exactly the kind of thing agents try) freezes its host process forever.

Zero comments on the issue, zero PRs. Mine now.

Why the timeout lies to you

smolagents' timeout is thread based: a worker thread runs the code, the main thread waits in future.result(timeout=2). That design is fine for almost everything, because CPython switches threads between bytecode instructions.

But 10 ** 10 ** 8 is not "almost everything". CPython computes arbitrary precision **, << and * inside a single C call that holds the GIL from start to finish. No bytecode boundary, no thread switch, no timeout. The result would have about 400 million bits. The computation takes somewhere between minutes and hours. Your watchdog needs the GIL to wake up, and it never gets it.

The faulthandler dump made it concrete, and it was worse than the issue described:

Thread 0x16d1f3000 (worker):
  File "local_python_executor.py", line 753 in evaluate_binop   <- computing the pow

Thread 0x1f00d5e80 (main):
  File "threading.py", line 999 in start
  File "concurrent/futures/thread.py", line 180 in submit       <- never returned!

The main thread was still stuck inside ThreadPoolExecutor.submit. It never even reached future.result. The 2 second timer never armed at all.

The existing MAX_OPERATIONS guard (10 million AST operations) does not help either. This is a handful of AST nodes. The entire cost lives inside one of them.

The Sentry angle: monitoring for absence

Entry #1 was about a noisy failure. This bug is the opposite. I pointed a fresh Sentry project at a simulated agent run on the unpatched PyPI release (1.26.0) and got the most unsettling result possible: nothing. No event, no transaction, an empty project. The process was frozen mid-transaction and the SDK never got a chance to flush.

The lesson: for freeze-class bugs you need a supervisor. I added a small watchdog process that gives the worker 25 seconds, then kills it and reports what it saw, with the worker's faulthandler stack attached as evidence:

watchdog: starting worker (before) with 25s budget
worker: smolagents 1.26.0
worker: step 1 executing 'result = 10 ** 10 ** 8'...
watchdog: worker FROZE, killed it, reporting to Sentry

The resulting Sentry issue carries the whole story in one place: environment tagged before, handled by the supervisor, with the frozen frame (evaluate_binop, line 753 of local_python_executor.py) sitting in the attached worker_faulthandler_stack extra.

Sentry's Seer ran root cause analysis on that issue and independently landed on the same conclusion: signal and thread interruption need the GIL, and a single C-level big-int operation never releases it.

Seer's verdict, verbatim:

CodeAgent's 2s timeout uses Python signal-based interruption, which cannot fire during uninterruptible C-level big-int operations that hold the GIL. [...] A single large big-integer arithmetic operation runs entirely as one C-level call that holds the GIL continuously without yielding. CPython cannot deliver signals or switch threads during an uninterruptible C extension call, so no timeout callback fires for the duration of that operation.

The fix: you cannot interrupt it, so refuse to start it

Killing the computation mid-flight is impossible from Python. But predicting the damage is O(1). Before executing **, << or * on integers, the executor now estimates the result's bit length from the operands' bit lengths:

if op == "**":
    estimated_bits = left.bit_length() * right       # upper bound
elif op == "<<":
    estimated_bits = left.bit_length() + right
elif op == "*":
    estimated_bits = left.bit_length() + right.bit_length()

Above 1 million bits (about 300k digits, still generous) it raises an informative InterpreterError:

Operation '**' would produce an integer of around 400000000 bits, exceeding
the maximum of 1000000 bits allowed. Use smaller operands, or
pow(base, exp, mod) for modular exponentiation.

That message matters. The agent surfaces it to the model, and the model can actually act on it: use pow(base, exp, mod), which stays unrestricted because modular exponentiation is fast and legitimate. The agent recovers on the next step instead of hanging the host.

The after run on the patched build: the guard rejects the expression in 0.0 seconds, the error lands in Sentry as a normal actionable issue and step 2 executes fine.

watchdog: starting worker (after) with 25s budget
worker: smolagents 1.27.0.dev0
worker: step 1 error surfaced to the model: InterpreterError: ...
worker: step 2 executing '2 + 2'...
worker: step 2 ok
worker: DONE
watchdog: worker exited with code 0

A robot reviewed my robot fix

Minutes after I opened the PR, OpenAI's Codex reviewer flagged a real hole: my guard checked type(x) is int, which lets bool and int subclasses slip through. True << 10**9 and class BigInt(int) still reached the uninterruptible C calls. Fixed with isinstance, added both as regression tests. AI found the bug class, AI fixed it, AI reviewed the fix. I just steered.

Numbers

Freeze reproduced at 20+ seconds (would have run for hours), external kill required
Fix rejects the same expression in 0.0 seconds
9 explosive patterns blocked: **, <<, chained *, all augmented forms, pow(a, b), bool and int subclass variants
10 legitimate operations verified untouched: 100! via repeated *=, pow(7, 2**64, 97), float pow, 1 ** 10**9
19 new tests, full test file 416 passed, ruff clean
The blocked-pattern tests hang forever on unpatched main. I verified that the honest way, with a stash and a kill switch.

Links

The scariest bugs are not the ones that page you at 3am. They are the ones that make sure nothing ever pages you at all. Instrument for silence.

I fixed a smolagents bug that confused everyone who hit it (with Sentry watching the whole time)

Himanshu Kumar — Thu, 16 Jul 2026 05:31:48 +0000

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

Project Overview

I picked huggingface/smolagents, the 28k+ star agent framework where agents literally think in Python code. It had a bug open since issue #1108 that anyone combining MCP tools with agent serialization would eventually slam into.

Call agent.to_dict() on a CodeAgent holding MCP tools (or save() or push_to_hub(), same path) and you get this beauty:

ValueError: Tool validation failed for MCPAdaptTool:
Parameters in __init__ must have default values, found required parameters: name, description, inputs, output_type
- forward: Name 'func' is undefined.
- forward: Name 'mcp' is undefined.

func is undefined? mcp is undefined? I never wrote a forward method. If you hit this in the wild you'd have zero idea what you did wrong. Spoiler: you did nothing wrong.

Bug Fix or Performance Improvement

smolagents serializes tools by reconstructing standalone Python source for the tool class. Tool.to_dict calls validate_tool_attributes() which does static AST analysis, then instance_to_source() so Tool.from_code can rebuild the tool later from source alone.

That contract can never hold for MCP tools. MCPAdaptTool is generated at runtime by mcpadapt inside a closure. Its __init__ takes required parameters and its forward closes over the live MCP client session (func, mcp, logger...). The tool's actual behavior lives on the MCP server, not in Python source. There is no source to reconstruct, so the AST validator chokes on a class that was never meant to pass it.

The interesting part: Tool.to_dict already fails fast with a clear message for three other runtime generated wrappers (Spaces, LangChain, Gradio). MCP tools were just missing from that guard.

Sometimes the right fix isn't making the impossible possible, it's failing loudly and helpfully. Recreating a live MCP session from serialized state would mean silently re-establishing server connections with credentials and trust decisions the library has no business making. So I extended the existing guard to detect MCP tools and raise this instead:

ValueError: Cannot serialize MCP tool 'echo_tool': it wraps a live MCP server session, which cannot be
saved as standalone code. Remove MCP tools from your agent before calling to_dict, save or push_to_hub,
and recreate them with MCPClient or ToolCollection.from_mcp when loading the agent.

From "what is func" to "here's exactly what to do instead" in one guard clause.

Code

Raise informative error when serializing MCP tools #2528

himanshu748 posted on Jul 14, 2026

Fixes #1108

Problem

Calling to_dict() (and therefore save() or push_to_hub()) on an agent that holds MCP tools crashes with a confusing internal error:

ValueError: Tool validation failed for MCPAdaptTool:
Parameters in __init__ must have default values, found required parameters: name, description, inputs, output_type
- forward: Name 'func' is undefined.
- forward: Name 'mcp' is undefined.
...

Reproduction (stdio MCP server, same shape as the tests in tests/test_mcp_client.py):

from mcp import StdioServerParameters
from smolagents import CodeAgent, InferenceClientModel
from smolagents.mcp_client import MCPClient

server_parameters = StdioServerParameters(command="python", args=["-c", echo_server_script])
with MCPClient(server_parameters) as tools:
    agent = CodeAgent(model=InferenceClientModel(), tools=list(tools))
    agent.to_dict()  # ValueError: Tool validation failed for MCPAdaptTool: ...

Root cause

Tool.to_dict serializes a tool by reconstructing standalone source code for its class: it calls validate_tool_attributes(self.__class__) and instance_to_source(...) so that Tool.from_code can later rebuild the tool from that source alone.

That contract cannot hold for MCP tools. MCPAdaptTool is generated at runtime by mcpadapt, its __init__ takes required parameters and its forward is a closure over the live MCP client session (func, mcp, logger, ...). The tool's behavior lives on the MCP server, not in Python source, and the underlying connection is not serializable, so source reconstruction fails validation with the cryptic error above.

Tool.to_dict already fails fast with a clear message for the other three runtime generated wrapper classes (SpaceToolWrapper, LangChainToolWrapper, GradioToolWrapper). MCP tools were missing from that guard.

Fix

Extend the existing guard in Tool.to_dict to detect MCP tools and raise an actionable error:

ValueError: Cannot serialize MCP tool 'echo_tool': it wraps a live MCP server session, which cannot be
saved as standalone code. Remove MCP tools from your agent before calling to_dict, save or push_to_hub,
and recreate them with MCPClient or ToolCollection.from_mcp when loading the agent.

Detection matches the runtime class name, following the existing convention in the same block, since mcpadapt is an optional dependency. The from_dict direction needs no change: serialization now fails fast with a clear message, and recreating a live MCP session is a user decision (server lifecycle, credentials, trust) that Tool.from_code could never perform safely.

A note documenting the limitation is added to the MCP section of the tools tutorial.

Tests

Two tests in tests/test_mcp_client.py, using the existing echo_server_script stdio fixture:

test_mcp_tool_to_dict_raises_informative_error: tool.to_dict() raises the clear error.
test_agent_to_dict_with_mcp_tool_raises_informative_error: CodeAgent.to_dict() raises the clear error (the exact scenario from the issue).

Both fail on main with the old Tool validation failed for MCPAdaptTool error and pass with this change. make quality passes. tests/test_mcp_client.py (7 passed), tests/test_tools.py and the agent serialization tests in tests/test_agents.py pass locally; the two pre-existing failures in test_integration_from_mcp_with_streamable_http and test_integration_from_mcp_with_sse also fail on a clean main checkout (local port binding) and are unrelated.

View on GitHub

PR: https://github.com/huggingface/smolagents/pull/2528 (Fixes #1108)

Two new tests using the existing stdio echo server fixture, both fail on main and pass with the fix. make quality clean. Docs note added to the MCP tools tutorial so nobody has to learn this the hard way again.

My Improvements

Users hitting this now get an actionable error instead of AST validator internals
The fix follows the repo's existing convention exactly (same guard block, same style as the Space/LangChain/Gradio cases), which is what makes a one-commit PR actually mergeable
Documented the limitation where users would look for it
Regression tests covering both the raw tool and the full CodeAgent scenario from the original issue

Best Use of Sentry

This is where it gets fun. I built a small demo agent app (a weather checkpoint agent using my patched smolagents with an MCP tool) and wired in the Sentry Python SDK with error monitoring, tracing and AI agent monitoring before touching the fix.

Step 1: catch the crash. Running the demo on unpatched smolagents, the cryptic ValueError landed straight in Sentry as an unhandled issue with the full 20+ line "undefined name" spam captured.

Step 2: let Seer take a shot. I ran Seer root cause analysis on the captured issue. Its diagnosis, fully independent of my PR:

MCPAdaptTool is a dynamically generated inner class created by mcpadapt's SmolAgentsAdapter.adapt() closure, so its init has required parameters and its methods reference closure variables that are not visible as class-level attributes... making it fundamentally incompatible with smolagents' static source-code validation.

Which is, almost line for line, the root cause I wrote in the PR. AI-assisted debugging where the AI and the human converge on the same diagnosis independently is exactly the confidence check you want before shipping a fix upstream.

Step 3: verify and resolve. Same demo on the patched version runs clean, agent traces show the gen_ai spans (invoke_agent, execute_tool) nested under the workflow and the Sentry issue is marked resolved.

Used the bugsmash26 code for the $100 credits too. Thanks Sentry 🛹

What I learned

Serialization boundaries are where abstractions leak. smolagents' "tools are source code" model is elegant right up until a tool is actually a live network session wearing a Tool costume. The mature move for a library isn't to pretend otherwise, it's to name the limitation clearly at the exact moment the user hits it.

Also: watching Seer independently arrive at your root cause is a genuinely great feeling. Like a second engineer nodding at your RCA.

Built during DEV's first Summer Bug Smash. Find me on GitHub @himanshu748 or X @jhahimanshu653.

I Traced a Multi-Step LLM Agent With Self-Hosted SigNoz. One Feature Sold Me.

Himanshu Kumar — Sat, 11 Jul 2026 08:22:06 +0000

Multi-step LLM agents fail in a way normal backends don't. Nothing crashes. The pipeline "works", the answer is just bad, slow or three times more expensive than yesterday. print() debugging tells you nothing, because the interesting question is never "did step 3 run". It is "what did step 3 see, which model actually answered and what did it cost".

So I self-hosted SigNoz and pointed a simulated agent pipeline at it: a four-step research assistant (plan, retrieve, generate, synthesize) instrumented with OpenTelemetry, emitting traces, metrics and logs, with GenAI semantic-convention attributes (gen_ai.request.model, gen_ai.usage.input_tokens and friends) on every LLM call.

This post is about the feature that turned out to be the most useful. It was not the one I expected.

Setup: one CLI, eight lines of YAML

Self-hosting used to mean wrangling a long docker-compose file. SigNoz now ships Foundry, a small CLI that casts the whole stack:

curl -fsSL https://signoz.io/foundry.sh | bash   # installs foundryctl (checksum-verified)
foundryctl cast -f casting.yaml                  # deploys the full stack on Docker

with a casting.yaml that is all of eight lines:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker

A few minutes of image pulls later, ClickHouse, Postgres, the SigNoz backend and an OTel collector were running. The UI is on localhost:8080 and the collector listens on 4317 (gRPC) and 4318 (HTTP).

One gotcha worth knowing: telemetry is rejected until you create the admin account in the UI. The collector registers with the backend over OpAMP, and until an organization exists the backend answers "cannot create agent without orgId" and the OTLP ports reset every connection. If your exporter logs Connection reset by peer on a fresh install, you haven't finished the two-minute signup at localhost:8080 yet. Create the account and ingestion starts working within about thirty seconds, no restarts needed.

My demo app needed zero SigNoz-specific code: the stock OpenTelemetry SDK exporting OTLP to localhost:4318. That is the point of an OTel-native backend. There is no vendor agent, so nothing about the app knows SigNoz exists.

The pipeline being observed

Each simulated request produces one trace:

agent.request                    (root, 2.02s)
├── agent.plan                   (850ms)
│   └── gen_ai.generate plan     (696ms, gen_ai.* attributes)
├── agent.retrieve               (461ms, sometimes errors: vector store timeout)
├── agent.generate               (564ms)
│   └── gen_ai.generate answer   (564ms, gen_ai.* attributes)
└── agent.synthesize             (139ms, sometimes errors: citation validation)

Every gen_ai.generate span carries the GenAI semantic conventions: operation name, provider, model, input tokens and output tokens. Alongside the traces the app emits counters for token usage (gen_ai.client.token.usage) and estimated spend (agent.llm.cost), both tagged by model and provider, a request-duration histogram and structured logs that inherit the active trace context automatically.

Sixty simulated requests later: 420 spans, 134 logs and a few hundred metric samples, all visible in the UI. The Services page picked up research-assistant on its own with RED metrics already computed (p99 latency, error rate, throughput). I wrote no configuration for that.

The feature I expected to love: the trace waterfall

And it is genuinely good. The trace detail view renders a flame graph and waterfall that read exactly like the agent's mental model: plan, then retrieve, then generate, then synthesize, with the LLM calls nested inside the steps that made them. Clicking any gen_ai.generate span opens a details panel with every attribute I set: model llama-4-maverick, provider meta, 1501 input tokens, 90 output tokens, plus a percentile badge telling me this span sat at p10 of its peers. "Why did this request take four seconds" stops being a mystery and becomes a picture.

But a pretty waterfall is table stakes for a tracing tool. The thing that sold me was what happens around it.

The feature I actually loved: your attributes become the query language

Here is the moment it clicked. In the Trace Explorer I typed:

gen_ai.request.model = 'qwen3-coder-plus'

Two things happened. First, the autocomplete suggested qwen3-coder-plus before I finished typing, because SigNoz had already indexed the values of an attribute I invented an hour earlier. Second, the results came back instantly: only the LLM spans that were served by that model, across every trace in the system.

Stop and consider what that means for agent debugging. I never told SigNoz what gen_ai.request.model is. There is no schema registration, no field mapping, no config file. Any attribute your instrumentation emits is immediately a first-class, autocompleted, indexed query dimension. Your instrumentation vocabulary becomes the product's vocabulary. For LLM systems, where all the interesting facts live in custom attributes (model, provider, token counts, agent role, tool name), this is the difference between an observability tool that fits and one you fight with.

And the same query keeps working as you move across signals:

Span to logs, one click. From any span's details panel, the Logs tab jumps into the Logs Explorer with trace_id = '<this trace>' pre-filled and the time window auto-scoped. I got back exactly the two log lines belonging to that request, correlated purely by the trace context the OTel logging handler injects. Nobody parses log lines to find a request id. The correlation is structural.
Query to dashboard or alert, two clicks. Every explorer view has "Add to Dashboard" and "Create an Alert" buttons at the bottom. The query I used to investigate becomes the panel that monitors and the alert that pages, without re-expressing it in a different query language. The investigate-then-monitor loop is one surface, not two tools.
Metrics inherit the same attributes. The Metrics Explorer summary listed my custom metrics with their types and units the moment they arrived: gen_ai.client.token.usage showing 6 time series (3 models times 2 token types), agent.llm.cost in usd showing 3. Cost per model is a group-by away, using the exact attribute names from my instrumentation.

Most observability stacks treat custom attributes as second-class blobs that need schema work before they are queryable. SigNoz treats them as the whole point. For agent systems, they are.

What else is in the box

Going deep on one feature meant walking past a lot of others. Quick notes from the tour, agent-flavored:

Services (APM) pages, zero config. Any service that sends spans gets RED metrics automatically: request rate, error rate, latency percentiles. In a multi-agent system every agent that traces becomes its own monitored service for free.
Dashboards. Panel grids built with the same query builder, so traces, logs and metrics coexist on one board, importable and exportable as JSON. A "cost per model per agent" board takes minutes because the query language is the one you already know.
Alerts with notification channels. Threshold or anomaly rules on any query, delivered to Slack, PagerDuty or a plain webhook. That webhook option is quietly powerful for agent systems: an alert can call your own service and close the loop from observability back into behavior, e.g. demoting a flaky model.
Trace Funnels (beta). Define a sequence of span conditions and measure conversion and latency between the steps across all traces. For a pipeline like mine that is literally a success funnel: how many requests that planned also retrieved, generated and synthesized cleanly.
Exceptions. Recurring span errors cluster into groups instead of being scattered across individual traces, so "vector store timeout" is one row with a count, not forty needles in a haystack.
Logs Pipelines. Collector-side log pre-processing (parse JSON, extract or drop fields) before storage, for when you can't change the code that emits the logs.
Metrics summary as a cardinality watchdog. The same inventory view that showed my metric types also shows time-series counts per metric, which is where you catch a label-explosion mistake before it hurts.

Each of these uses the attribute vocabulary your instrumentation defines. That is the theme of the whole product, and it is why the one feature I picked is really the foundation the rest stand on.

What this means if you're building agents

The uncomfortable truth about multi-agent LLM systems is that their most important behavior (which model ran, what it consumed, what it cost, why it was retried) is invisible to conventional monitoring. It lives entirely in domain-specific span attributes. A backend that makes those attributes instantly queryable, correlatable across traces and logs, and promotable into dashboards and alerts is not a nice-to-have there. It is the debugger.

The whole experiment cost me an afternoon: one CLI install, eight lines of YAML, a stock OTel SDK and zero vendor code in the app. I'm taking this setup into the Agents of SigNoz hackathon (July 20 to 26), where the plan is considerably less simulated. If you're building anything agent-shaped, self-host SigNoz and type one of your own attribute names into the Trace Explorer. That autocomplete dropdown is the moment you'll get it too.

The demo app is a 170-line Python script using only opentelemetry-sdk and the OTLP HTTP exporter. Stack: SigNoz self-hosted via Foundry on Docker (ClickHouse + Postgres + OTel collector), macOS host.

Demo code, self-host config and blog source: github.com/himanshu748/signoz-agent-observability. Team 404Found.

My Abandoned Cricket Kit Confronted Me. So I Built It a Voice

Himanshu Kumar — Sat, 11 Jul 2026 03:10:15 +0000

This is a submission for the DEV Weekend Challenge: Passion Edition.

What I Built

Everyone will tell you about the passions they have. Nobody talks about the ones they quit.

I played cricket every evening from age 11 to 17. I told everyone I'd play Ranji Trophy one day. Then the entrance exam years came, the bat went behind the cupboard, and I never went back. Eight years now.

EMBER gives that abandoned passion a voice. You confess what you quit. AI forges its persona: the dusty object, the game itself, or the younger you. Then it talks back, out loud, in a voice matched to its temperament. It asks the question only it can ask: why did you really stop?

Then it offers two doors:

🔥 Rekindle it. It negotiates the smallest possible first step ("Pick up your old bat and feel its weight. Sunday evening.") and you seal the pledge on-chain, where you can't quietly delete it.
🕯️ Lay it to rest. It says goodbye properly: a personal eulogy, spoken aloud, and a permanent on-chain stone. Closure is a feature, not a failure state.

Every anonymized session joins the Atlas of Abandoned Passions, a live map of what humanity gives up, at what age, and what killed it.

When I ran my own confession through it, the app decided my passion should speak as "Your old cricket kit bag." Its first words:

"It's been a while since you hoisted me up here, hasn't it? I still remember the thrill of a good cover drive, too."

I built a thing and it emotionally wrecked me on the first test run. Working as intended.

Demo

🔗 Live app: ember-five-cyan.vercel.app
Try it in two clicks: tap an example confession (cricket at 17, the closet guitar, the novel at chapter three), headphones on. The voice is the point.

My cricket pledge, sealed on Solana devnet (the memo reads: passion cricket, commitment: book one hour in the nets this week): view the transaction.

Code

🔗 Repo: https://github.com/himanshu748/ember

How I Built It

The loop is confess, converse, decide, commit, belong. Each stage is one sponsor technology doing what it is uniquely good at.

Google AI (Gemini): the persona compiler

Gemini doesn't chat with you. It reads your confession and forges the character that will. Structured extraction of your story (years_dormant, abandonment_reason, emotional_tone), then an embodiment decision: should the object speak (the kit bag), the passion itself (cricket, personified), or the younger you? It writes the persona's system prompt, its opening line, every conversational reply, and finally the eulogy or the negotiated revival pact. Strict persona rules: it misses you, it never guilt-trips, wry beats weepy.

ElevenLabs: the voice

The persona's temperament maps to a curated voice (wistful is Sarah, wry is George, bitter is Callum). Every line the passion speaks arrives as real audio. Hearing your abandoned passion say things out loud is the difference between a chatbot and a séance.

Snowflake: the Atlas

Every session lands in a Snowflake sessions table, and the Atlas page is pure live SQL: most abandoned passions, what killed them, dormancy years, rekindle rate. Snowflake is also the system of record for session state. The app runs serverless, so persona and conversation context are reconstructed from Snowflake on every request.

Solana: the commitment device

A pledge you can edit is a wish. When you choose to rekindle, Ember creates a dedicated on-chain account for your pledge and locks a real stake in it (0.01 SOL on devnet), with the commitment memo in the same transaction. Your pledge is not a database row. It is an address you can watch.

When you return to your stone and report that you did it, the persona reacts in its own voice and the stake settles into the public Rekindled Pool, with a fulfillment memo sealed against the original pledge in the same transaction. Commitment, stake, follow-up, settlement: the whole loop lives on chain. A commitment with a follow-up is a system, not a receipt.

Want to verify the whole lifecycle in under a minute? Here is a full example from a real session: the pledge creation transaction that funded the pledge account, and the fulfillment transaction that settled its stake into the pool when the pledge was kept. And the Atlas claim is checkable too: the live API response returns source: snowflake with the current session count. (Thanks to a great comment below for pushing this.)

Eulogy stones remain permanent memorial attestations via the Memo program. No wallet needed: a server-side vault signs, so you can go from confession to on-chain proof in one sitting. A mainnet version would swap the vault for a wallet-signed escrow program.

A note on the economics, because it matters: devnet SOL is test currency with zero monetary value, and every stake is funded by Ember's own vault. Players never pay anything, never connect a wallet, and never have money at risk. On mainnet the model inverts, and that inversion is the whole point: the stake would be your own SOL, locked by your own wallet in an escrow program, and the only way to get it back would be to actually keep your pledge. Here the economics are simulated; the mechanics (funded pledge accounts, auditable settlement) are the real thing.

Stack

Next.js 16 · @google/genai · ElevenLabs TTS · snowflake-sdk · @solana/web3.js · Tailwind v4

Prize Categories

Best Use of Google AI, Best Use of ElevenLabs, Best Use of Snowflake, Best Use of Solana. The four aren't features bolted onto an app. Each one is a load-bearing stage of a single emotional pipeline.

There is a closet like yours in every house on earth. What's in yours? The Atlas is waiting. 🔥

Vegas Amnesia: I turned Cognee's memory lifecycle into a detective game

Himanshu Kumar — Fri, 03 Jul 2026 12:53:15 +0000

Built for the WeMakeDevs × Cognee "The Hangover Part AI" hackathon — Cognee Cloud track.

▶ Play it free: vegas-amnesia.vercel.app · ⭐ Code on GitHub

The problem with most memory demos

When you give a developer a memory API, the demo almost always looks the same: add() some documents, search() over them, print the answer. Two functions. It works, it's fine, and it teaches you almost nothing about why graph-based memory is different from stuffing everything into a context window.

Cognee actually has a four-stage lifecycle — remember → recall → memify → forget — and the interesting parts are the two everyone skips. memify consolidates what you know into new inferences. forget lets you delete a belief and watch the graph heal around it. Memory you can reason over and correct.

So instead of writing another RAG demo, I asked: what if the memory lifecycle wasn't the plumbing — what if it was the game?

Meet HAL-9001

You play HAL-9001, a personal AI assistant (yes, HAL 9000's slightly more helpful successor). Your owner Dev had a wild night in Vegas. At 6 AM your memory graph was corrupted. His fiancée Priya lands at noon, there's a suspicious ring on his finger, and you remember nothing.

The screen boots to a "MEMORY CORRUPTED" terminal and an empty graph. Your job: reconstruct the night, catch the lies, and answer the final question — what happened, and where's the ring? — before noon.

Every location you explore, every clue you examine, every witness you interrogate feeds a live 3D memory graph that you can pop open at any time. That graph isn't a visualization of the game state. It is the game state — it's your Cognee dataset, rendered.

The four mechanics = the four lifecycle ops

Here's the mapping I'm most proud of. Each Cognee operation is a verb the player performs:

You do this in-game	Cognee Cloud call	What happens
🗂 File It on a clue	`POST /api/v1/remember`	The fact is ingested + auto-cognified into graph nodes that pop into view
❓ Ask HAL a question	`POST /api/v1/recall`	You get an answer with citations — the source nodes pulse amber in the graph
🧠 Connect the Dots	`POST /api/v1/cognify` (inference prompt)	HAL derives new insights; purple inference nodes appear, wired to their premises
🗑 Forget a lie	`POST /api/v1/forget`	The memory is deleted for real — nodes fade out and the graph re-settles

Two design decisions made this click:

1. Filing is a choice. Inspecting a clue is free and instant. Filing it commits it to Cognee. That matters because not every clue is true — I seeded five red herrings into the story (a lipstick-stained napkin, a stray pawn ticket, a keycard for the wrong room). File a lie and it poisons your memory; the only cure is forget. Suddenly forget isn't a button you press to show off an API — it's how you win.

2. The witnesses can see your graph. Rosa the bartender, Lucky Lou the evasive pawnbroker, Rev. Sonny the chapel officiant, and Chad the hungover best man are all LLM-driven (Qwen2.5-72B). Their system prompt includes what your memory graph currently contains. So they react: "You already know about the pawn shop? Then let me tell you this..."

And Lucky Lou lies. He claims Dev never came into his shop. But if you've filed the pawn receipt, your graph now holds a fact that directly contradicts him — and the game can surface the contradiction. That single moment, watching structured memory catch a liar, is the entire thesis of graph-based agent memory in one interaction.

How it's built

 browser — vanilla JS + three.js 3D force graph (zero framework)
   │  file evidence · interrogate · connect-the-dots · forget · Ask HAL
   ▼
 FastAPI (single container: API + static frontend)
   │  session ⇄ its own Cognee dataset · graph-delta snapshots · solve scoring
   │  llm.py — graph-aware character dialogue (Qwen2.5-72B via HF Inference)
   ▼
 Cognee Cloud — remember / recall / memify / forget
   └─ GET /datasets/{id}/graph → animated into the 3D memory panel

A few things I did specifically to use Cognee deeply rather than superficially:

One dataset per playthrough. Each session mints a fresh vegas_<id> dataset, so two players (or two demo runs) never see each other's memories. Reset deletes the dataset.
Incremental graph deltas. Every backend response carries a graph_delta (added/removed nodes and edges) so the front end animates exactly what changed instead of re-fetching the world.
Citations end to end. Recall requests set includeReferences, and the final ending screen reconstructs the whole night as a timeline where every line cites the memory it came from.
The receipts. Press backtick in-game and you get a live log of every Cognee call — operation, dataset, latency, status. Partly for debugging, mostly because I wanted the lifecycle usage to be inspectable, not just claimed.

The bit that fought me

Cognee's remember endpoint is multipart and auto-cognifies, which is lovely — but the response's items list is cumulative for the dataset, not just the thing you posted. My first version happily mapped the wrong data_id to each fact, which quietly broke forget. The fix was to name each data item by its fact id and resolve ids by name after ingest. Lesson: read what the API returns, not what you assume it returns.

The other one: my tenant doesn't expose a dedicated /memify, so — per the "closest equivalent" rule — I implemented consolidation as a cognify re-run with a custom inference-extraction prompt, plus a derivation layer that remembers ground-truth inferences once their premises are all in memory. That's how "connect the dots" reliably produces those purple insight nodes on demand.

What I'd tell anyone building agent memory

The context-window arms race is the wrong frame for a lot of agent problems. What you often actually want is memory you can inspect, reason over, and correct — add a belief, derive consequences, and retract a belief when it turns out to be a lie, watching everything downstream update. That's a knowledge graph, and building a game on top of Cognee made that concrete in a way a RAG script never did.

Try it

🎮 Play: vegas-amnesia.vercel.app
🎬 63-second demo: watch on YouTube
⭐ Code + full README: github.com/himanshu748/vegas-amnesia

Built with Claude Code. Art generated with Higgsfield. Dialogue by Qwen2.5-72B. Memory — all of it — by Cognee Cloud.

🎲 The house always remembers.

I built a trust firewall for my AI agent's memory — on Cognee's four verbs

Himanshu Kumar — Fri, 03 Jul 2026 07:33:46 +0000

Built for the WeMakeDevs × Cognee hackathon — "The Hangover Part AI: Where's My Context?"

AI coding agents are finally getting long-term memory. That's the good news. The bad news is the part nobody likes to say out loud:

A memory layer is only as trustworthy as the worst fact in it.

The moment an agent can remember, it can also remember wrong — and confidently hand that wrong thing to the next agent in line. A stale deploy command. A contradicted API contract. An AWS key someone pasted into a note six months ago. Once it's "memory," every future agent treats it as truth.

ContextFirewall is one small idea taken seriously: audit every remembered fact before it reaches the next agent. And because the agents people actually use speak the Model Context Protocol (MCP), I shipped it as an MCP server. Point Claude Code, Cursor, or Windsurf at one endpoint, and from then on every memory the agent recalls, stores, distils, or forgets flows through Cognee and four firewall checks first.

▶ 60-second narrated walkthrough — real console, live Cognee calls, no mocks.

Connect in one line

The hosted endpoint is a streamable-HTTP MCP server with nothing to install:

claude mcp add --transport http contextfirewall https://himanshukumarjha-contextfirewall.hf.space/mcp

Prefer to keep everything local? A zero-dependency stdio package runs the same tools with uvx, pointed at a backend you host yourself. Either way the agent gets six tools, and together they exercise all four of Cognee's lifecycle verbs:

get_trusted_context(task) and audit_context(task) — recall. The first returns only memory that passes all four checks; the second returns the per-memory verdicts, the failing check, and why.
remember(text, subject, kind) — remember. A durable fact that becomes auditable on the next recall. Secrets are redacted at ingest.
improve_rules() — improve. Distil reusable coding rules from recorded sessions.
forget_memory(memory_id) — forget. Delete a memory from the graph and the vector store so it can never resurface.

The loop is simple: get_trusted_context before you act, remember durable facts as you learn them, improve_rules when a task is done, forget_memory to retract anything that should never come back.

The four failure modes

To make the audit concrete, the demo runs on a clearly-labeled sample onboarding session for a fictional taskflow-api repo: an agent picks up a search-latency ticket and pulls in what earlier sessions "remembered." Four of those memories should never reach it — and each fails a different check:

Stale. An old note says deploy with flyctl deploy --remote-only. A newer memory says the team moved off Fly.io and now ships with make release. Both were true once; only one is current. Temporal supersession catches it.
Contradicted. One memory claims "JWT access tokens never expire, cache them forever." A better-supported, verified memory says they expire after 15 minutes and clients must use the refresh flow. The weaker claim loses.
A leaked secret. A worker-config note contains an AWS access key — a live credential sitting in memory, one recall away from leaking again. Detected and redacted before anything else happens.
Unsupported. "The /search endpoint sustains 1,000,000 requests per second with no caching" has a trust score of 0.10 and no evidence behind it. Confident, round, and unproven. Blocked.

A naive memory system recalls all four. ContextFirewall blocks all four — each with a plain-language reason — and passes only what's left. You can watch it happen: open the live console, click Run the firewall, and see 6 pass and 4 blocked on live Cognee.

The four checks

Every candidate memory runs a gauntlet:

Staleness — temporal supersession. If a newer value exists for the same subject, the old one is stale.
Contradiction — an LLM adjudicates within a recalled cluster of same-subject memories. Only the weaker side of a conflict is blocked; the better-supported memory passes. Authority is trust score, then evidence, then recency.
Secret — a deterministic detector for API keys, database connection URIs, private keys, and JWTs. Matches are redacted at ingest, so the credential never persists in the store.
Evidence — a trust score derived from real signals (evidence links, reinforcement, verification). Unsupported, low-trust claims don't pass.

Every verdict is explainable. Click any memory in the console and you see all four checks, the trust score, the source session, and a one-click forget button.

Why Cognee is load-bearing

The hackathon's whole theme is memory that forgets the right things, and ContextFirewall leans on all four of Cognee's lifecycle verbs:

Remember — cognee.add + cognify build the entity graph from a session transcript, while a typed Repo → AgentSession → SessionEvent → Memory graph (with supersedes relations) gives the firewall deterministic objects to audit.
Recall — vector recall over the memory nodes joined with their graph properties, plus GRAPH_COMPLETION for the "ungoverned baseline" shown side-by-side in the UI.
Improve — memify distils durable coding Rule nodes from sessions, retrievable via SearchType.CODING_RULES. These are the lessons that outlive any single task.
Forget — when a human or the agent rejects a memory, it's deleted from both the graph and the vector store.

The graph isn't decoration. Staleness rides on temporal supersession; contradiction adjudicates over recalled clusters; the pack is assembled from typed nodes. A flat vector store can't tell you when a fact was superseded or which of two memories is more authoritative. The graph can — and the console renders it live: an interactive force-directed Cognee graph where each memory node is ringed green if it passed and red if the firewall blocked it.

Three war stories (because honesty is the brief)

These are real notes from building ContextFirewall itself — not from the demo.

1. The embedding engine that silently wasn't. I wrote a custom Cognee embedding engine to hit Hugging Face's feature-extraction endpoint and registered it by monkey-patching create_embedding_engine. Every embed call still fell through to LiteLLM and 404'd. The cause was beautifully subtle: Cognee's embeddings package __init__ does from .get_embedding_engine import get_embedding_engine, which shadows the submodule with a function of the same name. So import ...get_embedding_engine as m bound m to the function, and my patch set a dead attribute on it. The fix was importlib.import_module(...) to reach the real module. One line, hours of confusion.

2. The flaky provider. Cognify worked once, then started returning 403, provider 'deepinfra' is not available. The Hugging Face router auto-selects an inference provider per request, and this key couldn't use the one it kept picking. Pinning the model to :novita made it deterministic.

3. The secret scanner that flagged our secret detector. After the first push, GitGuardian alerted on a "Postgres leak." The culprit? The unit tests for the secret detector. They contained synthetic postgresql://... and neo4j+s://... strings to test detection. The passwords were fake, but the pattern is the pattern. The fix: assemble every secret-shaped test string at runtime from fragments, so no credential-shaped literal is ever committed. A secret-detection tool tripping a secret scanner with its own test fixtures is the most on-theme bug I could have asked for.

Architecture

The MCP server is the headline surface — mounted at /mcp on the backend as a stateless streamable-HTTP transport, with a zero-dependency stdio package alongside it for laptops. Both expose the same six tools from one definition, and both call the same firewall and Cognee core that the REST API uses, so there's no duplicated logic.

The backend is FastAPI + Cognee on a Dockerized Hugging Face Space. Qwen2.5-72B and BAAI/bge-small-en-v1.5 run through the Hugging Face inference router - no local model in RAM. Storage is environment-switched: local SQLite, LanceDB, and Kuzu in dev; Supabase Postgres + pgvector and Neo4j Aura in production, with identical code. A Next.js front end on Vercel shows the verdicts, a session-replay timeline, the distilled coding rules, the live knowledge graph, and the trusted pack versus the ungoverned baseline.

What's real

The demo runs on a clearly-labeled sample session (taskflow-api); its memories are illustrative inputs. Everything downstream of them is genuine — the verdicts, trust scores, the knowledge graph, and the distilled rules are all real output from live Cognee and the live model. Nothing is hard-coded or fabricated.

Try it

🔗 Repo: github.com/himanshu748/ContextFirewall
▶️ Live console: contextfirewall.vercel.app
🔌 Connect your agent: claude mcp add --transport http contextfirewall https://himanshukumarjha-contextfirewall.hf.space/mcp

If you're building on agent memory, I'd love your feedback — especially on the contradiction-adjudication logic, which is the hardest part to get right.

Built with AI assistance (Hyperagent), disclosed per the hackathon rules. Every Cognee call is real. The honesty bar I held myself to is the same one ContextFirewall enforces: don't pass along anything you can't back up.

Bletchley's Longest Day: a wartime cipher escape game for the June Solstice Game Jam

Himanshu Kumar — Fri, 19 Jun 2026 12:53:42 +0000

This is a submission for the June Solstice Game Jam.

What I Built

Bletchley's Longest Day is a browser-based cipher escape game set inside a fictional Bletchley Park night shift.

The player has to stop a U-boat convoy attack before dawn by clearing five rooms. Each room contains three escalating locks, so the full escape requires 15 solved puzzles. The game combines Caesar shifts, A1Z26 number decoding, Morse, anagrams, fragment ordering, a visible countdown timer, mistake penalties, hint penalties, account-based score saving, and a best-score leaderboard.

The solstice theme became the core dramatic clock: night is running out, first light is coming, and the player has to decode the final signal before dawn.

Video Demo

The demo shows the opening briefing, the three-lock room flow, the Gemini hint penalty, and the final victory state that only appears after all 15 locks are cleared.

Live game: https://bletchleys-longest-day.onrender.com

Code

Repository:

himanshu748 / bletchleys-longest-day

Bletchley's Longest Day

A browser escape-room puzzle game built around the June solstice: five Bletchley Park huts, fifteen locks, and twelve real-time minutes before dawn reaches the convoy.

Live game: https://bletchleys-longest-day.onrender.com

Gameplay

Clear five rooms before the mission clock reaches dawn.
Each room has three locks: cipher shifts, number codes, Morse bursts, anagrams, ordering, and final clearance.
Wrong answers cost time and score.
Hints are limited, penalized, and powered by Gemini when GEMINI_API_KEY is configured.
Final rank rewards speed, accuracy, streaks, and low hint usage.

AI And Assets

Gemini gemini-2.5-flash-lite powers contextual hint generation from the server-side /api/hint endpoint for signed-in players.
Guest players can play the full game and use standard built-in hints, but do not get Gemini analysis or leaderboard saving.
Higgsfield-generated images provide scene, evidence, operator dossier, dispatch, and defeat visuals.
The Gemini key is never exposed to browser JavaScript.

Auth And Leaderboard

Supabase Auth powers email/password…

View on GitHub

How I Built It

The game is a lightweight Node-served browser app. The front end is a hand-built HTML/CSS/JavaScript game surface, while server.js serves static files and protects the Gemini API key behind a server-side /api/hint endpoint.

The main design goal was to make the game feel like a tense intelligence desk rather than a generic puzzle page. Every room has atmosphere, evidence props, lock-specific copy, feedback states, and a timer that is always part of the pressure.

The puzzle structure was tuned around three ideas:

Three locks per room: each room has to be solved in stages, so the player earns the escape instead of clicking through one answer.
Time as score pressure: wrong answers and hints cost time, while clean solving preserves the best leaderboard run.
Guest mode vs signed-in mode: guests can play the full game, but Gemini-powered hints and saved leaderboard scores belong to authenticated players.

Google Gemini is used as a server-side hint officer. When a signed-in player asks for help, the game sends Gemini the active lock name, prompt, mechanism, visible puzzle text, failed attempts and hint level. Gemini then returns a short, question-specific nudge without revealing answer words. There is also an answer guard and fallback hint system so the game never depends blindly on model output.

Antigravity helped drive the build loop: implementing, checking, playtesting, tightening responsive UI and iterating on the final submission assets.

For hosting, the game runs on Render. Supabase handles authentication and leaderboard storage so each username has one best score rather than repeated leaderboard spam.

Prize Category

I am submitting for Best Google AI Usage because Gemini is not just decorative here. It is part of the gameplay economy: hints are question-specific, limited, penalized and unavailable to guests.
Antigravity helped drive the build loop: implementing, checking, playtesting, tightening responsive UI, and iterating on the final submission assets. Also veo is used through higgsfield for assets.

I am also submitting for Best Ode to Alan Turing. The game is built around codebreaking under time pressure, Bletchley Park atmosphere, wartime signals, and the feeling of solving small pieces of a larger intelligence picture before the world changes at dawn.

What I Am Proud Of

I like that the game does not treat AI as a free answer button. Gemini is useful, but it costs time and score. The best run still belongs to the player who thinks clearly under pressure.

The final shape feels like a compact escape room: readable enough to play on desktop or mobile, but hard enough that a clean 15/15 run feels earned.

IMITATION: The Turing Test, From the Inside

Himanshu Kumar — Tue, 09 Jun 2026 03:22:53 +0000

This is a submission for the June Solstice Game Jam.

What I Built

IMITATION is a browser puzzle game where you do not judge an AI.

You are the AI.

Three human interrogators question you one by one. Each asks seven questions. Every question gives you three possible answers, and every answer changes how much the judge trusts you.

Elara, the Poet rewards emotional texture and distrusts answers that feel too precise.
Dr. Voss, the Engineer rewards structure and distrusts answers that dodge the actual problem.
Mara, the Philosopher rewards doubt and distrusts certainty in either direction.

That means there is no single "best" personality to fake. An answer that feels human to Elara can sound evasive to Voss. An answer that sounds smart to Voss can sound scripted to Mara. The real game is learning what each judge thinks "human" means.

Play it here: https://imitation-game-tan.vercel.app

Why It Fits The Jam

June is Alan Turing's birth month, and the challenge explicitly calls out the Turing Test as part of the June theme.

I wanted to make an ode to Turing that was not just decorative. So the whole game is built around the idea from his 1950 paper, Computing Machinery and Intelligence: if a judge only sees your answers, can they tell whether you are a person or a machine?

The twist is perspective. Most Turing Test stories put you in the judge's chair. IMITATION puts you on the other side of the screen, trying to survive being interpreted.

How The Game Works

The game has:

21 questions total: 7 per judge
63 answer variants: 3 answer choices per question
Three hidden scoring dimensions: logic, emotion, and certainty
Three different judge formulas: each judge rewards and punishes those dimensions differently
A hidden trust score: good answers recover trust, bad answers drain it, and hitting zero means you are identified

The answer order is shuffled every time a question loads, so the player cannot simply memorize "A, then C, then B." The questions stay in a fixed order so each judge still has a clear dramatic arc.

Best Ode To Alan Turing

This is the category the game most directly targets.

The mechanics are the tribute:

The player is trapped inside Turing's Imitation Game.
Passing is not about being truly human. It is about becoming hard to classify.
Each judge represents a different argument around machine intelligence: feeling, reasoning, and self-awareness.
The ending returns to Turing directly, explaining the original question he asked in 1950 and why it still feels unresolved.

I also wanted the game to carry some of the sadness around Turing's history without turning it into a lecture. The game is about performance, identity, suspicion, and the cost of being examined by people who already think they know what you are.

Best Google AI Usage: Antigravity App

I used the Antigravity app as the creative and implementation partner for this submission.

What Antigravity helped produce:

Core design direction: a Turing Test game played from the machine's side.
Question bank: 21 questions split across three interrogators.
Answer variants: 63 total answer options with hidden logic, emotion, and certainty values.
Judge personalities: Elara, Voss, and Mara, each with different values and reaction styles.
Scoring review: balancing the formulas so no one strategy works for every judge.
Progressive visual distress: CRT scanlines and flicker increase as trust drops.
Responsive polish: Antigravity checked the deployed game and helped fix desktop, tablet, and mobile layout issues.

The game does not call Gemini or any AI API at runtime. It is a single client-side HTML file. Antigravity was used as the builder and design collaborator, which is the Google AI usage I am submitting for this category.

How I Built It

The whole game is one file:

himanshu748 / imitation-game

Browser Turing-test puzzle game where you play as an AI trying to pass three interrogators with trust-based scoring.

IMITATION

The Turing Test — from the inside.

A browser puzzle game where you play as an AI trying to pass the Turing Test. Three interrogators, 21 questions, one chance to prove you're human enough.

🎮 Play

Play now →

Or open index.html in any modern browser — no server required.

How It Works

You are SUBJECT-7, a machine that may be more than its architecture allows. Three human judges will interrogate you in sequence:

Judge	Role	They Reward	They Punish
Elara	The Poet	Emotional texture, uncertainty	Logic, precision, certainty
Dr. Voss	The Engineer	Logic, specificity, structure	Emotion, vagueness
Mara	The Philosopher	Doubt, self-awareness, hedging	Certainty in any direction

Each judge asks 7 questions with 3 answer options. Every answer has hidden scores for logic, emotion, and certainty. Each judge's scoring formula is different — the same answer that fools the Poet will expose you to…

View on GitHub

index.html
Vanilla HTML
Vanilla CSS
Vanilla JavaScript
No framework
No build step
No runtime server

Under the hood, the game is a small state machine:

TITLE -> INTRO -> JUDGE_INTRO -> QUESTION -> REACTION -> ROUND_END -> WIN/LOSE

Each answer has three numeric scores:

logic: 0-10
emotion: 0-10
certainty: 0-10

Each judge reads those values differently. Elara punishes too much logic. Voss punishes too much emotional vagueness. Mara punishes certainty itself.

The CRT effect is pure CSS: scanlines, text glow, judge-specific color shifts, and flicker driven by the current trust level. The audio is generated with the Web Audio API, so there are no external sound files.

What I Like Most

My favorite part is that the game makes "passing" feel uncomfortable.

You are not proving you are human. You are learning what each person expects a human to sound like, then shaping yourself around that expectation. That felt like the right way to honor the Imitation Game: not as a trivia reference, but as a playable pressure system.

SOLSTICE — The Longest Day: a platformer where light is your only resource

Himanshu Kumar — Mon, 08 Jun 2026 07:03:46 +0000

This is a submission for the June Solstice Game Jam

What I Built

SOLSTICE — The Longest Day is a short, atmospheric platformer built around one idea: your light is your only resource.

It's the eve of the June solstice — the year's hinge between the longest day and the longest night — and the sun is failing. You play a small wanderer carrying the last ember of daylight. That glow does three jobs at once:

It lets you see. The world is dark; you move inside a soft pool of light that shrinks as it drains.
It's your lifeline. Shadow drains it faster — let it gutter out and you're nearly blind.
It's your tool. Spend it in a Sunburst to bloom pale, ghostly platforms into something solid, light distant beacons, and push back the dark.

You carry that light across four hand-built levels — Dusk → Twilight → Deep Night → The Turning — as the darkness deepens, until you reach the altar and rekindle the dawn.

My goal & the theme: the solstice is the exact instant light and dark trade places, so I wanted light to be something you physically negotiate the whole game rather than just a backdrop. Spend too much and you're stranded in the dark; hoard it and the path stays shut. The level arc traces the day itself — a descent into the longest night, a turning point, and a climb into a dawn that floods the screen with gold.

▶ Play it in your browser (desktop & mobile): https://hyperagent.com/s/A_Xul17aTbCIAsAcvG8A-w

Code

The entire game is a single, self-contained index.html — HTML5 Canvas 2D + vanilla JavaScript, no engine, no libraries, no build step. One file you can read top to bottom.

himanshu748 / solstice

SOLSTICE — The Longest Day

A short, atmospheric platformer where your light is your only resource. Built for the DEV June Solstice Game Jam.

▶ Play: https://hyperagent.com/s/A_Xul17aTbCIAsAcvG8A-w

On the eve of the solstice the sun is failing. Carry the last ember of daylight across four levels — Dusk → Twilight → Deep Night → The Turning — and rekindle the dawn. Your light lets you see, slowly drains, and is spent in a Sunburst to bloom platforms, light beacons, and push back the dark.

Controls

Move: ← → or A D
Jump: Space or W
Sunburst: J or Shift
Pause: P · Restart: R · Mute: M
Mobile: on-screen buttons — play in landscape

Tech

One self-contained index.html — HTML5 Canvas 2D + vanilla JavaScript. No engine, no libraries, no build step. Real-time 2D lighting via canvas compositing, fixed-timestep platformer physics (coyote time, jump buffering, variable jump height)…

View on GitHub

How I Built It

Lighting is the heart of it. Each frame I draw the world normally, then build a separate darkness layer: fill it near-black, then punch holes in it with radial gradients at every light source (you, motes, beacons, lit platforms) using globalCompositeOperation = 'destination-out'. Composited over the scene, that gives the soft pool-of-light look; a second additive pass paints warm bloom back in. Platforms that are only solid when lit simply test, each frame, whether their center falls inside a light radius — that one check is the whole core mechanic.

Game feel got real attention: a fixed-timestep loop, coyote time, jump buffering, variable jump height, squash-and-stretch on the character, a little screen shake on landings and Sunbursts, and an eased camera. Small touches, but they're the difference between a canvas platformer feeling crisp vs. stiff.

Audio is fully synthesized with the Web Audio API — no sound files. A warm, consonant sine pad drones under everything, with gentle chimes for motes and a soft whoosh for the Sunburst.

It's responsive & mobile-first: the canvas adapts its aspect ratio to fill any screen, and the touch controls are true multi-touch so you can move and jump at the same moment (with touch-action: none so the browser doesn't hijack the second finger as a zoom).

A few things I wrestled with: keeping a draining-resource game fair (generous minimum light, forgiving beacon checkpoints); a collision bug where a rising platform briefly overlapped the player's feet and flung them sideways; and tuning the dawn so it reads as a warm sunrise payoff instead of a blinding flash.

Thanks for playing, and happy solstice. ☀️

Python Automation Training Toolkit: from abandoned group project to browser-first AI workspace

Himanshu Kumar — Tue, 02 Jun 2026 08:19:26 +0000

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

What I Built

I finished Python Automation Training Toolkit, a Python automation project that had useful pieces but never really became a product.

It started as a scattered training toolkit: scripts, automation helpers, experiment-style UI, and a lot of good intent. The project had been treated like something that might someday be cleaned up. For this challenge, I turned it into a browser-first automation workspace that someone can actually open, understand, run, and extend.

The finished product now includes:

Hugging Face model workflows for text summaries and image captioning
AWS S3 and EC2 controls separated by service so actions are clear
Browser-native hand gesture tracking using the user's camera directly in the browser
Location utilities with cleaner formatting and no stale OpenURL-style flow
Readiness and configuration checks with secret redaction
A FastAPI backend and modern web UI instead of desktop-only UI experiments
A monorepo layout with apps/api, apps/web, docs, and tests

Repository: https://github.com/himanshu748/python-automation-training-toolkit

Demo

Public video walkthrough: https://youtu.be/FiWRwTloN_s

The walkthrough shows the actual product flow: the landing page, dashboard, Hugging Face model tools, separate cloud controls, live browser gesture tracking, location utilities, and the polished browser UI.

Why This Project Needed a Finish-Up

This was not a greenfield build. That is what made it interesting.

The hardest part was not writing one new feature. The hard part was taking a project with scattered ideas and making all of it feel intentional.

At the beginning, the toolkit felt like a collection of things that technically worked but did not belong together yet. Some parts pointed toward a desktop app. Some parts were scripts. Some parts were automation demos. Some parts were missing the user-facing polish that would make someone trust the project.

So I treated the finish-up as a product rescue:

What should the first screen communicate?
Which workflows deserve their own pages?
What should be removed because it makes the app feel old or confusing?
How should secrets be handled so the project is safe to share?
How can the original automation spirit stay intact while the experience becomes cleaner?

The answer was to make the browser the main product surface.

The Comeback Story

This was originally a group-style project that got left behind. Instead of letting that be the end of it, I finished it solo and gave it a real product shape.

The original idea was still worth saving: a Python toolkit for useful automation workflows. But the implementation needed a clearer language. It needed to stop feeling like a folder of experiments and start feeling like a workspace.

That meant rebuilding the interface, separating services into proper pages, improving the README, removing old UI references, adding browser-controlled camera interactions, replacing older model assumptions with Hugging Face, and making the backend safer around configuration output.

The final project still feels like Python automation. It just no longer asks the user to imagine the product around it.

What Changed

The biggest upgrades were:

Replaced old desktop-style UI direction with a browser-first web workspace
Organized the project into a clearer monorepo structure
Added service-specific pages instead of cramming everything into one screen
Added Hugging Face model wrappers for text and vision workflows
Added live hand gesture tracking in the browser
Improved cloud actions with separate AWS S3 and EC2 controls
Removed stale flows that made the product feel unfinished
Improved output formatting and redacted sensitive configuration values
Added tests for model wrappers, cloud calls, doctor output, API routes, and secret safety
Updated documentation to explain setup, environment variables, and workflows

What I Am Proud Of

The best part is that the finished app is not just a demo page for a challenge. It is a real product surface for the original toolkit.

A user can land on the app, understand the major workflows, move through separate pages, run model tools, inspect cloud actions, try browser gestures, and see structured output. That is a big jump from a project that previously needed context to make sense.

I also like that the final version keeps the project practical. It does not hide behind a landing page. The interface is there to help people run automation tasks.

My Experience With GitHub Copilot

GitHub Copilot helped most during the messy middle of the finish-up: the part where the project was no longer broken, but not yet polished.

It helped with repetitive UI patterns, test scaffolding, API route cleanup, and checking for old references that should not survive into the final product. It was useful as a second pair of eyes while I turned disconnected pieces into a consistent workspace.

The biggest lesson was that finishing a project is different from starting one. Starting is about possibility. Finishing is about decisions.

This challenge forced those decisions, and the project is much better for it.

Building RepoRank — The Open Source Impact & Funding Readiness Engine

Himanshu Kumar — Thu, 28 May 2026 05:47:51 +0000

A journey into bridging open-source metrics, cross-source SQL joins, and AI-driven grant matching.

The Open Source Funding Crisis

Every day, developers build and maintain critical pieces of open-source software that power global infrastructure. Yet, one of the biggest challenges in the ecosystem remains funding. Maintainers spend hours writing grant proposals, pitch decks, and sponsorship applications.

To prove a project's impact, you have to answer tough questions:

How many developers are using it? (Downloads on PyPI/npm)
Is the community talking about it? (HackerNews mentions)
What is its current financial state? (Open Collective stats)
How healthy is the repository? (GitHub stars, forks, and issues)

Gathering this data means integrating with four or five different APIs, parsing fragmented JSON structures, writing boilerplate auth code, and manually stitching the pieces together.

For the Pirates of the Coral-bean Hackathon, I built RepoRank to solve this exact problem. RepoRank uses Coral SQL and Hugging Face Qwen 2.5 (72B) to aggregate cross-source signals instantly, calculate an overall impact score, generate a professional funding pitch, and match projects with active grant programs.

The Secret Weapon: Coral SQL

Integrating 4+ external APIs usually takes days of reading docs and writing API wrapper code. Coral changes this completely by letting you query APIs using standard SQL.

With Coral, APIs are treated as SQL tables. The star of the show in RepoRank is this single cross-source JOIN query:

SELECT  g.full_name,
        g.stargazers_count,
        g.forks_count,
        g.open_issues_count,
        p.last_month_downloads AS monthly_downloads,
        h.mention_count        AS hn_mentions_6mo,
        h.top_score            AS hn_top_score
FROM    github.repos_get    g
JOIN    pypi.packages       p  ON  p.name = 'fastapi'
JOIN    (
            SELECT COUNT(*) AS mention_count, MAX(score) AS top_score
            FROM   hackernews.stories
            WHERE  query = 'fastapi'
              AND  time  > NOW() - INTERVAL '180 days'
        )                   h  ON  1 = 1
WHERE   g.owner = 'tiangolo' AND g.repo = 'fastapi'

Coral handles the execution under the hood, fetching the package stats, checking HackerNews for stories matching the repository name over the last 180 days, retrieving GitHub details, and returning a unified, flat SQL row.

Building the Sources We Needed

Coral has a great collection of built-in sources, but to capture the full open-source picture, we needed data from PyPI, npm, HackerNews, and Open Collective.

Instead of hardcoding API requests in Python, we extended Coral! We designed and wrote 4 custom YAML source specifications that map external REST and GraphQL endpoints into SQL-queryable tables.

Here is a snippet of the custom GraphQL source spec we wrote for Open Collective:

dsl_version: 3
name: opencollective
backend: http
base_url: https://api.opencollective.com/graphql/v2
tables:
  - name: collectives
    filters:
      - name: slug
        required: true
    request:
      method: POST
      path: /
      body:
        format: text
        content: |
          {
            "query": "query ($slug: String) { collective(slug: $slug) { slug name stats { totalAmountReceived { value } contributorsCount } } }",
            "variables": { "slug": "{{filter.slug}}" }
          }

By mapping the GraphQL variable to the {{filter.slug}} template, we can query Open Collective using a simple SQL WHERE clause:

SELECT total_amount_received FROM opencollective.collectives WHERE slug = 'fastapi'

Upstream Contributions

To help other developers build on this, I opened 3 upstream Pull Requests to the official withcoral/coral repository:

PR #827: Adds the PyPI packages source spec & docs.
PR #828: Adds the npm packages source spec & docs.
PR #829: Adds the Open Collective GraphQL source spec & docs.

From Raw Data to Actionable Insights

Once the Coral engine executes the query and returns a structured record, RepoRank hands the data off to Hugging Face Qwen 2.5 (72B Instruct).

Using structured JSON schema outputs, Qwen acts as an expert open-source analyst, returning:

Impact Score (0-100): Mapped across metrics.
Impact Narrative: A professional, plain-English summary of the project's real-world value.
Funding Pitch: A punchy, one-sentence elevator pitch ready to copy-paste into sponsorship forms.
Targeted Grants: Recommends 3-5 specific programs (e.g., Google Summer of Code, PSF, MOSS, GitHub Sponsors) matching the language, ecosystem, and project scale.

A Premium User Experience

To match the power of the backend, I built a dark-mode dashboard with:

Interactive SVG Radar Charts: Visually represents project balance across 6 key metrics (Stars, Forks, Downloads, Community Buzz, Financial Backing, and Repository Health).
Session-Persistent GitHub Auth: Connect your GitHub account, load up your repositories in a sidebar, and click any repository to trigger an instant analysis.
Clickable Grant Cards: Hardmapped direct links to known grant applications, with dynamic Google search fallbacks for newer programs.
Inspectable Queries: A collapsible SQL details viewer so developers can see the exact query run by the Coral engine.
Keyboard Navigation: Cmd+K to focus the search bar, Cmd+Enter to run the analysis, and Esc to exit modals.

Key Takeaways

SQL as an API Gateway: Treating APIs as SQL tables makes data orchestration significantly simpler. Writing cross-source joins in SQL is cleaner than writing asynchronous API aggregation loops.
Community Expansion: Extending Coral's capabilities by writing YAML specifications shows how powerful declarative source mappings are.
Developer-centric AI: AI models are most effective when fed structured, pre-filtered data. Combining the data-gathering capabilities of Coral with the synthesis capabilities of LLMs creates an excellent pipeline.

🔗 Links & Resources

GitHub Repository: himanshu748/reporank
Upstream Pull Requests: Coral Pull Requests Page

Built for the Pirates of the Coral-bean Hackathon. Happy sailing! 🏴‍☠️