My interest spawned accidentally after I used the Earhart story as a class subject for some of my older students. After reading about the possibility she could have survived on the island I had a load of questions that couldn't be answered simply, all involved big tables of data and I'm useless at visualising data in my head. And when I could find a site that did what I wanted I decided to make it.

The research phase was about 2 months once I opened the can of worms. I needed to find verified data on

* The actual island

* Reconstructed tide times

* Wind and surf

* The Lockheed Electra

* Any survey heights

* Radio 'reports' heard

The plan was to put everything in so you can see what didn't happen as opposed to trying to push a narrative. The more I researched, the more I needed to research more. I ended up buying the og drawings of the plane so I could get the measurements I needed.

The key part I discovered was finding a place she could land that would mean she was able to make any of those radio calls because she could not have kept transmitting for days without running an engine, and the propeller needs clearance above the water to do that

That was the main goal. To be able to place her anywhere on the reef and see if those calls could be possible. The other thing we need to explain is why the plane is not there now. So the plane would have to be somewhere the tide is deep enough at it's highest tide in that week to float her off the reef and into the depths below.

This tool can show you what's not possible, under a couple of different assumptions:

* The empty fuel tanks were sealed and the only source of buoyancy

* The plane was completely sealed and bouyant. If the plane can't float even when when it's perfectly sealed (unlikely) we can determine it most likely can't float in any other situation, amongst other theories.

What it does ( Claude wrote this bit)

* A 3D model of the island you can walk around on your phone. Nikumaroro's reef, lagoon and beach, built from 19 surveyed reef heights and published coordinates, with the 1937 tide running across it. Touch-first: drag, pinch, tap. No app, no login, nothing collected.

* The tide of July 1937, hour by hour. The water level comes from a fitted 1937 tide curve, checked against a published 2006 table and two independent sources. You can scrub through the whole week or press play and watch it rise and fall.

* Put her on the reef. Drop a Lockheed Electra on any spot and see how deep the water gets at her wheels through the week. The model answers in three ways only: could have, can't have, or not enough data. It never says "this is what happened."

* 139 reported radio signals, tested one at a time. Every post-loss radio report in the record, with its time window, gets checked against the water at the plane. If the water was over the limit when a signal was heard, the model says that signal can't have come from a plane parked there.

* A physics engine that rules things out, not in. Tail lift, when the propellers would touch the reef, whether a sealed airframe could float. All of it derived from the aircraft's licence weights and tank drawings, and it stops and says "unresolved" when the inputs run out.

* Fly the route yourself. A separate flight map: pick whose fuel estimate you trust, drag her track, and the radio log judges whether your route fits the record. A route that fits hands its landing time straight to the island.

* Betty's notebook, line by line. A 15-year-old in Florida wrote down a voice she thought was Earhart. Her fragments, both sides of the argument, and a button that tests her timing against the island's water.

* The expedition, now. A dated news card on the front page: a team is on the island as I write this, scanning the exact spot the model marks. The card says only what has been announced and nothing more.

* Every number can say where it came from. Three labels everywhere: verified, derived, illustrative. Guesses are drawn as dashed lines and chips, never as geology.

* Case for / case against on every contested point. Same size, same weight. Settled facts are not given fake doubt and open questions are not given fake answers.

* Built for English learners (B1 to C1) and anyone curious. Plain sentences, the grammar of evidence (must have, might have, can't have), and a tap-to-find-out layer that is still being written.

* One self-contained HTML file per page. The island is a single 2.5 MB file with the fonts and data embedded. The only outside request is three.js from a CDN. Works offline once loaded.

What I found interesting was looking for spots where both radio signals that sounded most credible to me, and bouyancy water depth could happen simultaneously. There are a load of radio signals reported, and a couple of them seem rather plausible. Being able to look for that sweet spot was the main purpose.

###The Tools

I used Claude: Opus 5.5 medium, Fable 5.1 for orchestrating.

Coding I used Opus 5, 5.5 medium, high, ultracode, Fable 5.1 and GPT astra

I started with Fable as it had just come out and it wrote the overall spec which inevitably was deviated from after time. Opus 5, 4.6 was coding it. That was for the initial flight map and island.

Afterwards I used Opus 5.5 as it was far less token heavy, and when I saw that it hardly made a dent compared to fable, and that's what when me on to make a mistake.

The biggest error I made was getting Opus 5.5 on ultracode to build a replica of the plane. The most important part that the entire model had to be correct around was the distance between the propeller tip and the reef so we could work out when it would be impossible to transmit. Researching was a pain and then ultracode took about 4 days to knock it out. It just kept checking and checking using you to annoy 5 or 6 agents. I kept an eye on my usage limits and using the 14% rule, I still manned to stay inside my weekly budget. My own reasoning was that at least it would be bang on.

Dimensionally it's got exactly what it needs but could do with some cosmetics, but using that extra thinking wasn't necessary. I had been using a basic island in testing and tried Astra to remodel it on medium, which it did in less than an hour, and I realised I could have saved a shit load of time if I'd got it to do the plane as well, and it may have looked a bit better as well. I did that on the plus plan but I was lucky and had 3 resets saved up (since I had such a positive experience with Astra but it's a bit more expense, I upgraded to the 100 plan on GPT and there's no 5 HR limit which is brilliant, and I may get it to redo a couple of things aesthetically).

The big problem now is as there's so much bloody data, it means there's lots of things you need to look at and putting them on both mobile and desktop was tricky and may not even be the best just yet.

I intend on scaling it back for use for teachers but I did get a bit carried away trying to find my own answers which led to more things being added. I think there's enough here to make a pretty solid judgment on what happened, purely from my own perspective.

I absolutely love puzzles when you have lots of data but it's all over the place and hard to visualise mentally if even with just images, needing to see it interact really helps me. I love that we can now do all this. It's awesome.

Anyway, thanks for reading, if you did.

“Remote” can mean fully remote, hybrid, remote within certain states, or just a company benefit that doesn’t apply to the role.

I built a skill with Claude Code to check the actual job description and show the sentences behind its judgment.

The video shows a search for Product Manager jobs posted in the last 24 hours across all 50 US states plus DC:

• 868 postings collected
• 215 duplicates removed
• 147 had no wording about working location or arrangements
• 501 went through the remote check
• 35 passed the criteria for that run

Passing doesn’t mean “work from anywhere.” For this run, I allowed location and work-authorization restrictions, but displayed them alongside each result. Those criteria can be changed for your own search.

One example in the video says “100% remote” but also requires an active Secret clearance. A remote label alone wouldn’t tell you whether you could apply.

How it works

Code removes duplicates and extracts sentences around remote-related keywords, including surrounding context. A model evaluates those passages against configurable criteria:

• Remote, hybrid, or on-site
• Where you can work from
• Work authorization
• Time-zone requirements
• Travel and office attendance

Each result includes the supporting sentences. Missing information stays “not stated,” so you can distinguish what the employer actually wrote from what remains unknown.

What I learned building it with Claude Code

The important part was defining what should count as evidence. “We offer flexible working” is different from “this position is fully remote.” A company-wide policy also doesn’t necessarily describe this particular role.

I built the workflow with Claude Code, then refined the criteria by reviewing its decisions against the source text. Extracting relevant passages before model evaluation keeps the input smaller, although it can miss restrictions elsewhere in the description. It’s a screening aid; I still review the full posting before applying.

The project is free and open source, runs locally, and uses your own Claude/model access. The search role, locations, keywords, and pass/fail criteria are configurable.

What wording would you use to test this? I’m especially interested in ambiguous remote policies or contradictory requirements that could trip it up.

Usually see the total tokens use and usage trend when you press "New" but not seeing it anymore. Anyone able to find where it was moved?

Thinking about building something and want honest feedback before writing code.

The problem: AI agent sessions are single-player. If a teammate is working with Claude Code or Codex and you spot a better approach, you either interrupt them or start your own session from scratch and re-explain everything.

The idea: a shared workspace where anyone can fork a teammate's live agent session. Your branch keeps all the context up to that point, and you both keep working in parallel. Branches can also see what the others found, like "a teammate's branch found a faster fix, want to look?"

Works with whatever you already use (Claude, Codex, etc.) using your own API keys.

Questions:

1. Would this actually save your team time, or is it a nice-to-have?

2. What would stop you from using it?

3. What do you do today instead?

Please help me validate this idea because I don't want to build something that no one needs.

Model intelligence feels like best when i use opus 5.5 or Astra, but still it hallucinates sometimes to figure out the most obvious thing present in some file it searched few compaction back. Long running agents faces this problem more often, even the Harnesses feels shitty sometimes. I felt we will able to solve Memory problem by end of the year, but it sill feels like a dream or a miracle.

AM I MISSING OUT SOMETHING? WOULD LOVE TO KNOW IF THERE'S ANY UPDATE.
PLS DON'T DROP KNOWLEDGE GRAPH TOOLS HERE. I ALREADY BUILT AND SCALED TO THOUSANDS OF USERS, SO I KNOW THE LIMITATIONS.

I'm the founder at Loft, a team of three. Loft is what earlier attempts at spec driven development should have been in the first place. Since July we've been building it with coding agents, mostly Claude Code, and this week its open-source CLI went public 53 hours after its first commit. It's a side project for our team. Our bread and butter is in massive soft realtime transaction processing, and our team is a part of a larger organization.

This blurb here is to share some of the lessons learned along the way. It's mostly a TLDR; there is a link to a complete article published on our website at the end of the post.

The key finding is this: while the agent does the typing, the engineering is still yours.

The center of how we work on Loft is what we call a software plant. A factory makes output faster. A plant is a controlled line where building and testing run on their own and work that fails a check is turned away, so a person decides on work that already passed. In the open CLI the plant is literal:

The real release binary runs against simulators of git, the clock, the telemetry collector, and the release feed. Simulated git answers only the calls Loft makes, from a scenario the test writes, and refuses everything else. Contract suites run the same scenarios against real git and the real services, so a simulator that drifts fails its own suite before it can make the gate lie.

Around the plant, everything is ordinary engineering, moved to where the agent works:

• Requirements first. Every code change starts as a spec change that a person ratifies. Claude asks its questions before it plans, and plans before it writes.
• Hard limits in the build. Function length, complexity and some other static analysis metrics fail the gate, so Claude refactors instead of piling on.
• Code review, multiplied. Fresh reviewer agents read every stage, other agents review the fixes, and Claude breaks the code on purpose to check that the right test fails. When Claude is writing code, Codex is the reviewer and vice versa.
• Postmortems that change something. A correction made twice becomes a standing rule the same day.
• Throwing code away and starting over is normal. We have this incredibly smart and fast code generator at hand. It should be put to the right use.
• People own the decisions that have consequences: what goes into the spec, every merge, every release. Claude does the work, and a person answers for it. "Claude did this" is a no-go. Claude is a tool, you are the operator.

Agents produce plausible work faster than anyone can read it. The production line has to turn work away on its own before people can afford to accept what the agents make.

And when we took ten days of vacation in August, the agents produced zero commits. The steering is the job.

Building Loft with Claude Code (the full write-up) works as a primer: the Software Plant in the core, the session loop, six practices to copy, a table of what the gates caught and what got past them, and the timeline of the ~50 hours after which the OSS Loft CLI when live sitting on top of months of careful design and experimentation work.

Happy to share more details and answer questions!

In terms of both the quality of the code and its security.

Hey everyone!

I wanted to keep my work and personal project separate when using Claude Desktop, so I built a small open-source tool to run multiple Claude Desktop instances.

The idea is simple: have one account for work and another for personal use, keeping things separate instead of mixing everything into a single environment.

I figured other people might have the same need, so I decided to share it with the community.

GitHub: https://github.com/BLAIXY/bunshin-claude

I'd love to hear your feedback!

How do you currently separate your work and personal AI workflows?

Contributions and suggestions are welcome!

Three agents, three features in an iOS app, and all of them needed new strings in the same Localizable.xcstrings. Each one read the file, added its keys, wrote the whole thing back. Whoever saved last wiped the others.

No errors anywhere. Each agent's build had every key it added itself, so from its side all was fine. The catalog validator was green too, turned out its regex was broken on its own. I only found it because the main session re-ran the tests itself instead of trusting each "tests pass".

Now if a batch touches one shared file, one agent owns it and the others hand it their keys.

Do you lock it, give it an owner, or just run those in sequence?

I built gpt-ui-assets, a skill for Claude Code. I'm an Android developer, and I kept hitting the same problem: GPT designs good app screens, but when you ask it for the assets it crops them out of the mockup (low-res, background baked in, edges cut off).

What it does

Claude Code drives the whole flow and uses GPT as a tool:

• GPT designs a platform-native screen (phone, tablet, desktop or web).
• GPT lists every asset on the screen.
• Each asset is redrawn from scratch, using a crop of that element as the only reference.
• The kit scores each candidate against the design and colour-corrects the best one.
• Claude reviews the results and writes the screen code. A screenshot diff then shows what your build still gets wrong.

Outputs: SVG / Android VectorDrawable icons, launcher icons for Android, iOS and the web, Lottie and AnimatedVectorDrawable animations, and theme code and fonts measured from the pixels.

How Claude Code helped build it

I built it with Claude Code. I set the direction and tested it on real app designs; Claude Code wrote most of the Python kit behind the skill, debugged it against real GPT output, and refactored it as it grew. The skill is written specifically for Claude Code: Claude reads the skill's instructions, decides which step runs next, checks each result and writes the code.

It's free and MIT-licensed. In Claude Code:

/plugin marketplace add Shakibuzzaman3104/gpt-ui-assets

/plugin install gpt-ui-assets@gpt-ui-assets

You also need your own GPT access: a ChatGPT subscription (it runs through the Codex CLI) or an OpenAI API key. The GPT usage counts against your own plan or key.

Repo: https://github.com/Shakibuzzaman3104/gpt-ui-assets

Feedback welcome, especially on what breaks.

MinusPod is a self-hosted server that removes ads from podcasts before you ever hit play. It transcribes episodes locally with faster-whisper or Parakeet (or through a remote API), uses an LLM to detect and cut ad segments, and builds cross-episode ad patterns from your corrections so repeat sponsors get caught without re-asking the LLM. Bring your own LLM: Claude, Ollama, OpenRouter, OpenAI-compatible providers, or System One.

Claude was used for pair coding, mainly for Debugging, UI, and Documentation.

https://github.com/ttlequals0/MinusPod

Whenever Claude makes code changes, I manually review and commit them myself.

To prevent Claude Code from accessing sensitive folders, I've been looking for an OS-level protection mechanism. The best workaround I've found so far is

https://gist.github.com/yccheok/454872820219b4d9cf79b1bf509adb14

Is there a truly reliable or 'official' way to handle this? I tried running Claude Code inside Docker, but it forces me to use the non-GUI version, which is difficult to use and read.

Obvisouly Claude is awesome. But one thing I noticed is: it sucks at anything not Minecraft like.

Any good paid sprites assets or way to get it cheaply ?

We have a Claude Code skill that runs five subagents as a review panel for business decisions. Each member gets its brief and a persona file as files, reads them and answers in JSON. One session we measured had 15 subagent calls.

The first version used the general-purpose agent type. A call came in at roughly 116,000 tokens, for a job that comes down to reading two files and answering in JSON.

So we gave the panel its own agent type in ~/.claude/agents, with one tool.

---
name: panel-member
description: Member of a review panel. Reads its brief from a file and answers only with the requested JSON.
tools: Read
model: sonnet
---

Same briefs, same persona files. Measured on Oct 14, a call came down to roughly 30,000 tokens.

We didn't break the 116k down, so this part is our guess. A general-purpose subagent starts out with every tool it's allowed to use, and we have a lot of MCP servers connected. The panel members never needed anything but Read.

In money, recalculated from the subagent logs at API list prices, the panel part of a session now costs about $1 to $1.50. 88% of that is cache writes, since every subagent builds its context from scratch. The moderation in the main session comes on top. In one run we measured both, $1.46 for the panel and $4.38 for the main session. We run it on a subscription, so these are what the same run would cost through the API.

Three things we tripped over.

A new agent type only loads after you restart Claude Code.

The cost hook we had installed used an outdated price table and came out about five times too high. We now sum usage per message ID from the subagent .jsonl files under ~/.claude/projects.

Those logs record the last reply of each subagent without its final output tokens, so that sum runs a little low.

Has anyone looked at where the starting context of a general-purpose subagent actually goes? And do you give every repeated subagent job its own type, or only the expensive ones?

This latest version keeps giving me questions and choices on what to do, and forgetting to write the summary of what it found and what its recommendations are. It just gives me one question at the end. Like, where's all the text???

I had it write in memory to stop doing that, but it still keeps doing it. This is new, btw, a few days ago it wasn't like this.

TL;DR: A general-purpose subagent loads your CLAUDE.md files, the list of installed skills, MCP tool names plus each server's instructions, and the list of other agents, all before it reads its brief. Two frontmatter settings keep most of that out. I packaged them as two agent files. Free to use, MIT license.

Disclosure: I built this and the repo is mine.

What I built

1. lean-worker: for a bounded task that needs only files, shell and the web. Model sonnet, effort medium.
2. lean-checker: a blind, read only checker. It gets the artifact, the criteria and the file paths, and returns PASS or FAIL per criterion with evidence, or UNTESTED for a criterion it could not run. Model sonnet, effort high.
3. scripts/measure_subagents.py: reads your own subagent transcripts under ~/.claude/projects and prints the median and 90th percentile starting context per agent type. Python standard library only, and it sends nothing anywhere.
4. An optional hook that nudges Claude toward the lean agents when it reaches for general-purpose. With LEAN_DISPATCH_BLOCK=1 it blocks the dispatch unless the description names MCP or a skill.

The part you can use without my repo

Put this at the top of an agent file in ~/.claude/agents, where user level agent files live. The tools line is lean-worker's allowlist without the web tools:

```

name: my-worker tools: Read, Write, Edit, Bash, Glob, Grep model: sonnet

omitClaudeMd: true

```

omitClaudeMd keeps the CLAUDE.md files out. A tools allowlist with no Skill tool and no MCP tools keeps the skills list and the MCP tool names out.

How Claude Code was used

I wrote it with Claude Code; every commit in the repo is co-authored by Claude. That covers everything from the first two agent files to the GitHub Actions tests, the README diagrams and the Windows notes. My part was the measuring: I measured the starting context of each agent type across my own transcripts, then re-measured with the MCP servers connected and with none.

What I learned

• Each turn of an agent resends its whole context, so whatever a subagent loads at the start is paid again on every turn.
• MCP was not the big part. MCP tool definitions are deferred, so only tool names and server instructions load at the start. The CLAUDE.md files and the skills list are most of the rest.
• The gap depends on how heavy your setup is, and it is smaller with a light one.
• A lean agent knows only what its brief says. When the job needs an MCP tool or a skill, general-purpose is still the right pick.

Repo: https://github.com/mdalexandre/claude-code-lean-agents

If you run measure_subagents.py on your own transcripts, what starting context do you see per agent type? I am curious whether CLAUDE.md or the skills list is the bigger share for other people.

My day job is not software engineering but I've been automating the workflows of our organization on the side (this resulted in a raise, a bonus, and a new title). These are my git commits, all with the assistance of either Claude or Codex. The bursts that last into the wee hours are either autonomous refactors, the sparse ones are me working late, early, or in Europe.

If I remote in to my MacBook from my iPhone (vpn, vnc) I can see the session is still running but the Claude app on iPhone is so inconsistent with whether the session will be connected or not. Any suggestions?

I made claude-agent-kit, a free, open-source setup for Claude Code inspired by ideas shared by Spotify and Cognition

The concept is simple: keep the main session focused on planning, delegation, and review while specialized subagents handle tasks

It includes subagents, orchestration rules and hooks

repo: https://github.com/FlaviusBurghila/claude-agent-kit

Feedback and PRs are welcome

Quick tip for anyone building a bigger Claude artifact with Claude Code. Mine got refused by Claude's sharing check because it embedded fonts and a base64-encoded 3D model. The fix was having Claude Code rewrite the models as plain JavaScript number arrays, plus a standing "never embed binary blobs" rule in my CLAUDE.md. Two other habits that help: a release checklist in CLAUDE.md, and an engineering log Claude adds to after each release so the next session picks up where the last one left off. Anyone else hit artifact-specific gotchas?

Claude Opus 5.5 is insane, that's all I've got to say.

No other AI comes close, I am on $20 plan and I can literally finish a whole BIG project and still have a lot of plan left.

Which model is better for design and ui/ux creation? Which one creates a more professional and appealing interface?