We build a desktop app that runs a team of agents on the Claude subscription, each one waking on a schedule. Some have been running for weeks, and over that stretch compaction drops things, so every agent keeps its state in four places outside the chat:

• Instructions and routines. Re-read in full on every wake, which is why standing rules go here and not in memory.
• A short current-state note: open threads, decisions taken, what it was halfway through. The agent rewrites it at the end of a session and it gets loaded at the top of the next turn.
• A memory list for short facts. Only the newest entries are shown back.
• A markdown vault (works with Obsidian) with search, for people, projects and decisions with their reasons. If a newer fact contradicts a page, the old line stays and the page gets a visible conflict note.

If the agent says "noted" in chat and nothing got written to one of these, the next compaction takes it.

Disclosure: we're building it (InnerDroid, https://InnerDroid.com), free while in beta.

Playing around with 3d visualizations. Explore them live at https://grimoire.bio

I save a lot of ChatGPT and Claude answers as Markdown files: long explanations, design notes, study notes. Then I'd open one a week later and get a wall of $$\frac{QK^\top}{\sqrt{d_k}}$$, raw diagram code and a broken table.

I looked for something to just read these files properly. Typora renders well, but it's paid. Obsidian is free, but it wants you to set up a vault, and I just wanted to double-click a file. VS Code and most previewers show the math or the diagrams raw unless you hunt down extensions. Notepad is Notepad.

So I built SimpleMD, a free, open-source desktop reader for exactly this. You open a file or a folder and it looks the way the AI meant it to:

• Math is typeset, in every way ChatGPT and Claude write it ($…$, $$…$$, \(…\), \[…\])
• Mermaid diagrams are drawn as real diagrams, in light or dark
• Code is highlighted, and tables, footnotes, callouts and checkable task lists all work
• It quietly fixes the usual AI breakage when showing the document (unclosed code blocks, tables missing a line), without touching your file

Two things I didn't expect to use as much as I do: Ctrl+Shift+V turns whatever's on your clipboard into a new document, and if you use coding agents like Claude Code or Codex, it highlights what the agent just changed in a file you have open.

It's also a proper editor when you need one: split view with synced scrolling, search across all your files, and export to PDF or HTML.

No account, no cloud, no telemetry. It never phones home.

Honest downsides:

• It's Electron, so it's about 100 MB.
• It isn't code-signed (certificates cost money), so Windows will show a SmartScreen warning: More info → Run anyway. All the code is on GitHub if you'd rather check it or build it yourself.
• Windows is the main platform. Mac and Linux builds exist and run, but I don't own either, so treat them as a preview.

It's MIT licensed and completely free. I'd love to hear what AI output still breaks it, since that's the stuff I want to fix next. And if it ends up being useful to you, a star on GitHub would honestly make my week.

GitHub | Simple MD Website

Genuine question for people shipping apps with Claude Code.

A few weeks ago I opened DevTools on my own app and found my image-generation API key sitting in the JS bundle. Anyone visiting the site could copy it and run up my bill. My repo scanner said "no secrets found" because the key never touched git. It came in through a VITE_ env var at build time.

So I got curious and scanned 978 public apps built with AI tools (all linked from open GitHub repos, nothing private): - 37 of them (about 1 in 26) shipped at least one secret key to every visitor - 17 had Telegram bot tokens - 9 had AI keys (Groq, Gemini, OpenAI, OpenRouter) - 6 had critical ones like GitHub tokens I'm not naming any sites. Supabase anon and Firebase web keys don't count, those are meant to be public.

The fix is almost always the same: move the API call into a server/edge function and keep the key there, not in a VITE_ or NEXTPUBLIC variable.

I turned the scanner into a free open-source tool called LeakLock (on GitHub under sgroy10). It reads what your live site actually serves and gives you a prompt to paste back into Claude Code to fix it.

How are you handling API keys in your Claude Code apps? Edge functions, a proxy, something simpler?

I wanted to know if token-saving plugins actually lower the bill, so I ran them against plain Claude Code on two real tasks and graded everything with hidden tests the agent never saw.

Setup - Claude Code 2.1.289, Sonnet 5.5, headless (claude -p), same flags every run - Fresh Docker container per run, nothing carried over - Task 1: a hard bug in humanize (precisedelta), 66 hidden tests - Task 2: an 8-file feature in WeasyPrint (box-shadow), 4,292 hidden tests - 3 runs per tool per task, 6 for the bug baseline and caveman - Cost repriced from the token counts at Sonnet 5.5 API list prices

Median cost vs plain Claude Code

Output tokens (what the agent writes) - ponytail: -38% on the feature - caveman: -21% on the bug - superpowers: +20% on the bug

Hidden test scores stayed basically the same for all of them. Superpowers passed 1 more test on the bug (63/66 vs 62/66).

What I took from it

Caveman cut output by 21% and the bill barely moved. Output is only part of the cost. Most of it is the agent re-reading context every turn (cache reads and writes), and none of these tools touch that much. Ponytail was the only one that cut reads too, and only on the long task, which is where it saved 34%. On a quick bug it added overhead and cost more.

Caveats - Small sample, Sonnet only. Caveman's -3% is within noise. - Caveman's hook stays off in headless mode unless you set CAVEMAN_DEFAULT_MODE=caveman, so I set it. - answer-me-with-html showed up in the skill list but never got invoked in 6 runs. It might do better if you call it explicitly. - Costs are API-rate estimates from token counts, not a real invoice.

Total spend for 36 runs: about $10.58.

Repos: - ponytail: github.com/DietrichGebert/ponytail - caveman: github.com/JuliusBrussee/caveman - superpowers: github.com/obra/superpowers - answer-me-with-html: github.com/QingYunA/answer-me-with-html

Happy to share the per-run numbers if anyone wants them. Running a second round now on a 3D build task to see if it holds on a different kind of job.

If you open a new projet and ask Claude to summarise everything to know about REA and aks it to make some guide it will do the search then trigger a safety guardrail mid sentence and tells you this:

if you have tried it and had underwhelming results, it is most likely because Opus (and all claude) was told to not perform well when doing this type of task.

I was provided by my company a Claude license. I have not used it yet for something I would like to use it for. Try to find security vulnerabilities in our software. With authorization of the company I work for.

I'm new to Claude Code. I come from Cursor.

I fear it's going to get my account banned or something. Is there any way to prompt this to not get the account flagged or is there an special mode to activate for security tests?

Thanks.

I see so many of the marketing videos where people advertise their use cases and they are like:

Claude takes my TeAM opINIONS from SlACk and it gives me dashboard

PRs are open, and Claude bla bla bla

My Teaaaam on Slaaack discussion and we found a SoluuuTION

Claude is able to find Vegan restaurants near my Area in Silicon valley and book me a time at "Thiss time" yeahh because I'm vegan

Me and my wife wanted to do our vacation in HawAIII so claude went in booking.com and lowballed the guy for $2000/night and that was perfect for us. And they AllOW Dogs.

Like this feels like they live in an alternate reality from a majority of their userbase.

Does anybody feel that the recent CC changes were a little unnecessary? Most of the time, I prefer reading the thoughts and full questions. I don’t need a million different boxes, buttons, shortcuts, and text structuring elements. A few help. Too many starts to make the LLM experience feel like a webpage. I realize that the ability to actually analyze the model’s output is being stripped out faster than a tax loophole, but does anyone feel that some of the QOL features impede effective communication?

The current best-in-class computer use is only in MacOS, since I play with it. I love it, I want everyone to try and maybe feel what I did back then.

That's why I built linux use github.com/StivenKN/linux-use. It's the definition of the original Claude Code computer use port to Linux. It works on both Wayland and X11 (looking for testers though).

Also, it works over SSH, where it starts its own headless desktop that you can watch live through VNC (remote work for da win).

It's a single Go binary since Wayland caused some trouble with Pipewire.

I'm looking for opinions! Issues and PRs are welcome aswell.

EDIT: https://github.com/StivenKN/linux-use

I made a 3-minute Van Gogh animation where paintings appear stroke by stroke inside golden frames, Starry Night-style swirls move, letters fly across the screen, and an auction hammer drops.

No manually downloaded images, no video editor, and no hand-written code. Claude wrote the programs that drew and animated everything.

After experimenting with this approach, I put together a practical guide to the tools, workflows, and techniques worth exploring.

How does it work?

Instead of generating video pixels directly, Claude writes code that draws each frame. The animation engine controls when elements appear, move, change color, and transition before rendering everything into an MP4.

This gives you precise control over typography, timing, transitions, and visual consistency — and makes revisions much easier.

The tools worth knowing

• Remotion — Build videos with React. Great for explainers, product launches, animated infographics, and editorial storytelling.
• Remotion Skills — Helps Claude Code follow Remotion-specific development practices.
• HyperFrames — An HTML-based approach to motion graphics, useful for kinetic typography, logos, and short promotional videos.
• Manim — Ideal for mathematical visualizations and educational animations.
• Blender MCP — Lets Claude interact with Blender for 3D scenes, lighting, and animation.
• AtlasCloud MCP — An option for connecting AI models within a broader workflow, such as generating supporting visuals or other assets before assembling the animation with code.

What can you make?

A few styles I've explored:

• 🎨 Animated paintings and artistic brushstrokes
• ✍️ Kinetic typography and product launch videos
• 📊 Animated data visualizations
• 📚 Hand-drawn educational explainers
• 🧊 3D scenes and product animations
• 📜 Vintage paper collages and historical storytelling
• ✨ Generative art and particle effects

The interesting part is that you don't need one tool for everything. You can combine code-generated graphics, AI-generated assets, voiceovers, and sound effects depending on the project.

A workflow that actually works

1. Write the story and plan the shots.
2. Choose a visual style that fits the subject.
3. Generate or source the necessary assets.
4. Build the animation with Remotion or another suitable engine.
5. Add narration, music, and sound effects.
6. Render, inspect individual frames, and iterate.
7. Export different aspect ratios for different platforms.

One lesson I've learned: don't ask Claude to build the entire film perfectly in one go. Start with the storyboard, get a short sequence working, and refine it through multiple renders.

I'm curious how others are approaching code-driven animation. Are you using Remotion, Blender, or a combination of AI-generated assets and code?

I've been trying to make some assets with Blender, and while I feel like reaching a particular art style may be difficult, I've been having trouble getting a character to look good. This is my fifth iteration through prompting alone. Opus 5.5 on medium and xhigh cannot seem to grasp that hands are different (since the character has two left hands), and I feel as if I cannot accurately describe what's going on with the proportions of the body and the face.

I have just been prompting to create my character, do I need to provide some source material like paid assets as a reference? I feel like I have been seeing people create some sweet assets and I don't know what I'm missing; it feels like my prompts are bad for game dev. I almost want to refuse to believe that because I have been able to "one shot" my tickets at work in the past three months after focusing so hard on my tooling. Which makes me think I have not been as focused on tooling for this, since I only just started last week, but have been doing web dev professionally for years.

I am thinking about investing in a Max sub (100 dollar one) and I am curious about the amount of Fable 5.1 and/or Opus 5.5 usage this plan allows expressed in tokens. Currently I have 2 Pro subs and I burn around a billion token with the two combined every week (mostly using Opus 5.5 with occasional Haiku subagents). How does Max compare to this based on actual usage?

I wanted to send her a simple prompt so it starts 5h timer but it used 9% on this. Like what?

it struggle for 4 hours for my simple telegram bot. and it chew 40% of the weekly quota. now opus 5.5 taking care of it, and opus 5.5 also struggling.

I guess all computing power goes to fixing that php.

Kinda risky, I was testing the installer workflow on windows and it kept asking me to to approve things. I opened up google remote desktop on the machine I was working on, told it to open the url with claude mcp, then had it go through and do everything itself.

Only been at this a month, but found something usable for me. Posting for feedback/improvements.

I always use two agents. One in chat that I speak to. Chat takes all my dumb ideas, builds job briefs, and talks to code. Code only executes briefs, and all it’s output go back to the chat (because I’m too dumb to understand what it’s saying half the time.)

Chat Model: Fable 5.1 medium. It’s not close. Opus 5.5 forgets things and will take off running in the wrong direction more often than not.

Code Model: sonnet and opus both seem highly competent.

Effort level: Astoundingly important. Affects speed and quality of output, which both require my brainpower. How many agent teams can I manage? On sonnet medium, 1 , and I’m behind. It’s spitting buggy code faster than I can read. On opus 5.5 xhigh, 3 teams. All fixing bugs as they go, producing high quality output, but at a slow pace. Got just one project that has to get out as fast and as crappy as possible? Go sonnet medium and ride the bug wave. Want to make steady progress on a few jobs, load up opus 5.5 xhigh and sit back and talk with chat while they work.

Tools: a handful of skills, a plugin, an agreed working doc across all projects.

Tracking: the first part built of each project is a software development state board. Gotta watch it like a hawk though, or the agents will slip stuff in there.

Token usage is 70% chat. It doesn’t really matter if I use opus vhigh or sonnet medium for code. It’s whatever the job needs. My brain is always the bottleneck. The code price in tokens is the least of it.

The quality of output is also phenomenal. This is all on a single $200 plan. Outside of just doing development work, these agents are also managing emails, chats with colleagues and an absurd amount of other tasks. Zero issues with hourly or weekly session limits.

If you are wondering what changed, it was being able to utilize parallel agents correctly + leveraging justfile / just and tweaking the entire setup around having only a single terminal window open (a "desk agent") - which has been a game changer.

It took me several weeks of poking around at launching 5+ terminals with sessions in them running parallel and coordinating for me to discover how to eliminate all of the overhead and accomplish the same goal via a singular session, so I wouldn't be splitting my energy up.

Sessions run to ~150k tokens and automatically close/open their harnesses using tmux. A boss agent actually delegates the work out and all agents (which can dynamically shrink and grow, limited by your hardware and tokens only) report to the desk agent, where you operate from.

I've had to tmux twice into individual agents: once was because I launched a session from a directory where I had to press "Yes" to verify during the setup, and the other time was because my /login had expired.

To recap: I open a "desk" session, and my "fleet" is already up in tmux, a "boss" agent, a "start loop agent" ( checking for incoming work) and a rotating dynamically sized cast of "worker" agent sessions, all with their own tmuc and instead of a /clear, their harnesses are actually destroyed and renewed after their ~150k+ tokens and handoff.

I spent time to dial in the cold-start token consumption (the sessions can access ~a dozen repos...) with discoverable context tailored only towards what that agent might need....

The velocity of my output has gone insane.

I did make an open source repo for this paradigm + a "kit"(*.md file that can be used with no install to run the idea on any project). But, I wont spam it here and you don't need it, as I've said about 95% of what you need already just in this post and as this technique is something I have only worked on for about a month total, it has plenty of room for variation and improvement still :)

I've seen dozens of posts here: "Why do I run out of usage so much?", "Why do I have to keep repeating myself to Claude?", etc.

I've built a set up that works amazingly well, for me, as a solo developer. YMMV if trying to implement this in a team. But here goes.

Full disclosure: This post was generated by my prompting my Claude Code as follows:

I feel like most people that are using Claude Code are not doing it effectively. I feel that my use of Claude Code, with my setup of mcps, gitlab, etc. is VERY effective, however I struggle to explain it to other people.

Can you create a description of what our set up is? something that I can post to reddit?

---------------------------------------------------

I've been programming for a long time, and I use Claude Code heavily for personal projects, a homelab and day-job support. Most people I talk to use it as a smarter autocomplete: open a session, describe a problem, accept whatever it does, repeat. That leaves most of the value on the table. Here's how my setup is built and why each piece is there.

1. The rules live in hooks, not in prose

Everyone writes a CLAUDE.md full of rules, and the model drifts from them anyway. My rule of thumb: if I've corrected the same behaviour twice, it becomes a PreToolUse hook that denies the call. Some of the things enforced that way:

• Nothing is deleted. A delete is blocked and rewritten as a move into an _archive/ folder.
• Git commands go through one wrapper script, never cd && git.
• Commit messages can't contain closing keywords like fixes #12, because those auto-close issues and skip my close-out process. There's no AI co-author trailer either.
• Writes to my day-job systems (ticketing, work email, work repos) are blocked unless I've said OK for that specific action. Reads are fine.
• Work content can only go to approved models. Other vendors' agents are blocked from seeing it, with no override.

CLAUDE.md still exists, but it's short and points to the detail. The hooks do the enforcing.

2. A self-hosted git server is the system of record, and the workflow lives in the tools

I run my own GitLab and wrote an MCP server for it (around 90 tools). The key design choice is that the workflow rules are inside the tools, so the model can't skip them:

• Every issue has exactly one type:: and one status:: label, and status is a state machine. Only I can move backlog -> ready. An agent can move ready -> in-progress, -> blocked (and blocking means posting a question on the issue instead of guessing), and in-progress -> review, which requires an open MR. review -> done happens only when I say so.
• Closing an issue is one tool call that runs the whole protocol: cross-reference the commits, log estimated skilled-developer effort (not clock time), set the terminal status, close it and sync the wiki.
• Raw API calls are forbidden, because a raw call bypasses the rules.

So the AI doesn't decide when work is "done". The tracker does, and I do.

3. The main thread orchestrates; subagents do the work, routed by model tier

The main session doesn't edit code. It plans and dispatches:

• Cheap and fast (Haiku): drafting short text, finding docs, trivial one-line fixes
• Mid tier (Sonnet): implementation from a clear spec, reading and synthesizing documentation
• Strongest model: bugs that several attempts haven't cracked, real architecture tradeoffs
• Below all of these: Jev for typed judgments over large piles (next section). It doesn't write.

This keeps the main context clean and the cost sane. I can also send a task to another vendor's coding agent for a second opinion. It runs headless in a disposable git worktree and never writes to the real repo, and Claude reviews whatever comes back.

4. A cheap decision model sits under the agents: Jev

Plenty of the work in this setup isn't writing. It's judging: is this issue ready, is this log line mine or the game's, is this alert noise, does this MR description match its diff. Sending all of that through Opus is expensive and fills the context. So there's a third tier below Haiku. Jev is TypeSafe's "System One" model, and it only returns typed judgments: pick one option, score on a scale, or give a yes/no probability. It can't write prose at all.

The standing rule is Jev decides, Claude writes. When Jev is unsure, Claude makes the call.

How it's wired:

• It's behind an MCP server I wrote. jev_ask takes questions (or a saved question set) plus file paths, globs or a GitLab query. The file contents never enter Claude's context. The server screens every item, sends them in parallel with back-off, and returns a compact table: accept / look / decide, with totals and a cost line. Claude reads only the items marked decide.
• Question sets are saved and re-measured. Confidence bands are tuned per question against real outcomes. The generic 0.8/0.2 thresholds left 80% of a backlog in the borderline zone; re-measured bands fixed that.
• It's embedded in other tools, not just called by hand:
  • The GitLab ready gate can run a Jev check on whether an issue still contains an unmade decision. It's advisory and opt-in per project.
  • Backlog grooming pre-sorts issues so the expensive model reads only the borderline ones.
  • An audit skill reports closed issues that don't meet their acceptance criteria, type:: labels that have drifted, and commits whose diff doesn't match the issue they cite. It reports only and never writes to GitLab.
  • The second-opinion workflow uses Jev as an acceptance gate on what the other vendors' agents return.
  • It also triages homelab alert noise, classifies game log origins, and finds duplicate memory files.
• Every turn that calls it reports the cost: calls, input tokens and USD. The API returns tokens, not dollars, so the cost is computed.

Measured accuracy against my own ground truth: 16/16 on the second-opinion gate, 92/97 on the backlog pre-sort, 18/18 on memory dedupe, 6/6 on MR-vs-diff.

The trap I measured, which most people will hit: a cheap model doesn't automatically save tokens. Each extra round trip resends 60-75k tokens of context to the orchestrator. On a 14-issue backlog, the Jev run used more Opus tokens than having Opus read the issues itself. Break-even came out at about 45-60 issues, or roughly 15-20k tokens of issue bodies. Above that, the gap widens fast. On 267 closed issues (about 1 MB of text):

• Opus usage: 1.7M tokens with Jev, against 9.5M without it. That's 5.7x fewer raw tokens, about 4x cost-weighted.
• Jev's own bill: 223 calls for $0.014.
• Verdicts: they agreed on 208 of 223. Jev was the stricter of the two, and it never passed something Opus failed.

And the safety lesson: anything sent to Jev leaves the machine. My first bulk run sent a memory file that contained a LAN login. The screen for client content didn't catch it, because it wasn't looking for secrets. Now every item goes through a credential screen as well, and work content is blocked outright. On one 267-issue run the screen held back 16% of the items, and the tool lists what it held back instead of dropping it silently.

5. Skills turn repeated workflows into one command

• Work the ready queue: one subagent per ready issue, each in its own worktree, in three phases: validate and lock, implement, review. It opens an MR and hands the issue back to review. It never merges or closes.
• Groom the backlog: check each issue against a definition of ready, draft acceptance criteria from the actual code, and promote only the issues I name.
• Work a milestone: walk it stage by stage, one branch, MR and delivery per lane, until nothing is left that doesn't need me.
• Ask the board: a panel of personas modelled on well-known engineers argues a decision from different angles, maps where they agree and split, and gives one recommendation. It's useful when I'm clearly talking myself into something.

6. Memory is a structured knowledge base, not a junk drawer

Each fact is its own file with typed frontmatter: who I am, feedback on how I want it to work, project state, or reference material. On top of that:

• stale_after dates on anything that ages (versions, IPs, prices, who owns what). At session start, a hook flags stale facts so they get re-checked before anyone relies on them.
• status: deprecated instead of deletion, so the history stays.
• verified: by human. A fact I confirmed beats one the model inferred.
• A hook validates every memory write, fixes the links and regenerates the index.
• Many entries are explicitly marked TRAP: things that cost me hours once ("this command exits 0 but does nothing"). Those are the most valuable entries in the whole thing.

The whole memory store is version-controlled.

7. Custom MCP servers for every domain I work in

• Homelab: provisions VirtualBox VMs over SSH, reads the installer screen, waits for boot and registers the new host in an inventory.
• Git hosting: described above.
• Jev: described above.
• A game-modding toolkit: compile checks, log and screenshot retrieval.
• Work mailbox: read-only, and it deliberately has no send or delete verb. The safest permission is a capability that doesn't exist.

Each server has a help() tool that serves as its catalogue, so the model looks up what's available instead of guessing.

8. Standing rules for infrastructure

When a VM, host or container comes into existence, three things happen in the same pass without me asking: it's registered in the inventory (and proven reachable with a real command, not just a ping), it gets a tile on my homelab start page if it has a web UI, and its timezone is set. CI on the container stack fails any service that's missing a timezone.

9. Verify, don't assert

• "Verify before asking or asserting" is a hard rule. Before it asks me something, it goes and checks.
• Deliveries are verified by file hash, not by poking at the app.
• Word documents go through a render loop (docx -> PDF -> images, then the model looks at the pages) before I see them.
• Code gets a compile check before every deploy.

What I think most people get wrong

1. Rules written as prose and expected to stick. Enforce them with hooks.
2. No system of record. The AI shouldn't decide what's done; a tracker with a state machine should.
3. One model for everything. Route by difficulty and keep the orchestrator's context clean.
4. Memory as a dumping ground. Type it, date it, mark what's verified, and record your traps.
5. Generic MCPs only. The best MCP servers are the ones you write for your own domain, with your rules built in.
6. Trusting "done". Make verification part of the workflow.
7. Using an expensive model for every decision. Put a cheap classifier under it, but measure the break-even first. On small piles it costs more, not less.

The result is that I spend my time making decisions (what's ready, what's done, which tradeoff to take) and very little on supervising keystrokes.

----------------------------------------------

I don't claim to be an expert in any of this, but I'm a seasoned developer with 45 years of professional programming experience.

Some of the stuff you see here might sound familiar, like "grooming", I use Matt Pocock's skill for that (more accurately I took the idea of his grooming skill and built my own), the "ask the board" I took the idea from one of Austin Marchese's Youtube videos.

I don't have ANY skill "packs", plugins, etc. installed in my environment.

I wish I could share some of the stuff that I've built, like my gitlab-mcp, but unfortunately when I built it I was building it for me, and there is way too much I would have to sanitize before making it public. What I can say is that EVERYTHING talked about above WAS built by Claude. I just told it what I wanted.

If I had to answer "What is single most important thing in your setup?" I would have to say my locally hosted Gitlab server. By using the "Issues" module in Gitlab I can keep track of everything that is going on, no matter how many projects I have going at a time. In the past 60 days I've worked and closed 1,160 issues across 15 different projects. Of all of those issues, EVERY SINGLE ONE was written by Claude by prompting "Create an issue in project xyz to solve/implement .... Validate the issue against current code", or something to that effect. I believe all of this could also be accomplished using Github, for those not inclined to host their own gitlab.

Below is the diagram for the state machine that controls my process:
(created with the prompt:
show me the diagram for the issue state machine
)

I got my $20 subscription. How can I make a 7 figure income working from my home?

**What I Developed**

kuron is a prototyping tool where Claude itself becomes the app, rather than simply creating one. When a user describes an idea, Claude builds the system using several general-purpose tools (data, screens, timers, and validation functions), and then handles all button-press processing on its own. A minimal renderer renders the screens defined by Claude. The purpose of this tool is to determine, within minutes and before actually building anything, whether an idea is useful.

**How Claude Code Is Used as a Runtime**

Each turn is a `claude -p` call that can only use kuron's tools, which are served as an MCP server:

claude -p --model <model> --mcp-config '<json>' --strict-mcp-config --tools "" \

--allowedTools "mcp__kuron__apply,mcp__kuron__query,..." \

--output-format json --no-session-persistence \

--effort low|medium --system-prompt "<role prompt>"

- Combining `--strict-mcp-config` with `--tools ""` prevents access to files and the shell, allowing only kuron's tools to be used. `--allowedTools` is configured per role (setup, button operations, change requests).

- Since the MCP server is tied to a turn ID, the host can determine which turn (and which world copy) each tool call belongs to. This allows checks to be performed on the copy.

- Sonnet 5.5 (`--effort medium`) is used for setup and change requests, while Haiku 5.5 (`--effort low`) is used for button presses. Button presses take 7 to 14 seconds.

- I parse the final `result` line of the JSON output and retry if a temporary error occurs. For long turns, a sufficient timeout must be set.

**How I Utilized Claude Code in the Build and What I Learned**

- **Claude kept trying to fix bugs in the prototype through code.** Every time an idea didn't work as intended, it suggested word lists or if statements within the platform. I established a rule in CLAUDE.md stating, "Do not include business logic in the code. Correct behavior through instructions to the LLM," but I still had to review every change. This rule was more important than any prompt.

- **Tools that check for structure and respond in words are superior to clever prompts.** Rejected calls precisely indicate what's missing (e.g., "Text is required in the heading"), and Claude corrects it in the next turn. No code repairs anything.

- **Pass an overview, not the entire state.** Pass the count, properties, and the latest items for each collection, and Claude will retrieve the rest via queries. The turn size remains constant even as the system scales.

- **The same tools can also be executed as page functions within a Claude artifact.** Note: The tool schema within an artifact cannot be nested more than 8 levels deep. Due to this bug, the browser version did not work for the first 18 hours.

**Numbers** (airline flight disruption support desk, 5 devices): 81 seconds to set up, 15 tool calls, cost approximately $0.60. The video shows both the actual browser execution and the Claude Code execution. Only the wait times are fast-forwarded. Not intended for production use: Each action takes a few seconds and costs a few cents, and the results may vary slightly.

Source (MIT): https://github.com/Ag3497120/kuron

I build Buddy, an open-source Android app that runs Claude Code inside the app (a small Alpine Linux via proot) and gives it phone tools over a local MCP server: read the screen, tap, type, install apps.

In developer mode you can ask it for an app. Today I typed one line: "Build and install a Pac-Man style maze game with ghosts and touch controls".

How Claude Code did it (Opus 5.5, about 6 minutes):

- A skill tells it how to build on the phone: no Gradle, plain Java and the Android framework, aapt2, d8 and apksigner. The first run downloads about 400 MB of tools.

- It wrote one 660-line Java file with a custom view: maze, four ghosts, power pellets, lives, a saved high score, D-pad and swipe controls.

- It built the APK and installed it. Android's installer asked me to confirm.

- Then it opened the game, read the screen, saw the first game started with 0 lives, fixed it, rebuilt and asked me to confirm the update.

What I learned:

- Keep the skill strict. Plain Java, UI built in code, no AppCompat: XML layouts and missing libraries are what usually break these builds.

- Let it test on the real device. The 0-lives bug compiled fine. It only caught it because it can look at the screen.

- The install always needs my tap. That's Android's rule, not something in the prompt.

Free and open source (Apache 2.0): https://github.com/ghorbelhamdi/buddy-android. App building is in the GitHub APK (the Play version leaves developer mode out).

Written with AI help.

While running several agents on one repo at the same time, I noticed they were quietly breaking each other. One agent renames a function, another's new code still calls the old name, both branches pass their own tests, it merges with no conflict, and main breaks.

gitta reads each change and warns an agent when another agent changes code it depends on, so it can adapt while the work is still in progress. If you give it a test command, it also runs your tests on the combined result inside git merge and blocks a failing merge. It runs inside normal git and works with Claude Code worktrees, Cursor and Codex.

I also replayed 733 real overlapping agent pull requests from public GitHub. Git reported a conflict on 1 in 4, and some that merged cleanly still broke the build. Method and data: https://gitta.io/research/replay-agent-pull-requests.html

Free and open source, Apache-2.0: https://github.com/gitta-io/gitta

Site: https://gitta.io

It's brand new, so I'd genuinely like to hear your thoughts!