Inspiration

Agentic AI is becoming the default way to build with LLMs, but for a student just starting out there's almost nothing that shows how these systems actually work. You type a prompt, an answer comes out, and you never see how the job was split, which agent did what, or where the tokens went. We hit the same wall on our own agent projects: once a few agents were talking to each other, the only way to understand a run was to dig through logs. So we built cookinUp, a kitchen where every agent is a chef you can watch, question, and redirect, with a learning layer that teaches prompting and task breakdown just by using it.

What it does

cookinUp turns a request to an AI model into a kitchen you can watch and control.

  • Ordering: you type in an order, and a Head Chef breaks it into smaller tasks and writes up a menu.
  • The menu: each task gets its own station with a goal, a model, a token budget, and a set of tools. You can look over the menu and change it before any chef starts cooking.
  • Cooking: a team of chef agents handles those tasks at the same time, and an expediter puts everything together into one final answer.
  • The kitchen setup: each agent is a chef at its own station, each job is a ticket that moves through the kitchen, and tokens are the ingredients.
  • Chefs work together: they can ask each other questions and pass notes directly, so not everything has to go back through the Head Chef. Every conversation shows up as a speech bubble with a line connecting the two chefs.
  • You can step in: at any point, leave a chef a note, switch it to a different model, move tokens between stations, or stop it mid-run. If you rerun a station, it and everything that depends on it gets cooked again so the final answer always matches your changes.
  • Cost tracking: every chef has a live token and cost counter, and when the order is done you get a receipt.
  • Models and keys: cookinUp works with Claude, OpenAI and Gemini. The Head Chef picks a model for each station based on how hard the job is, and you can change any of those picks.
  • Built for learning: cookinUp explains every step in plain words as it happens.
  • Prompt Power meter: it grades your order while you type on four things: what you asked for, how much detail you gave, what shape you want the answer in, and who it's for. Then it suggests one thing to add next.
  • Note helper: it teaches you to give specific feedback like "make it shorter and add a joke" instead of just "redo it."
  • Progress: as your prompts get better, you unlock lessons and move up the ranks from Dishwasher to Head Chef. Five challenges in the Recipe Book earn you badges along the way.

How we built it

cookinUp is built with Next.js, React, and TypeScript, using the Vercel AI SDK for structured outputs and tool loops. Each order runs in its own kitchen service on the server: a planner returns the menu, a scheduler starts every station whose dependencies are done, and the expediter merges the results into one answer and flags conflicts between stations. Every state change streams to the browser over Server-Sent Events, and the canvas kitchen re-renders from that state.

The kitchen itself is a custom pixel-art canvas engine with sprite rendering, pathfinding, and a task queue per chef, with draggable in-game windows layered on top. Stations can run a short research step first, using the provider's web search or by asking a colleague.

The tracks plug in like this:

  • Backboard: after each order, we save a short note about that student's prompting, like "usually forgets to say who it's for." Before their next order, we pull those notes back for a personalized tip ("last time you left out the audience, want to add it?"). Progress follows them across devices instead of living in one browser.
  • Gemini API: Gemini models are hireable for any station, and the Head Chef's hiring guide prices them alongside Claude and OpenAI, so Flash-Lite often wins the cheap jobs.
  • DEV Writing Challenge: we'll publish a write-up of what we built and what we learned.

Challenges we ran into

  • Seeing inside the system without overwhelming users. Showing every message, tool call, and rerun in a way a beginner can follow took a lot of iteration.
  • Keeping reruns correct. When one chef's work changes, everything built on it has to be invalidated and re-cooked.
  • Structured output sometimes came back cut off or invalid, so we added retries that recover without breaking a running order.
  • Chefs can overrun their token budgets, which makes costs harder to predict and control.
  • Making learning feel like play instead of a tutorial, which is where the Prompt Power meter, ranks, and challenges came from.

Accomplishments that we're proud of

In one weekend we shipped a working multi-agent pipeline that runs across Claude, OpenAI and Gemini, with parallel stations, direct chef-to-chef messaging, and reruns that correctly invalidate everything downstream. Every explanation a student sees is built from run data, so the teaching layer costs zero extra model calls. We built the pixel-art kitchen engine ourselves, including sprites, pathfinding and in-game windows, and we integrated Backboard for cross-device memory. Most of all, we took a messy agent pipeline and made it something you can read in a few seconds.

What we learned

Once you can see what each agent costs, deciding where to spend gets a lot easier. Before we had live counters, a long run felt expensive without telling us why. Seeing the cost next to each chef showed us which stations were working harder than their results justified, and that made it simple to move tokens around or switch a station to a cheaper model.

We also learned that plain words explain more than a diagram does. Beginners could follow what was happening once every step was described simply as it happened. Building those explanations from run data, instead of asking a model to write them, meant helping people understand never added to their bill.

Letting chefs talk to each other directly changed how we thought about structure. Sending everything through the Head Chef was easy to follow but slow, while direct conversations moved faster and were harder to keep under control. Showing every exchange on screen mattered more than the speed, because people only trust what they can see.

Reruns taught us to think about dependencies. If one station's work changes, everything built on top of it is out of date, so a rerun has to cook that station again along with everything after it.

Finally, feedback has to be specific to teach anything. "Make it shorter and add a joke" shows a student what a good instruction looks like, and "redo it" doesn't, so we built the note helper and the Prompt Power meter around that idea.

What's next for cookinUp

  • Saving orders on the server so they survive a restart (today only browser snapshots persist).
  • Hard budget limits so chefs can't overrun their allowance.
  • Measuring direct chef-to-chef messaging against routing everything through the Head Chef, on tokens, time, and quality.
  • Replaying past orders step by step, with the ability to zoom in on one chef and see exactly what it's working on.
  • Importing an existing agent setup so teams can map the systems they already run.
  • An advanced learning mode that goes deeper into how LLMs and agent systems are actually built.

Built With

  • agent-orchestration
  • ai-agents
  • ai-safety
  • backboard
  • claude-api
  • data-visualization
  • dev
  • developer-tools
  • github
  • llm
  • multi-agent
  • node.js
  • prompt-engineering
  • react
  • speech-to-text
  • sqlite
  • tailwind-css
  • text-to-speech
  • token-optimization
  • typescript
  • vite
  • voice
  • websocket
Share this project:

Updates

Submission history