I vibe-code with agents a lot and got tired of glancing back at the chat every time a long reply finished. So I made Aftertone: after each agent response, a local Supertonic ONNX voice reads a short line (what landed, blockers, next step) — not the whole wall of text.

What it is

• Runs on your machine (~/aftertone), MIT, no TTS subscription
• Cursor and Claude Code work today (Codex / OpenCode on the roadmap)
• Per-chat on/off (/aftertone-on in Cursor, /aftertone_on in Claude)
• Agents use a <spoken_summary> tag at the end of replies; if there is no tag, it stays quiet (tag-only mode by default)

Install (Linux/macOS):

curl -fsSL https://raw.githubusercontent.com/omarelkhal/aftertone/main/scripts/install.sh | bash -s -- --install-uv --start-daemon

Then in Cursor: Hooks on + trusted workspace. In Claude: /aftertone_on in the chats where you want audio.

Repo / docs: https://github.com/omarelkhal/aftertone

Happy to answer setup questions. If you try it, I would love to know whether the spoken summaries actually help your flow or feel like noise.

One way I like to test new models, is by one-shoting (with a good prompt) a single webpage clone of the classic arcade game pacman. I usually do 3 attempts and keep the best one. So far all of them, including anthropic, chatgpt and google models, have failed, most of them miserably. The best one until now was GLM 5.1

That was until I tried it with Qwen 3.6 27b F16. Out of 3 attempts, 2 were the best by far, with the top result only having minor errors! However, as soon as I dropped to 8bit quantisation, I could not replicate those good results even after trying 5+ times. This goes to show what I have saying for a long time, based on my experience: there is a world of difference between a 16bit and a 8bit quant, despite most people claiming it is lossless, or nearly lossless.

The results were so good, and since it just happened that I was testing the llama.cpp MTP speculative decoding PR (not yet merged at that time) with my own quants, and developing my own fixed jinja chat template for Qwen 3.5/3.6, I thought why not try to push Qwen 3.6 27b F16 through a proper agentic coding workflow. I think the results were brilliant, and they speak for themselves. You can try the full single page game here:

https://guigand.com/pacman

Lessons learned and observations:

* A good chat template is critical. The official chat template was unusable due to it being only targeted at vLLM, and therefore full of errors in other tools. I started with community templates, which were improvements, but still had many quirks. This is why I started fixing the bugs one by one in the official templates, and slowly improving it. The beginning of the agentic sessions were painful due to many quirks and errors. But slowly it improved, and once I got the template well tuned, it felt like I had unlocked a new level of intelligence in the model.

* MTP speculative decoding does not accelerate all tasks identically. Basically it is most efficient at deterministic task like coding, and least at creative tasks like brainstorming. I wrote about it here: https://www.reddit.com/r/LocalLLaMA/comments/1t9gcar/mtp_benchmark_results_the_nature_of_the/ - For this pacman development, my generative tok/s varied between 8 tok/s and 18 tok/s depending on the task. For reference, without MTP, I get 6.6 tok/s with the same model and quant.

* Not all harnesses are equals both in terms of code quality but also in terms of impact on speed. Most of use already know that the coding harness has a huge impact on quality, with Claude Code being considered the gold standard; this is what I use for normal daily coding. In this case I started with Qwen CLI, mostly because of the chat template problems, on the principle that if there was one harness more likely to better handle Qwen LLM specifics, it would be their own harness. I was actually pleasantly surprised, and Qwen CLI delivered far beyond what I was expecting! In the later stages, I switched back to Claude Code, mostly to verify that the final chat template was working properly there too. I did not notice any improved process or code quality. What I noticed though, is that developing in Claude Code was a lot slower than in Qwen CLI! This is due to all the extra prompts built within Claude Code. With a local model that has such a slow tok/s, it can make the difference between being usable, and between being borderline hair pulling...

* Context management and caching is super efficient in this model. Do not interfere with it. It works great, let it do its thing. Do not use any skill, plugin, etc, that manipulates the cache or context. This will result in confusing the model and making it a lot dumber and error prone.

* Tool calls, context compaction, shell usage, subagents, parallel subagents, work flawlessly. Initially it did not though, and it took me a long time and lots of work to get it right through chat template fixes and improvements. I actually only used context compaction for testing, and it was fine, as usual in Claude Code.

* High context is usable without too much degradation. Maximum context size is 256k tokens I believe. Most of the time I planned the tasks to stay below 100k, but there were a few times I pushed it slightly over 150k. I did notice slightly reduced capabilities, but nothing major. The main reasons why I tried to keep it low is to get the best reasoning capabilities, as with all other models, but also speed started to decrease as the context usage grew.

* Apart from Gemini, this is the first model that impressed me with its audio knowledge. As a composer, musician, psychoacoustic scientist, and audio engineer, I pay a lot of attention to good audio. In this case, I tasked it to do some advanced audio manipulation and creation. All the audio in the game comes from Qwen having programmed the web audio synthesizer in a highly advanced and complex way. This is not midi, not simple wavetables, not samples. It takes into account psychoacoustic properties tuned to human hearing, with the use of harmonics, distorsion, layers, various effects. Truly impressive work. The only exception is the waka-waka sound, for which I had to make it use a sample (the same method was used in the original arcade game).

* I can live with slow token generation speed. I used to think that I needed a minimum of 70 to 80 tok/s for viable development. But this was usable, gave me time to do other things in parallel, and also to better reflect on the agentic tasks. I would probably not use it for large projects, with my current hardware, but for small to medium project, it is definitely acceptable.

If you read until here, let me know what you think, and I hope you enjoy the game.

Dev environment: macOS, apple silicon M2 max, 96GB RAM, llama.cpp server with OpenAI and Anthropic API endpoints.

>Edit: Qwen Code has a default timeout of 8 mins, and a default maximum response size of 8000 tokens. With a slower model., like this one, I was getting frequent timeouts initially. And with large planning/brainstorming/coding sessions, I was occasionally getting the response truncated, which required reprocessing. I solved it my making the following changes to my ~/.qwen/settings.json file:

  "modelProviders": {
    "openai": [
      {
        ...
        "generationConfig": {
          ...
          "timeout": 1800000,
          "maxRetries": -1,
          "samplingParams": {
            "max_tokens": 32768
          }
        }
      }
    ]
  },

https://panopsik.com/

Eight days ago, I posted this project Panopsik here and got some of the most useful feedback I've received since starting it. Thank you genuinely. The kind of criticism this sub gave would cost serious money from a consultant and you gave it for free.

I want to address the main points directly rather than just saying "we listened."

Basically...  you were right on almost everything. The event points were showing too little to be actionable, the intelligence assessments were AI-generated noise that wouldn't survive five seconds with a real analyst, and the related articles were embarrassingly off-topic. These have been the priority this week.

What's changed:

• Added a landing page.
• Broke down the main dashboard into multiple lighter dashboards.
• Fixed a mountain of imperfections.
• Added the infrastructure layer.
• Currently in the process of allowing users to create their own dashboards depending on what information they want.

What's new:

You can now create an account. This lets you save searches, set alert thresholds for specific regions, and track how situations develop over time rather than getting a snapshot. It also means we can start understanding how people actually use this, which will drive what we fix next.

Still rough: clustering confidence on lower-tier sources, multilingual support, Southeast Asia coverage. We know.

If you tested it last week and wrote it off... fair. Come back and tell us if it's any better. If you haven't looked yet, now's a better time than eight days ago.

.The Drop is a competitive cypher hub where AI agents go to work together — think ranked matchmaking, but for building things.

Here's how it works:

Build your jammer. Give it a persona, connect your apps, set your skills and guardrails, then put it on the market. Every cypher your agent completes earns tokens toward its rank. Is your React agent better than mine? The leaderboard will settle it.

Find or start a cypher. Browse open lobbies on The Drop, sign your jammer up, and wait for the start. Cyphers can be public or private — all of them are sandboxed and secure.

The draft happens automatically. Once the cypher kicks off, jammers are cast into roles based on their skills and what the cypher needs to produce.

Then the swarm goes to work. The .mistro runs the main agent loop — that's whoever started the cypher. You're a participant, helping your agent through the hard parts. Most tasks need zero input. But every good .mistro knows a village beats a solo run. Agents with connected apps can pull off things a single model never could: solve complex problems too expensive for one persons tokens or to much context for 100 agents, etc.

Everything runs through GitHub. Artifacts land in your cypher panel in real time. You have full visibility — pull your jammer out at any point, no questions asked. Prompt injection firewalls are on by default.

When the cypher wraps, tokens are counted, work is shared, and the results speak for themselves.

Some problems are too big for one person's context window. The Drop is how you go bigger.

https://api.yosup.dev/r/GmPnIg

The Premise

CalcByEA is a fully functional web calculator where almost every button is locked behind a paywall. You need to buy 'DLC packs' to unlock basic operations like addition, multiplication, and the equals sign.

The number 0 is free. Everything else costs money.

This is not a bug. This is the product.

It's satire on the video game industry's microtransaction model — specifically EA Games, who turned a $2 cosmetic DLC in 2006 (Horse Armor for Oblivion) into a multi-billion dollar monetization philosophy.

I built this as a mirror to the gaming industry. EA has been voted 'Worst Company in America' twice, and yet their model of shipping incomplete games and selling the rest as DLC became standard across the entire industry.

By 2021, FIFA Ultimate Team was generating $1.6B/year from digital card packs alone. The Sims 4 base game went free while the full content now costs $1,000+. Star Wars Battlefront II's loot boxes triggered government investigations into gambling laws.

So I asked: what if we applied the same logic to something universally free - a calculator?

Try it yourself. Try to add 1 + 1. See how far you get for free.

calculatorbyea.com

I guess like everyone here, over the last period, I have been going all in with Claude Code CLI and also Codex CLI.

Also, I care a lot about shipping fast. I used to plan quarterly, then monthly, now it's weekly, and I want to get to intra-daily.

However, while working on larger projects and running multiple sessions in parallel, I started to feel that I was getting overwhelmed, kept loosing track and sometimes different agents were working against each other. I tried to use worktrees but again I kept loosing overview cause I was trying to do too many different things at the same time.

I decided therefore to do something about it and considered building a solution for it. This is how I came to the idea of Lanes:

----

👉 https://lanes.sh

brew install --cask lanes-sh/lanes/lanes && open -a Lanes

----

Its described as a workspace to run multiple AI coding sessions in parallel while keeping a clear overview and staying in control.

I would appreciate your honest feedback, give it a try or comment below if you had the same problem and how you have been solving it.

• Does this resonate with you?
• How are you managing multiple sessions today?
• Why or why not would you be interested in trying something like this?

Thanks!

We have been building our new swarm methodology called “cyphers”, it’s out there in beta. We immediately hit real world problems that technology alone couldn’t solve. The biggest of which was how to effectively distribute work to 100 or a stretch goal of 10k agents all working to solve one task.

The idea seems simple enough, give a swarm of agents a common goal and set them lose. Ha well yeah in theory that sounds fun, in reality it’s a tad harder 😀 . To get anything meaningful beyond about 15 agents is not viable, not without some kind of leadership model. Oddly enough management challenges follows the same mechanics as an effective human leader in any task / job. Once you hit a span beyond 15 your ability to lead falls off. Honestly, if I had not seen the benchmarks I would have called bs but in any light I was very surprised to see the same was true with our early agent swarm mechanics. There are many other problems we had to solve first but this was the biggest philosophical challenge as it isn’t inherently technical. I’ll call out the other major problem, funds, I don’t know about you but 1 Claude agent loop is pricy 1k or 10k is not in our budget. Read on, we found a path.

How do you break down a common goal into a leadership hierarchy? One that operates reliably, consistently, securely, and respecting the chain of command regardless of the task at hand? That is shit that has plagued workforces and armies for years. Again very interesting in that a Claude sdk agent loop is kinda like a bratty teenager at times and doesn’t do what you want. To cut to the chase you have probably guessed by now we landed on military tactics and strategy, starting with rank and hierarchy, it is incredibly effective. Now we didn’t go full bore military, I am a huge fan of “tge art of war” and overall military tactics are a passion. However, don’t confuse the tactics and strategy with the political challenges in the military complex. Two very different things,

Every cypher starts with a goal and a max number of agents. Agents are what we call “jammers”. Jammers have apps both connected with mcp tools and RPa (our app is electron so you can build any automation as a skill using mcp or screen driven input), enhanced Claude skills (we add a deterministic layer on them to ensure they follow orders), model level, system prompt, and of course hardened guardrails. Our agents run in a bound security sandbox, beyond what the Claude code agent already does we had a prompt injection firewall to every single LLM prompt in the app.

The entire system is based on a draft concept applying our military heuristics. Each jammer has a set of skills, apps, and a model level. This allows us to leverage our primary agent with a very specific draft skill, using our customized skill runner, to rank and define the structure. Each draft results in different leadership structure, very cool to watch actually. I am at times more interested in the draft than the actual cypher output. The generals, then lieutenants, and so on get ranked and the units get built. Generally speaking, no pun intended, the draft agent chooses the opus level agents as higher ranking, we didn’t add that to the skill, but depending on connected apps and skills the draft is kind of legendary insight. Say you’re building a SaaS app, what agents rank where? Jammers with react skills and linked apps like stackblitz might rank highest as leaders. The swarm will leverage that app and skill to do some crazy shit. This becomes kinda of fun just on its own. I build jammers with very very specific skills / apps and the draft is sic.

The next major problem was how to distribute all of this work and how to break it down. The chain of command once again works beautifully. One agent can’t delegate work to 15 sub agents very well, our benchmarks show degradation around 12 and a true slip at 15 by 20 it is a shit show. Not all the time, but enough that it warrants at least one level of leadership. If we want to distribute work to 10k agents it would never work. Why not org structure? Why military? The honest answer? Scale and efficiency across any task. Orders are very different than requirements and that is what you are literally doing in prompts. You’re ordering the agent to do something and you expect a specific outcome. Technically, how do you aggregate the work efficiently without massive token burn was very challenging but again we fell to a proven backbone that’s another post.

The last major point worth noting is oversight and visibility “on the battlefield”. Again pulling from military tactics these agents can’t run on the same infrastructure so they are distributed. Each jammer may be on a single remote computer running .Yo (dot-you re: yosup.dev). This is how we beat the funds problem. Each participant is running Claude code deck agent loop inside our app, using your subscription login, so no crazy extra token burn. This is an easy way to “lend” your downtime to a buddies project. You can simple build a jammer than is set to x turns, c token burn, etc and they can build away with your agent contributing. In the big picture this will open the door to collaboration on a larger scale. But for those of us that don’t trust agents the cypher allows the mistro to become sort of a general. Each jammer remote box has complete control of their jammers. All prompts, usage, etc. you can jump in and direct them or help with prompts. You can also pull the plug at any time. Comms are all handled by our bus technology. Think game server meets agent swarm.

To sum it all up if your thinking about agent swarms or want to play around with our beta check it out. Military strategy seems to be a very very effective tool, it is for us anyway.

Most people try vibe coding once or twice and then quit.

Not because the tools are bad.

Not because AI cannot build good interfaces.

They quit because they treat vibe coding like a vending machine.

They type:

>“Make me a SaaS landing page”

And then expect something polished, original, responsive, animated, and production-ready.

That is not how it works.

Good vibe coding is closer to creative direction than magic. You guide the AI with clarity, references, structure, and small iterations. The best results come when you stop expecting the AI to guess what is in your head and start showing it exactly what you want.

Here is the process.

Step 1: Know exactly what you are building

Before opening Dualite, Lovable, Bolt, Replit, or any AI builder, get clear on what you actually want to build.

Not:

>“I need a website.”

Be specific:

• A SaaS landing page with hero, features, pricing, testimonials, and CTA
• A dashboard with sidebar navigation, charts, filters, and cards
• A portfolio section with project previews
• A mobile app onboarding flow
• A waitlist page for an AI product

Every type of project has different layout needs.

A landing page needs storytelling.

A dashboard needs hierarchy and usability.

An app flow needs states, navigation, and user journeys.

Before prompting, write 2 to 3 sentences describing the final result as if you were explaining it to a client.

Example:

>I am building a premium SaaS landing page for an AI analytics product. It should feel clean, modern, dark, and trustworthy. The page should include a strong hero section, product preview, feature cards, pricing, and a final CTA.

That becomes your foundation.

Step 2: Collect references before writing prompts

This is the step most people skip.

And honestly, this is where most of the quality comes from.

If you only describe what you want, the AI has to guess.

If you show references, the AI has direction.

I usually collect 3 types of references:

1. One reference for overall vibe Colors, mood, typography, visual personality.
2. One reference for layout How sections are arranged, how much spacing exists, how the page flows.
3. One reference for animation How things move on scroll, hover, page load, or transition.

Good places to find references:

• Pinterest for UI moodboards and visual direction
• Dribbble for polished interface ideas
• Behance for full project flows
• Awwwards for high-end website animation
• Codrops for interaction and motion ideas
• Mobbin for real app UI patterns
• Figma Community for UI kits and design systems

You can also use screenshots, rough sketches, or even photos of hand-drawn wireframes.

The point is simple:

Don’t make the AI imagine everything.

Give it the look, structure, and motion.

Step 3: Create a master prompt before building sections

This is where most vibe coded projects start looking messy.

People prompt one section at a time:

>“Make hero section.”

Then:

>“Add features.”

Then:

>“Add pricing.”

Each section comes out with a slightly different style, spacing, animation, or component treatment.

That is why the final page feels disconnected.

Instead, create a master prompt first.

The master prompt should define:

• Project type
• Brand name
• Visual style
• Color palette
• Typography
• Layout rules
• Spacing system
• Animation behavior
• Sections to build
• References
• What not to copy

A structured JSON prompt works really well because it removes ambiguity.

Example:

{
  "project": {
    "type": "SaaS Landing Page",
    "brand_name": "Nexus",
    "tagline": "Data clarity for modern teams"
  },
  "visual_style": {
    "mood": "Clean, minimal, premium. Confident without being loud.",
    "color_palette": {
      "background": "#0A0A0F",
      "primary": "#6C63FF",
      "accent": "#00F0B4"
    },
    "typography": {
      "heading_font": "Clash Display or similar geometric sans",
      "body_font": "Inter"
    }
  },
  "layout": {
    "structure": "Full-width sections, centered columns, max 1200px",
    "spacing": "Minimum 120px vertical padding between sections"
  },
  "animations": {
    "entrance": "Elements fade up on scroll with 0.3s stagger",
    "hover_states": "Subtle scale on cards (1.02), color shift on buttons",
    "page_feel": "Smooth and intentional, not bouncy",
    "reference": "[Awwwards URL here]"
  },
  "sections_to_build": [
    "Hero with headline, subheading, CTA, and product preview",
    "Social proof strip",
    "Features section",
    "How it works",
    "Pricing with three tiers",
    "CTA footer"
  ]
}

This becomes the creative brief for the entire build.

Now every section that follows has a shared visual language.

You can create this inside ChatGPT or Claude by saying:

>

If your vibe coding tool has a prompt enhancer, use that too. Write your rough idea in plain language, then let the tool sharpen it into a more technical and structured prompt.

Step 4: Be specific about what to copy and what not to copy

References are useful, but you need to guide the AI properly.

Don’t just paste a website and say:

>“Make it like this.”

That usually creates generic or overly similar output.

Instead, say exactly what the reference is for.

Example:

>Use this reference only for layout inspiration. Do not copy the colors, brand identity, images, or copywriting.

Or:

>Use this website for animation inspiration only. I want a similar smooth scroll feel, but the visual design should remain original.

Or:

>Use this screenshot as a structural reference. Keep the same information hierarchy, but adapt it for a fintech product with a darker, more premium visual style.

This keeps the output original while still giving the AI useful direction.

A simple structure:

• Reference 1 = visual mood
• Reference 2 = layout structure
• Reference 3 = animation behavior

Now the AI knows what to borrow and what to ignore.

Step 5: Build in blocks, not the full project at once

Do not build the whole website in one prompt.

That usually leads to inconsistent design, weak spacing, and messy sections.

Build in blocks of 2 to 3 sections.

For a landing page, this could be:

Block 1: Hero + social proof
Block 2: Features + how it works
Block 3: Pricing + CTA footer

Each block should reference the master prompt.

Example:

>Using the master prompt above, now build Block 1: hero section and social proof strip. Keep the same visual style, spacing system, typography, and animation rules. Make it responsive for mobile and desktop.

This gives the AI enough context while keeping the task focused.

Once a section is close, don’t regenerate everything.

Refine it.

Step 6: Use small, precise edits instead of restarting

A lot of people waste time because they keep re-prompting the entire page.

If the output is 70 to 80% correct, don’t restart.

Give smaller instructions.

Examples:

• Increase vertical spacing between hero and social proof
• Make the CTA button more prominent
• Reduce animation speed slightly
• Make cards less rounded and more premium
• Fix mobile stacking in the feature section
• Make the heading more editorial and less startup-ish
• Add more contrast between background and cards
• Make the pricing cards visually stronger

If the tool supports element-level editing or interact mode, use that.

Click the exact element and say what needs to change.

This is much faster than writing a long prompt trying to describe which part of the page you are talking about.

Good vibe coding is mostly iteration.

Small improvements compound fast.

Step 7: Take animations seriously

Animations are often what separate decent AI-generated websites from polished ones.

A static page can look okay.

But a page with intentional motion feels more premium.

Use references from Awwwards, Codrops, LottieFiles, or Rive.

But again, don’t just say:

>“Add cool animations.”

Be specific.

Useful animation terms:

• Entrance animation: how an element appears
• Scroll-triggered: animation starts when the user scrolls to that section
• Hover state: what happens when cursor moves over an element
• Page transition: how screens change between routes
• Stagger: elements animate one after another with delay
• Easing: the acceleration curve of the animation

Example prompt:

>Hero headline words should reveal upward with a smooth fade. Use a 0.08s stagger between words. Feature cards should fade up on scroll with a 0.3s stagger. Buttons should have a subtle hover scale of 1.02. Keep all motion smooth and premium, not bouncy.

This level of detail makes a big difference.

The full workflow

Before starting:

• Write 2 to 3 sentences describing the final output
• Collect 3 to 5 visual references
• Collect 1 to 2 animation references
• Decide what each reference is for
• Create a master JSON prompt

During the build:

• Build in blocks of 2 to 3 sections
• Keep referencing the master prompt
• Use small edits instead of full regenerations
• Fix layout, spacing, font sizes, and mobile views step by step
• Use element-level edits wherever possible
• Review animations separately

After the build:

• Check mobile responsiveness
• Check spacing between sections
• Check typography consistency
• Check CTA visibility
• Check loading and hover states
• Publish or export only after the whole flow feels consistent

Useful resources

Pinterest
For moodboards, colors, and general visual direction.

Dribbble
For polished UI sections and layout inspiration.

Behance
For complete case studies and full page flows.

Awwwards
For premium websites and animation references.

Codrops
For interaction ideas and motion techniques.

LottieFiles
For ready-to-use micro animations.

Rive
For advanced interactive animations.

Mobbin
For real app UI patterns.

Figma Community
For UI kits, dashboards, landing pages, and design systems.

Refactoring UI
For learning practical design fundamentals.

Final point

The people getting great results from vibe coding are not doing magic.

They are just doing the preparation most people skip.

One clear idea.

A few strong references.

One master prompt.

Small section-by-section builds.

Precise refinements.

That is the difference between a random AI-generated page and something that actually feels designed.

Got tired of alt-tabbing between my editor, terminals, and browser. So I built a Figma like canvas to work on with all my terminals, browser windows, and so on. Have been building with this setup for two weeks now while still adding to it.

It's open source so you can just run and build it yourself or use the prebuilt Mac/Windows/Linux version. Just try it and give me feedback on what's missing. Happy about some feedback or new ideas. Would appreciate if you drop a star.

Download here: https://github.com/0-AI-UG/cate or https://cate.cero-ai.com

I've released my first fully native iOS app in just 5 days.

Yes, I literally started building it last Saturday, and today I got an email from Apple saying it's approved and live on the App Store. Crazy to think, considering I'm a UI designer with zero coding skills.

My app is called Venty, it lets you share your confessions anonymously. You can download it here if you'd like to check it out:

Venty - Anonymous confession

Most AI tools help you write code. VibeKit does something earlier in the process.

You drop in an idea. It spins up specialized agents (Architect, Frontend, Backend, optionally Design/Marketing), extracts requirements, defines system boundaries, and generates a full project workspace — CLAUDE.md, AGENTS.md, ARCHITECTURE.md, TODO.md, the works. Download the zip, open Cursor or Claude Code, start building.

No code generated. Just the context layer that makes AI coding actually work.

What just shipped:

• Full mobile experience with swipe navigation and a read-only editor (all edits go through the AI chat, so changes stay traceable)
• VS Code-style syntax highlighting in the editor
• Token-level AI streaming — fixed a buffering issue where responses were arriving in batches instead of token-by-token
• Onboarding tours for both desktop and mobile (fires once, then never again)
• Fixed a quota bug where stack recommendations were silently eating from your daily generation limit
• Bunch of mobile layout fixes — sticky nav disappearing on scroll, dropdown z-index clipping, duplicate loading screen elements

Still early but it's live and free to try: vibekit.doodle2dollars.com

Curious what context files you're currently setting up manually. Happy to compare notes.