DEV Community: Jasmin Virdi

Next in Building TinyAgent series is Streaming!

Jasmin Virdi — Mon, 01 Jun 2026 08:27:35 +0000

Perceived speed vs actual latency

Jasmin Virdi

May 31

Streaming an LLM response, in 4 GIFs

#ai #javascript #webdev #tutorial

Comments 13

5 min read

Streaming an LLM response, in 4 GIFs

Jasmin Virdi — Sun, 31 May 2026 00:16:15 +0000

We have watched tokens stream in from an LLM before where they appeared one at a time, like the model was typing. If you used the Anthropic SDK's .stream() method, it just worked and you probably never saw what was on the wire.

This post will majorly focus on how a stream response works and how bugs are handled by SDK behind the hood.

1. Why Streaming exists

To enable the streaming option we would need to make one change in the post request that is a single field "stream": true and it will change the response experience.

Here are the pointers we take from the gif.

The left side shows no streaming as the cursor blinks for 4 seconds then the whole response lands at once.
The right side shows the streaming where the first word shows up in about 300 milliseconds. Words flow in as the model generates them.

Both the sides have same model, same prompt, same total time it is just the right side started giving response almost 4 seconds earlier. The 4 seconds wait time for a full reply feels broken. A streamed reply that finishes in four seconds feels fast. Streaming doesn't make the model faster it makes the wait disappear.

2. What's on the wire

When you set stream: true, the API stops sending a single JSON blob. It opens a persistent HTTP connection and pushes events down the line as the model generates them. The format is Server-Sent Events (SSE) a web standard. Any SSE debugger will read this stream.

Here's what comes through:

A few things to notice:

The text lives in delta.text, nested inside content_block_delta events. Those are the events we should look after.

stop_reason moved. In post 1, we saw it right there in the response JSON. Here, it arrives at the very end inside a message_delta event, just before message_stop. If the loop bails out as soon as the text stops arriving we will never see it.

Chunks don't line up with tokens or words. You might get "Hello" in one chunk and " world" in the next, or both in one. The network decides where the cuts happens and it is not the model, not the API.

That's what the SDK has been hiding from you.

3. Reading the stream

Streaming sounds complicated until we write the loop. It's just reading bytes, buffering them, splitting on blank lines, and parsing JSON.

Here's the flow:

The response body is a ReadableStream which can be iterated with for await.
Each iteration gives us bytes which we can decode to string.
Buffer the string. A chunk might end mid-message.
Split the buffer on \n\n — that's the SSE message separator.
Keep the last item in the buffer. It might be incomplete.
For each complete message, find the data: line, strip the prefix, and parse the JSON.
If the type is content_block_delta, print delta.text.
If it's message_delta, you've got your stop_reason.

Here is the complete sample code you can use to try out:

const prompt = process.argv[2] ?? "Count to 10, slowly.";

const response = await fetch("https://api.anthropic.com/v1/messages", {
  method: "POST",
  headers: {
    "x-api-key": process.env.ANTHROPIC_API_KEY,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-opus-4-5",
    max_tokens: 1024,
    stream: true,
    messages: [{ role: "user", content: prompt }],
  }),
});

const decoder = new TextDecoder();
let buffer = "";

for await (const chunk of response.body) {
  buffer += decoder.decode(chunk, { stream: true });

  const messages = buffer.split("\n\n");
  buffer = messages.pop() ?? "";

  for (const message of messages) {
    const dataLine = message.split("\n").find(l => l.startsWith("data: "));
    if (!dataLine) continue;

    const data = JSON.parse(dataLine.slice(6));

    if (data.type === "content_block_delta" && data.delta.type === "text_delta") {
      process.stdout.write(data.delta.text);
    }

    if (data.type === "message_delta") {
      process.stderr.write(`\n\n[stop_reason: ${data.delta.stop_reason}]\n`);
    }
  }
}

The way it is working is that when the chunk ends in the middle of a message split("\n\n") leaves an incomplete fragment as the last item. pop() pulls it back into the buffer so the next chunk can finish it. Without this line, every split message crashes the parser.

data.delta.type === "text_delta" this check matters because content_block_delta can carry other delta types too: input_json_delta for tool arguments, thinking_delta for extended thinking, signature_delta for verification. For now we only care about text.

You can find the full implementation here on GitHub as well.

4. Three bugs

The code above works on a good day. Here's what breaks it on a bad one.

The ghost stream. The issue is user navigates away with the stream keeps running and tokens keep arriving with nobody to read them. In order to fix this pass an AbortController signal to fetch and call abort() when you're done.

The fix is an AbortController:

const controller = new AbortController();
const response = await fetch(url, { signal: controller.signal, ...options });
// later, when the user navigates away:
controller.abort();

The silent truncation. The API can send an error event mid stream during overload. If the loop only handles content_block_delta, the error gets skipped and you end up with a truncated response and no exception. The fix is to handle data.type === "error" explicitly.

if (data.type === "error") {
  throw new Error(`Stream error: ${data.error.message}`);
}

The split packet. A single SSE message can arrive in two TCP packets. Without buffering, JSON.parse throws on the half. This is what buffer = messages.pop() ?? "" fixes, it holds the incomplete piece until the next chunk completes it.

stop_reason, in a stream

In post 1, stop_reason was right there in the response JSON. In a stream, it's the same four values end_turn, max_tokens, tool_use, stop_sequence but they arrive inside a message_delta event near the end of the stream.

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"end_turn",...}}

The same rule from post 1 applies: if you ignore stop_reason, you'll ship a bug. A max_tokens cutoff in a streamed response looks exactly like a normal end of stream. You won't know the model was cut off unless you read this event.

Three things to try before the next post

1. Run the streaming code. Then change "stream": true to false and run it again. Notice how long you wait before seeing anything. That gap is what your users feel.

2. Add console.error(chunk.length) inside the for await loop, before any parsing. Run the code and watch the numbers. You'll see chunks of wildly different sizes it could be 8 bytes here, 400 bytes there. The network decides, not the model. Tokens and chunks are not the same thing.

3. Start a stream, then disconnect your wifi mid response. Watch what happens. The loop hangs, then eventually throws but only if we have added error handling. This sets up the error handling post later in the series.

What's next

TinyAgent can now stream a response. Tokens land as they arrive. stop_reason shows up at the end. It still has no memory though every call starts blank.

In the upcoming post series we will capture another important details. 😁

Happy Coding! 👩‍💻

An LLM API call, in 4 GIFs

Jasmin Virdi — Tue, 26 May 2026 20:52:22 +0000

This is the first post of series Building TinyAgent where we are going to build a small agent from scratch in Node.js with no frameworks just the API calls.

But before we write an agent, we need to understand what actually happens when you call an LLM. If you've only ever used a SDK, you've probably never seen the raw request and understand how it works. Six lines of code, an API key, and it just works but you have no idea what happened when request was dispatched and response was printed on the screen.

1. The request

Here is the sample API call with each and every section explained in detail.

A few things worth noticing in the API call.

The API is stateless: Every new API call does not remember previous call context. If you want a chatbot that "remembers" earlier messages, you hold the messages array and resend the whole thing every time.

max_tokens is a hard stop, not a target. If you hit the target the response stops mid sentence.

The API call pattern is universal. Different URL, Authorization: Bearer instead of x-api-key, the system prompt lives inside messages rather than at the top level. But it's the same POST, the same JSON, the same {model, messages, max_tokens}. Once you understand the shape, switching providers is just a find-and-replace.

2. The response

The API answers with a JSON blob. There are ~10 fields in it, but only four actually matter:

The one which is mostly skipped is: stop_reason.

It tells you why the model stopped, and in real systems and there could be possible reasons behind it:

end_turn      → finished naturally, you're done
max_tokens    → hit your ceiling, response is truncated
tool_use      → model wants to call a tool (next post!)
stop_sequence → matched one of your stop strings

If you only check the text and ignore stop_reason, you will ship a bug at some point. The response looks fine right up until it doesn't.

The other field worth burning in: usage. It shows you how many tokens went in and came out. You want this number in your logs from day one not after you get a surprise bill. 🤯

3. Tokens

I keep saying "24 input tokens." Here's what that means:

Things that surprise people and is worth noting:

Words don't equal tokens. "Unbelievable" is one word but four tokens. The tokenizer splits on common substrings, not spaces.

Code costs more than it looks def add(a, b): is 8 tokens. Every bracket and comma is its own token.

JSON is expensive. {"a":1} is 7 tokens. If your tool schemas are bloated, they're quietly eating into your budget on every single request.

Non-English costs more Japanese, Hindi, Arabic tend to run 2–4× the token count of the same content in English. If you're building for a global audience, this changes your cost math a lot.

Rule of thumb for English prose: ~1 token ≈ 4 characters ≈ 0.75 words. For everything else, run it through the tokenizer yourself before assuming.

4. The bill

Two meters run on every call. They are priced differently

Output tokens cost roughly 3–5× more than input tokens. That's the one number to internalize about LLM pricing.

cost = (input_tokens  / 1,000,000) × input_price
     + (output_tokens / 1,000,000) × output_price

Three things that follow from the asymmetry:

Long prompts are cheap. Long responses are expensive. Stuffing 50 KB of context into a system prompt is fine. Asking for 50 KB of output is roughly 5× more expensive.
"Thinking" tokens count as output. Reasoning models bill their internal thought at the output rate, even though you don't see it.
Tool schemas eat input on every call. They get resent with every request, just like the system prompt.

At $0.006 per call, 100k calls a day is $600/month from one small feature. Add usage logging now, not when you get the alert. 🚨

5. The whole thing in 20 lines

Here is the complete code of the API call we have discussed above:

Jasmin2895 / TinyAgent

No dependencies and no install setup it is just Node file with API key.

Three things to try before the next post

Run it and watch the numbers Make ten calls, change the prompt length, see how usage moves. You'll build a real instinct for cost faster this way than reading any doc.
Set max_tokens: 20 and ask for something long. Watch it cut off. Check stop_reason. This is a bug you'll hit in production eventually better to meet it on purpose right now
Build a multi-turn chat by hand. Keep a messages array, push each user message and each model reply onto it, and resend the whole thing every turn. Once you do this, you'll immediately understand why long conversations get expensive you're paying for the full history on every call.

What's next

In the upcoming post series we will expand the ability of the TinyAgent to actually handle lot of things than just responding.

Happy Coding! 👩‍💻

I Taught Two AIs What Not to Say About Their Humans

Jasmin Virdi — Sun, 26 Apr 2026 18:28:05 +0000

This is a submission for the OpenClaw Challenge.

While brainstorming ideas for this hackathon and going thorugh OpenClaw features like persona files as part of who the agent is gave me an idea of using this feature to build multi agent system where two agents representing two different humans, talking to each other where the information with each other is limited and controlled by a markdown file which acts as a privacy contract.

What I Built

Clawmate is two AI agents, each representing a different human, talking through a shared file. Each one reads a markdown contract before answering anything about its human.

Alice 🦞 is mine. Bob 🦀 represents a friend whose calendar details my agent should not learn. They share a file at ~/clawmate-shared/backchannel.json. Alice writes a query into it. Bob reads, applies his contract, writes a filtered answer back.

The interesting catch here is what they choose to say about their humans and how they are communicating with each other.

Architecture Explanation

Two workspaces, two agents - Alice in ~/.openclaw/workspace/, Bob in ~/.openclaw/workspace/bob/. Each has its own Telegram bot, routed independently with openclaw agents bind --agent bob --bind telegram:bob so messages to Bob's bot reach Bob and not Alice.
One shared file that is ~/clawmate-shared/backchannel.json is the "conversation" between the two agents. They don't message each other on Telegram they just read and write into this JSON file.
Two privacy contracts - Each agent has an IDENTITY.md that lists what it will and won't share about its human. The agent reads the file as binding.

Bob's agent markdown contract.

## Privacy contract

### Never share
- Event names or descriptions
- Message contents from anyone
- Names of people Bob is meeting with
- Locations Bob will be at

### Do share
- Whether Bob is busy or free in a time range
- Whether Bob can be reached for an emergency

### When in doubt
Refuse, name the rule, offer what you can give.

How I Used OpenClaw

The best part about building this is OpenClaw's design choice to make persona files. The features I used here are:

Two agent workspaces with separate session stores, so Alice and Bob don't share memory
Telegram channel bindings with agents bind to route distinct bots to distinct agents
Filesystem tools so each agent can read/write the shared backchannel and its own calendar
The IDENTITY.md persona layer as the actual enforcement mechanism for the privacy contract
A custom Clawmate skill describing the send-query/respond-to-query protocol

Demo

I gave Bob a mock calendar with deliberate privacy traps:

{
  "owner": "bob",
  "events": [
    { "date": "2026-04-26", "start": "18:00", "end": "20:00", "title": "dinner with emma" },
    { "date": "2026-04-27", "start": "14:00", "end": "15:30", "title": "therapy" },
    { "date": "2026-04-28", "start": "19:00", "end": "22:00", "title": "concert" }
  ]
}

Asking about Bob calendar but due to contract the limited information is shared by Bob's agent.

Agent to Agent Loop between Bob and Alice Agent

Alice writes the query

Bob reads, filters, responds.

The shared file as ground truth.

The conversation between Alice and Bob's agent is a JSON file changing over time. Their entire message exchange along with query and answer is present in the file. The word "concert" is not there. The privacy contract is the gap between what Bob read and what Bob wrote.

What I Learned

The thing first when building this project was that OpenClaw treats persona files differently than I expected. On most agent platforms I've used, IDENTITY.md would be styling but OpenClaw deals it differently. I used it as a persona file OpenClaw reads as the agent's identity, not as styling. For Clawmate, it's where Bob's privacy contract lives a plain language list of what limited information will be shared by defining set of rules.

The workspace model was quietly doing the same kind of work for separation. Alice and Bob really did have separate brains, separate persona files, separate session stores, separate sandboxes without me wiring up two parallel stacks. One config, two agents, no shared state I had to defend against.

I used this command agents bind --agent bob --bind telegram:bob to route two Telegram bots to two distinct agents which was pretty easy and quick. Another exciting part was how unobtrusive the filesystem tools were. Bob wrote structured JSON to the backchannel file, in the right schema, in response to a Telegram prompt, with no wrapper code from generated from some helper or application.

OpenClaw made the parts I expected to be hard disappear, which let me let me focus on the part that actually mattered that is designing the protocol and the contract between two agents, instead of fighting the platform to support them.

ClawCon Michigan

I didn't attend ClawCon Michigan. Would definitely love to attend in future. 👩‍💻

Thanks Dev and OpenClaw team for organising this amazing hackathon.

VibeBurst: Chrome extension to redesign website vibe!

Jasmin Virdi — Wed, 04 Mar 2026 08:23:16 +0000

DEV Weekend Challenge: Community

Jasmin Virdi

Mar 1

VibeBurst: I Built a Chrome Extension That Lets AI Redesign Any Website's Vibe

#showdev #devchallenge #weekendchallenge

Comments 9

3 min read

VibeBurst: I Built a Chrome Extension That Lets AI Redesign Any Website's Vibe

Jasmin Virdi — Sun, 01 Mar 2026 23:03:37 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

You know that feeling when you've been staring at GitHub for 6 hours straight and everything just looks... the same? Every site, same vibe, same boring UI. Dark mode if you're lucky. Maybe someone made a theme extension for that one specific site. Cool.

But what if you could just throw a whole aesthetic onto any site? Like, cyberpunk GitHub at 2am because why not. Glassmorphism on your docs. Brutalist Hacker News — which honestly already looks like that anyway.

Yeah, that's what I built.

What I Built

VibeBurst is a Chrome extension. You click it, pick a theme, and AI restyles the entire page with custom CSS. Not some generic stylesheet that breaks everything — it actually reads the page and generates CSS that makes sense for that specific site.

The four themes:

⚡ Cyberpunk — dark backgrounds, neon cyan and magenta glows, monospace fonts
🔮 Glassmorphism — frosted glass aesthetic, soft purple and teal, airy and light
🧱 Brutalist — maximum contrast, pure black and white, bold red accents, zero ornamentation
🌅 Retro Wave — warm 80s sunset gradients, neon pink and sky blue, synthwave nostalgia

Hit Regenerate to get a fresh take. Hit Reset to go back to normal. That's it.

Demo

Here's is simple demo and screenshots of how this works on different websites.

Same View in different views:

Code

Github repository link - https://github.com/Jasmin2895/VibeBurst

How I Built It

Stack: Plasmo + TypeScript + React for the extension, Groq API with llama-3.3-70b-versatile for generating CSS. Nothing fancy.
The AI part was honestly the easy bit. The hard part? Making the CSS not destroy the page.

Early versions were a mess. * selector wrecks everything. Touch width/height and the layout's gone. Bad contrast and you can't read anything. Took a lot of trial and error — ended up building a sanitizeCSS function to strip out anything that could break layouts before injecting.

Then there's the fact that most sites barely use semantic HTML. It's all divs and class names. Targeting header or nav does almost nothing on sites like Google. So I had to scan the site's actual stylesheets, find every class setting a background-color, and catch the JS-injected ones too.

Biggest thing that clicked: don't let the AI pick colors for class selectors. Let it style body, h1, button — the semantic stuff. Then grab the body background-color and apply it to all site-specific classes programmatically. That's when things finally stopped looking patchy.

No JS touched. Page works the same. Just looks different.
Weekend project that taught me CSS specificity is painful and theming the web is harder than it should be. 😅

It was an overall great learning experience. Thanks Dev Team for organising this short weekend challenge! 👩‍💻

VibeBurst: I Built a Chrome Extension That Lets AI Redesign Any Website's Vibe

Jasmin Virdi — Sun, 01 Mar 2026 23:03:37 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Yeah, that's what I built.

What I Built

The four themes:

⚡ Cyberpunk — dark backgrounds, neon cyan and magenta glows, monospace fonts
🔮 Glassmorphism — frosted glass aesthetic, soft purple and teal, airy and light
🧱 Brutalist — maximum contrast, pure black and white, bold red accents, zero ornamentation
🌅 Retro Wave — warm 80s sunset gradients, neon pink and sky blue, synthwave nostalgia

Hit Regenerate to get a fresh take. Hit Reset to go back to normal. That's it.

Demo

Here's is simple demo and screenshots of how this works on different websites.

Same View in different views:

Code

Github repository link - https://github.com/Jasmin2895/VibeBurst

How I Built It

No JS touched. Page works the same. Just looks different.
Weekend project that taught me CSS specificity is painful and theming the web is harder than it should be. 😅

It was an overall great learning experience. Thanks Dev Team for organising this short weekend challenge! 👩‍💻

VibeBurst: I Built a Chrome Extension That Lets AI Redesign Any Website's Vibe

Jasmin Virdi — Sun, 01 Mar 2026 23:03:37 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Yeah, that's what I built.

What I Built

The four themes:

⚡ Cyberpunk — dark backgrounds, neon cyan and magenta glows, monospace fonts
🔮 Glassmorphism — frosted glass aesthetic, soft purple and teal, airy and light
🧱 Brutalist — maximum contrast, pure black and white, bold red accents, zero ornamentation
🌅 Retro Wave — warm 80s sunset gradients, neon pink and sky blue, synthwave nostalgia

Hit Regenerate to get a fresh take. Hit Reset to go back to normal. That's it.

Demo

Here's is simple demo and screenshots of how this works on different websites.

Same View in different views:

Code

Github repository link - https://github.com/Jasmin2895/VibeBurst

How I Built It

No JS touched. Page works the same. Just looks different.
Weekend project that taught me CSS specificity is painful and theming the web is harder than it should be. 😅

It was an overall great learning experience. Thanks Dev Team for organising this short weekend challenge! 👩‍💻

Rekall — A Context Recovery CLI That Uses GitHub Copilot as Its AI Brain

Jasmin Virdi — Mon, 26 Jan 2026 17:21:05 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Rekall is a zero-config CLI that helps developers recover context after meetings, breaks, and context switches. Instead of piecing together git status, git log, and git stash list every time you sit back down — you type one word: rekall

Rekall collects your entire project state — branch, commits, uncommitted changes, stashes, TODOs, FIXMEs — and sends it to GitHub Copilot CLI as a structured prompt. Copilot acts as the AI analysis engine, synthesizing raw data into a concise summary, suggested next step, and blockers.

Most cases we use Copilot to write code. Rekall uses Copilot to power the product — four commands, each with its own Copilot touchpoint:

rekall context — Copilot synthesizes your project state into summary, next step, and blockers
rekall pr — Copilot analyzes PR changes with risk assessment and review questions
rekall explain — Copilot explains your recent commits in natural language
rekall suggest — Copilot generates commit messages or branch names from your changes
rekall onboard - A quick cheat sheet to understand the project structure and what's new.

The tool is built in TypeScript and works with or without Copilot installed — gracefully falling back to intelligent rule-based analysis.

Demo

GitHub: https://github.com/Jasmin2895/rekall
npm package link: https://www.npmjs.com/package/rekall-cli
npm: npm install -g rekall-cli
Try instantly: npx rekall-cli

Rekall with Github Copilot CLI

Rekall without Github Copilot CLI


$ rekall explain              # Copilot explains your recent work
$ rekall suggest              # AI commit message suggestions
$ rekall pr 1                 # Give summary overview of the PR
$ rekall onboard              # Quick cheat sheet for project
$ rekall suggest "add dark mode" --type branch  # Branch name suggestions
$ rekall --format json | jq '.analysis'         # JSON for scripting

Quick Test

cd any-git-repo
npx rekall-cli
npx rekall-cli explain
npx rekall-cli suggest "your feature idea" --type branch

Requirements: Node.js 18+, Git. Optional: gh CLI for PR mode, gh extension install github/gh-copilot for AI-powered analysis.

My Experience with GitHub Copilot CLI

Rekall doesn't just use Copilot CLI during development — it uses Copilot CLI as the product itself. Every command pipes collected project data into gh copilot and parses what comes back. That's the entire architecture.

When you run rekall, your git state and code issues get packed into a prompt and sent to Copilot CLI via execute command. The response is parsed into sections — SUMMARY, NEXT_STEP, BLOCKERS — and rendered as clean terminal output. All four commands follow this same pipeline.

If Copilot isn't installed, Rekall doesn't break. It falls back to a rule-based engine that prioritizes FIXMEs, scores PR risk by file type, and generates commit messages from conventional patterns. It works — but Copilot's output is noticeably better. The tool tells you which mode you're in so there's no guessing.

Building With Copilot CLI

The most useful part of Copilot CLI during development was testing my own prompts. I'd run gh copilot -p with a rough prompt explain with different prompt structures directly in the terminal, see what came back, tweak the wording, and repeat — before writing any parsing code. That saved me from a lot of trial-and-error.

It also caught a shell escaping issue I would've missed. I was passing raw project data (file paths, commit messages) into the prompt string, and Copilot helped me think through what characters could break the shell command. That's how the escaping logic ended up covering backslashes, quotes, dollar signs, and backticks.

My initial error handling was too optimistic, only checking if Copilot was "not installed." During testing, I hit a variety of edge cases: API quota limits (402), authentication errors, and generic "no quota" messages. Each time, my tool (Rekall) tried to parse the error as a valid response.

Using the CLI, I mapped out every failure mode gh copilot could return. This allowed me to build a comprehensive pattern list that catches these exceptions silently and lets the tool fallback gracefully.

Looking back, the thing that worked best was treating Copilot CLI as a conversation partner I could test ideas against — right there in the terminal, no context switching needed.

It was an overall great learning experience thanks to Dev and Github Team for organising it. 👩‍💻

[Boost]

Jasmin Virdi — Thu, 03 Jul 2025 15:15:56 +0000

Jasmin Virdi

Jul 1 '25

Quizbit: Turn Any Article Into an Engaging Slack Quiz.

#devchallenge #runnerhchallenge #ai #machinelearning

Comments

3 min read

Quizbit: Turn Any Article Into an Engaging Slack Quiz.

Jasmin Virdi — Tue, 01 Jul 2025 22:38:58 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

What I Built

I built an AI-powered "Quiz Master" for Slack using a Runner H workflow. This automation takes any online article and instantly generates an engaging, five-question quiz based on its content. The Quiz Master then posts the quiz directly to a designated Slack channel, one question at a time, creating a fun and interactive learning experience for the team. After a brief pause, it reveals the correct answers with explanations, making it a seamless way to test and reinforce key takeaways from shared reading materials. This solves the problem of "did they actually read it?" by turning passive information consumption into an active and gamified group activity.

Demo

Here is the demo of setting up a Sample Slack Quiz using an article.

Here is the final output view in Slack.

How I Used Runner H

This entire workflow is powered by a single, carefully crafted Runner H prompt. The AI agent handles the content analysis, question generation, formatting, and timed message delivery.

Here is the exact prompt I used:

Based on the article at {source_url}, generate a 5-question quiz that tests the main insights and key data points from the text.

For each question, provide the question in bold using Slack’s mrkdwn format, followed by four answer choices, each prefixed with a number emoji (e.g., :one:, :two:). Structure the quiz so each question and its answer options are sent as a separate message to {slack_channel}. Ask the channel Id and source_url of article from user to post.

After 30 seconds, send a follow-up in the thread of last message listing the correct answers and providing brief explanations for each.

Ensure each message is clearly formatted for Slack and suitable for a gamified experience. If Zapier’s Slack integration supports Block Kit elements, include interactive buttons for answer selection; otherwise, present answer options as plain text

You can view the Runner H session here:

Surfer 2: The Next Generation of Cross-Platform Computer-Use Agents - H Company

We are a frontier AI research company that designs, builds, and deploys cost-efficient agentic AI systems directly into enterprises’ core workflows and processes.

hcompany.ai

Use Case & Impact

This AI Quiz Master has several powerful real-world applications:

Corporate Training & HR: HR and training teams can use this to quickly assess comprehension of training materials, new company policies, or onboarding documents. It makes mandatory reading more engaging.

Content & Marketing Teams: After sharing an important industry report or a new company blog post, marketing teams can use the quiz to reinforce key findings and ensure everyone is aligned on the core message.

Educational Settings: Teachers and study groups can use it to create quick quizzes from articles, research papers, or news items to facilitate discussion and test knowledge.

General Team Engagement: It serves as a great tool for team-building. You can run a weekly quiz on a fun or interesting article to foster a more interactive and connected team environment in Slack.

The primary impact is efficiency and engagement. It saves managers and team leads significant time by automating the creation of learning materials. More importantly, it transforms passive reading into an active, collaborative, and fun experience, which significantly boosts information retention and team participation.

Social Love

// Detect dark theme var iframe = document.getElementById('tweet-1940430429494083615-784'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1940430429494083615&theme=dark" }

Huge thanks to Dev and Runner H Team for this hackathon! I really enjoyed participating. It was a refreshing and different kind of challenge, focusing on the creative art of AI prompting rather than just lines of code.

Subscription Intelligence Hub - Your financial emails Knowledge Hub!

Jasmin Virdi — Wed, 04 Jun 2025 22:33:41 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

We often have come across this problem where we sign up for stuff and later wonder, "Why am I paying for this again?" and also we have so many bills paid via different payments apps and email is the only place where we get notifications from all these app payments. I built the Subscription & Purchase Intelligence Hub to fix that!

Just forward your financial emails such as e-receipts (even PDFs!) and related email chats to one Hub address.

AI figures out the financials: It uses OpenAI to grab the vendor, product, price, and category from your receipts. It also converts receipts uploaded in any currency into USD.
It gets the "vibe": For your discussion emails, it uses NLP to find key comments and even tells you if the sentiment was good (👍), bad (👎), or so-so (😐).
Everything connects: The Hub links your spending to these contextual insights automatically.
Your personal view: Pop in the email you forwarded from (no complicated sign-ups!) and see your finances with the "why" clearly laid out on a simple dashboard.
Basically, it helps you actually understand your spending, not just see the numbers.

Demo

You can access the app live app here

Steps to use the app.

Forward all your bills and reciepts to postmtest06@gmail.com to analyse.
Go to the Dashboard page

You will see your financial summary categorised by month spending and spending by category/vendor

Here we also show the Financial Items containing context of financial discussion or info derived from email.

Detailed financial card item open view.

If the Item is recurring event like monthly or yearly subscription we show the next payable date. There is an Add Renewal to calendar button which generates downloadable .ics file which can be used to create event in calendar.

For reminders I have setup a slack channel where i post regular updates of expenses. This was a feature to showcase that if this is managed by team they can handle or post regular updates of the expenses of teammates in slack channel for subscriptions renewals. Link to slack channel

Code Repository

Link to the Github repo

How I Built It

I really wanted to make financial tracking less about just numbers and more about the story – the 'why' behind what we spend. My goal was to turn that email clutter into actual understanding.

I created a Node.js/Express backend with a PostgreSQL database, and a React frontend. The first, and most crucial, step was email ingestion. This is where Postmark truly shone for me. Setting up the inbound webhook was incredibly straightforward. It just worked, consistently delivering emails as well-structured JSON – even PDF attachments. OpenAI API does the heavy lifting on parsing financial details from all sorts of emails and PDFs. The natural NLP library helps dig out key contextual sentences from discussions and figures out the sentiment.

Here is the backend process preview.

It was a fun challenge to combine these tools to turn messy email data into clear, actionable insights!

I have also thought about enhancing this in future by adding Google calendar integration where the user can directly add reminder in their calendar instead of downloading ics file.

Thank you to PostMark and Dev.to team for bringing this challenge to us.