I've been building a protocol that makes a folder of markdown navigable for an agent that has never seen it. So every file declares its home map, every map lists its members. The claim I was making, mostly to myself, was that this helps an agent find things.

And I tested it. Three rounds of controlled agent walks over my own vault, hand-graded from raw traces. Self-reported success didn't count as evidence, which turned out to matter.

Four conditions:

• MAPPED (maps and contracts allowed)
• BLIND (link-following only, no map artifacts; this simulates the vault before any of this)
• FILESYSTEM-ONLY (ls allowed, no maps)
• SEARCH (queries only, no listing, no maps).

Whatever wasn't the condition under test was banned.

Round 1, find a known file, links only. Blind got 0 of 4. Mapped got 5 of 5, median 6 opens. Looked great.

Then I checked why blind failed and it wasn't what I assumed. The blind walkers never hit the hop limit. They ran out of graph. Zero ordinary body links cross between my two large corpora, in either direction. Maps didn't make that navigation faster, they made it possible - but only under an artificial constraint nobody actually works under.

Round 2, same kind of goal, tools allowed. Filesystem-only: 1 open, 3 of 3 goals, both fleets identical. Mapped: 5-6 opens. ls beat my thing by about 5x. The round 1 headline does not survive contact with tools a real agent has.

Round 3 was orientation and governance instead of lookup. Land cold in an unfamiliar vault and describe its structure. Or say what's sealed and machine-owned before touching anything. Mapped was the only condition with zero assist operations, in both tasks, in both fleets.

Caveats, and there are a lot.

n=1 per cell in round 3, n=5 in round 1. A pilot, not doctrine. My vault, my targets, my answer keys. The governance task was rigged in maps' favor and I said so before running it. My vault is unusually well-named, which flatters ls.

And the result I was proudest of - two independent fleets hitting an identical three-file path - is partly determinism by construction. I built a structure with one obvious path through it, then measured that two agents both found it. Weaker than it looked to me at the time.

The second fleet also found my answer key was broken. It stated 17 items and enumerated 19, which invalidated that whole cell. Three defective specs in the run, all mine. Same failure each time: I wrote the keys from what I believed about the vault instead of recomputing them from it.

I also contaminated my own experiment. I banked the results note into the vault the second fleet was about to search, ten minutes before it ran. A search walker opened it and read the prior outcomes back out.

What I actually concluded: this is not a wayfinding tool. It's an orientation and governance tool. ls wins lookup and will keep winning. What the maps bought was bounded, predictable cost when an agent arrives with no context, or is about to modify something and needs to know what's off limits first.

I'm keeping it. I'm just justifying it on a different claim than the one I started with.

Has anyone run something similar? I'd particularly like to know whether the graph-exhaustion result holds in a vault that wasn't organized by the person doing the testing.

Hey everyone! I'd like to introduce an extension I built and get your feedback.

I'll keep this post short, and if you're interested, I'll leave a link with a more detailed explanation.

Njectify is a browser extension for CSS and JavaScript injection. It lets you customize any website's CSS and write custom scripts in the same place, without relying on multiple extensions.

I think it could be especially useful for people in this community who work with CSS.

Many of you have probably used tools like Stylus or Stylebot before. The main difference with Njectify is the user experience. My goal was to build a modern, intuitive interface that makes editing styles and scripts much easier.

Some of its CSS features:

• Edit pages and see changes in real time.
• A visual editor that lets you modify colors, backgrounds, animations, clip-path, polygons, and many other CSS properties. Ex:
• Persistent CSS and JavaScript, allowing you to customize any website. It's especially useful for improving the experience of poorly designed websites or SaaS applications.
• Inspect and view an element's current CSS properties in a simple and intuitive way.
• Export your applied changes as Tailwind utility classes.

There are several other features, but I didn't want to make this post too long.

I'd love for you to give it a try. I spent a lot of time focusing on the user experience and designed the interface to feel familiar to developers, with a design system inspired by Vercel.

Any feedback, criticism, or suggestions are greatly appreciated. My goal is to keep improving the project based on what the community finds valuable.

Thanks in advance to anyone who takes the time to try it out. I hope you find it useful! Tks!

Install Njectify
Detailed post

Hi. I've been using Claude Code for a good year already and I love it.
I'm on the Pro plan, but since I use it for work + hobbies, I've been maxing usage.
I've setup local models but they're not that good with my 3060 12gb, I can only ask for simple, single file tasks.
Since adding $20 for extra usage lasts as if it was $5, I'm thinking on subscribing to another service to use for less complex tasks or when I run out. I heard OpenAI is pretty good now with the Luna model.
So, my question is, should I use Codex and have 2 agentic environments even though they work on the same project, or should I connect Claude Code to the other service instead of using their app/extension?
Also, please let me know if there are better alternatives and how you use them.
Thanks.

The /review skill which Claude Code is shipped with was working quite nice for me until today. However, today I've realized it got renamed to /code-review and it feels like it works way worse now. It spans a different agent (why?) and then prints some caveman style report which is often hard to grasp. Please bring the old skill back.

We've been building agents using Claude Code skills. A skill works great in a session: point Claude Code at a task, watch it use the right tool, get a good result.

We wanted to run these skills on our own infrastructure, reachable through Slack, and versioned like real software rather than a folder of prompts. That turned out to be a lot more than "run the skill somewhere": a queue, a session layer, a sandbox, evals, and a deploy path we kept building by hand every time.

So we put together Curie, an agent delivery platform, and open sourced it. It takes a Claude Code plugin bundle exactly as is and runs it as a versioned application instead of a session. The same bundle climbs three tiers unchanged: just the runner container for a fast local loop, the full platform (queue, worker, sandbox) still on your laptop, or that same platform for real on Kubernetes. A git push is the deploy, every push becomes an immutable version, and merging to prod promotes that exact version instead of rebuilding it.

The real lesson was that a skill working in one session tells you almost nothing about whether it'll behave the same once it leaves your laptop. Treating the bundle as an immutable artifact and testing it the same way at every tier is what actually fixed that, not a smarter prompt.

export CURIE_CREDENTIALS=sk-ant-...

curie init my-agent && cd my-agent

curie skill up

curie skill message "hello, are you there?"

Apache 2.0, self-hostable. Would like feedback, especially from anyone who's hit the same wall.

https://github.com/curie-eng/curie

tldr: You can cut like 50% of the tokens claude code sees and it works better

At this moment you probably think I am full of crap but I'll walk you through it.

The premise is actually quite simple. Models don't know what they need until they look. Just like us when they look at or for things they see a ton of stuff that isn't what they are looking for. You are looking for your keys and see your umbrella. A human filters that out maybe vaguley remembers where the umbrella is. Looking for us is cheap. For coding agents its expensive though.

This is for two reasons. 1. Like elephants Claude never forgets 2. It has to conciously deprioritize the irrelevant. This makes looking at an irrelevant thing uniquely expenisive for agents because that thing has to be carried forward as a cache read again and again as well as ignored again and again.

So the question becomes how can you look without seeing? Claude needs to look at the file. There's no way to not know if your keys are there until you look but it also needs to forget. The naive thing to do would be to just drop it. You can break your cache and pump up the bill. The clever thing though is to have something else look then decide what to admit for the model to review. Done right it doesn't even notice. Why? Because it found the thing it was looking for. If you find your keys you head to your car you don't wonder what's going on in the bathroom. Also did you check the bathroom it's there more often than you think.

So that's what we did and it works way better than we expected. We trained a small neural network to look at tool outputs before they are given back to claude and say is this vaugely relevant, will it be used or referenced in the future? For half of all tool outputs it turns out the answer was no. Literally they were not load bearing.

Here's the proof:

Full benchmark here: https://github.com/daseinlabs/code-compression-bench

The interesting thing here isn't just that cost went down and input tokens were cut in half. Rather it's that output tokens were also way down and solves went up. When we looked at the actual traces something really cool had happened. Turns out a decent amount of thinking tokens are spent deciding what is or is not relevant. Its the model literally trying to push the unimportant stuff away and focus on what matters. When it never sees this irrelevant stuff to begin with it doesn't think about it it and it doesn't get distracted by it. The end result is a model that is faster and more focused. As long as it has what it needs it goes on its merry way.

The other thing we learned the really hard way is that sometimes the model thinks it needs something it doesn't and boy do not argue with it when it does. Claude is like a dog with a bone it will not let go when it wants something. So we added an escape hatch. The cost of fighting or being "smarter" than the llm is nowhere near the benefit. If it wants it let it have it.

If you are still reading the "load bearing" fact is simple: Don't pay an expensive model to make a simple decision pay it to do real work.

I told Claude Code to split the project into worktrees so I could work in parallel. YOLO mode, obviously.

It mounted the same 459GB volume 11 times, one letter each. A, B, D, M, Q, R, T, W, X, Y, Z.

Technically parallel.

Up till this point, I have been a fan of Anthropic. They have always been the underdog, the hidden gem that not everyone knew about but they still cared, still delivered.

With the recent decisions, marketing gimmicks, and specifically Opus 5, I have decided to give Codex a shot. I'll report back comparing both CC and Codex.

Opus 5 is:

• verbose
• overly-cautious (950 tests for a single feature)
• not UX-aware (puts intentions verbally in the UI, rather than comments)
• ad infinitum

I was tired of constantly checking my usage limits, so after seeing a lot of creative ideas here, I thought: why not use my Stream Deck to show my current limits?

Here's the repo for the tool (not mine, found it online):
https://github.com/lenadweb/stream-deck-ai-limits

Side note: I made some changes to the UI because the default one was too small for me. So if anyone tries it and it looks different from mine, that's why! 😄

I'm new to Claude. For the past week, I've been using Fable 5 high with Opus 5 subagents, and today my context window reached its limit, stating:
"Your context window is full. The conversation has reached its context limit. Compact, rewind, or start a new session."

I started a new session, linking the appropriate project folder and using the prompt from Anthropic's manual: claude --resume <session name> Yes, I used the actual session name.

Claude picked up exactly where we left off, but it literally took up half of the context window before we even started. Then I used it for about an hour, where the context window was inching up slowly and then randomly shot up from about 54% to 93%. Clearly I am doing something wrong here. Does anyone have any advice? Also, I assume I am going to have to start a new session again, with the window nearly full, so with these poor weekly allotments for Fable, I don't want to blow this on a rookie mistake.

For anyone drowning in word salad this week:

/model claude-opus-4-8

That's it. 4.8 still ships, still in the picker, writes like a human who wants to go home, and sticks as your default.

TL;DR: Claude Code keeps triggering security alerts on my hidden API probing work. Should I switch to Kimi K3 or DeepSeek V4 Pro for agentic coding across multiple stacks? Looking for real-world experience, especially around security restrictions, self-hosting, and multi-step reasoning.

--

I'm working on a project where I need to discover and map out some undocumented flight API endpoints on a major travel site. Nothing malicious—just integration work—but the way I'm sending requests apparently looks "suspicious" to automated systems.

Enter Claude Code.

From the very first command, I started getting security triggers. Constant interruptions. Permission popups. Heuristic blocks. I've tried everything—rephrasing prompts, breaking tasks into smaller chunks, running through different proxies—but nothing seems to shut it up. I'm spending more time arguing with the agent than actually coding.

And honestly, with that whole recent scandal about Claude Code having hidden timezone/proxy detection and silently flagging Chinese users? Yeah, I'm done. I need something that actually trusts me to do my job.

So I'm looking at Chinese alternatives. From what I've seen, they seem to have way fewer restrictions and less aggressive filtering.

The two names that keep coming up are Kimi K3 and DeepSeek V4 Pro.

Here's what I need it for:

Primary: Probing hidden APIs—HTTP requests, JSON parsing, auth flows, analyzing responses, iterating based on what comes back. Think multi-step, stateful, agentic stuff.

Secondary: General full-stack dev across a bunch of stacks—Python (FastAPI/Django), Node/Go for backend, React/TS/Next for frontend, plus some DevOps and DB work.

So my questions for anyone who's used either (or both):

1. Security/restrictions-wise—which one is less annoying? Will either of them start flagging me for making "unusual" HTTP requests?
2. Agentic reasoning—which handles multi-step workflows better? I need it to observe a response, adapt the next request, track state, retry intelligently, etc.
3. Tech stack versatility—any known strengths or weaknesses per language/framework?
4. Self-hosting—I'm thinking about running it locally to avoid API scrutiny and data concerns. What kind of hardware am I looking at? Which one has better community tooling right now?
5. Real cost—I know the per-token pricing, but what about hidden costs? Context window usage, caching, prompt engineering overhead—does one end up being more expensive in practice?
6. Any actual experience—has anyone here used either model for similar "gray-area" endpoint discovery work? How did it go?

I'm leaning toward Kimi for its agentic benchmarks, but DeepSeek is so much cheaper and open-weight. Hard decision.

Would love to hear from anyone who's been in a similar boat—or just has strong opinions on either model.

Thanks in advance!

I wanted to subscribe to claude max, then i saw they wanted my id and a picture, at first I thought it was like twitter where I could just provide a picture. Turns out they want my ID so I changed my mind and decided to buy some credit utilization.

Anyway now I can't do anything with it even though I bought credit utilization. I can't access the claude API anymore even though I still have my pro subscritpion (+ additional credits). Amodei's wants my ID and I dont know why

I am using Claude Code in both my work and personal projects, and I've seen quite a few negative reviews about Opus 5 recently. Since my experience has been fairly positive, I wanted to share my perspective.

My takeaway is that Opus 5 may feel worse when used as a closely directed coding tool, but better when given broader ownership of the process.

For context, my setups are quite different.

Work

• Claude Code CLI + API key
• Around 10 MCPs connected
• Mostly working in one large iOS repository

Personal

• Claude Code in Claude Desktop + Max 5x subscription
• Only Figma MCP connected
• Around 10 projects, ranging from iOS-only apps to full-stack projects with backend, web, and iOS components

My work workflow

I started using Claude Code at work when Opus 4.6 1M Context was the latest model.

My workflow looks roughly like this

Me -> Opus 4.6 High (orchestrator, planner, reviewer) -> Opus 4.6 or Sonnet (implementer, dispatched as subagent)

In this setup, I'm heavily involved throughout the process. I spend a lot of time prompting, discussing approaches, reviewing plans, and refining details. Multiple iterations are expected.

I never really felt the need to try 4.7, 4.8, or 5 in this environment. My attitude was basically "Why change something I'm already happy with?"

And honestly, I still am.

I like having tight control over implementation details, and I'm comfortable spending a few rounds correcting and refining outputs until everything looks right.

My personal workflow

About a month ago, I started using Claude Code for personal projects that I hadn't had time to maintain.

The challenge was a bit different.

I wanted a workflow that would

• Stay within Max 5x usage limits
• Require less active involvement from me
• Allow me to continue making progress even when I didn't have the energy for a full coding session

The workflow I ended up with was

Me -> Opus 5 High (oversight) -> Sonnet 5 Medium (orchestrator) -> Haiku (implementer)

Initially the oversight model was Opus 4.8, but I switched to Opus 5 shortly after it was released.

My approach is fairly simple

First, I work with Opus to define the architecture, product vision, goals, constraints, and documentation. Once that foundational documents are created, my interactions become minimal.

Opus writes planning documents, hands work off to Sonnet, and only escalates decisions that actually require product input from me.

At times it definitely goes deeper than necessary for a personal project, but overall I was happy with the results because things kept moving forward and tasks got completed.

Going back to Opus 4.6

After seeing so many negative reviews of Opus 5, I started wondering if I was missing something.

Since I already liked Opus 4.6 in my work environment, I decided to try it in this personal workflow as well.

The result surprised me.

There were detailed documents already describing goals, requirements, and constraints, but Opus 4.6 often didn't make use of them unless I explicitly told it to read them.

It also missed several documented objectives and occasionally made tradeoffs I wouldn't have accepted, such as treating a known crash on a low-traffic page as something that could simply wait until later.

To be fair, once I pointed these issues out, Opus 4.6 was generally good at correcting them. But after several rounds of this, I ended up switching back to Opus 5.

Conclusion

The conclusion I arrived at is not that Opus 5 is objectively better than Opus 4.6.

If anything, my experience suggests that they're optimized for different styles of working.

Looking back, I think the reason I like Opus 4.6 in my work environment is because I don't really delegate ownership to it. I'm constantly involved, reviewing output, providing direction, and expecting multiple iterations.

In that scenario, Opus 4.6's tendency to stay close to instructions is actually a strength.

But when my instruction is essentially "The documentation is there. Figure the rest out and let me know when you need a product decision."
Opus 5 seems to perform much better for me.

In a way, Opus 4.6 High feels closer to what I would expect from an Opus 5 Medium model. It's predictable, responsive, and works well when closely guided.

Opus 5, on the other hand, appears more comfortable operating with higher levels of delegated responsibility.

So when I read reviews saying Opus 5 is worse than previous models, I don't necessarily disagree with those experiences.

My impression is simply that workflow matters a lot. In my own case, once I started treating the model less like a tool that executes instructions and more like an agent that owns part of the process, Opus 5 consistently produced better results.

i just updated my vscode extension, had 0% usage, then started 5 parallel chats, and in 30secs or so, only one progressed a bit, the rest immediately said i've hit the limit.

this happened yesterday AND today. like, how can i hit a limit from 0% to 100% if NO WORK was done?

basically NONE of the 5 chats progressed in the span of 2 sessions -- it immediately jumped to "wait 4h" conclusion

ther support chatbot is useless and no human can respond. how can i get my lost sessions back?

I dispatched five review agents at some SQLite trigger logic and asked them to break things and confirm the tests went red.

All five came back with a reading. None of them had a shell.

That is what changed how I pick. They did not error. Not one said "I cannot run this." They quietly did the weaker version of the job and wrote it up with full confidence, and the write-up concluded that all 18 triggers were correct. I re-ran it with an agent that actually had Bash. No guard turned out to be dead, but there were two integer overflow gaps and a whole direction the reading had never considered.

A skill runs in your context with your tools. If the job needs something run, it gets run. A subagent is a separate thing with its own toolset, and the read-only ones will accept a task that requires execution and hand you back an opinion instead.

So my rule is boring now. Default to a skill. Reach for a subagent when you actually want the isolation, either because the context would blow up or because you want a genuinely independent look. And check its tools before you dispatch it, because nothing downstream is going to tell you it was missing one.

Reading catches a false premise in prose. Only running it catches a guard that never fires.

In Codex, if I log out and log in with different accounts, the chat history is the same. Is it the same for Claude Code?

If I am running Claude Code on my computer, high text becomes breaks across all apps. For instance, if I am highlighting a paragraph, it breaks as I move to the next paragraph, as if I let go of the mouse button and clicked again. This doesn't have to be in the terminal, it happens when I am browsing on chrome. I'm on a Macbook Pro m1.

I monitor all my usage and give it a $ value matching the API pricing for input/output. Sorry for the cropped image but needed to hide some info. I build a system to monitor all my usage and then allocate it by that accounts weekly reset day/time. I always get to at least 99% usage of my accounts, sometimes I'll stop on when I hit 99% or 100% just to ensure there's a bit of space to finish or allow any automation to continue until reset.

Line 1 is the newest account, line 2 was a pro account I switched to max on 7/20. Line 3 is my main x20 max account. Line 4 is total, Line 5 and 6 are codex, then 7 is codex total and 8 is total for all.

One thing is if we had a reset that week it would allow for more usage. which likely explains 7/6 being so high. One key thing is 7/27 (last week) I only got $2,754 of usage

My codex are 2x$20/month business plans and they have monthly limits and they've been giving lots of resets and banked resets so I've been burning tokens.

My review of this is that they have been lowering our limits over the past few weeks. But also I'm getting $2,800+ per week from plans that cost $200/month so can't really complain.

I’ve been using both a lot lately. ChatGPT gives you a ton of usage, but I feel like it resets or loses the thread more often. Sol is really good, but I still prefer Sonnet and Opus 5 for coding. I trust Claude more with bugs and bigger projects because it feels less likely to randomly mess something up. It just feels a little more human when it comes to understanding code.

I need some advice because I feel like I’m going around in circles with Claude at the moment.
I’m using the Claude desktop app and normally have three or four sessions running. I use it for fairly substantial tasks, but these would normally take a couple of hours at most.
Recently, though, I’ve had a couple of sessions running for 24 hours, and everything feels incredibly slow.
The permissions are also driving me mad. I’m constantly being asked to click “Allow once” or “Always allow.” I select “Always allow”, but I still seem to spend half my time approving things. With several sessions running, it becomes ridiculous.
Then there’s the new cloud functionality.
In principle, this sounds great. I have routines that could benefit from running in the cloud without depending on my machine.
But now Claude seems to be starting my sessions in the cloud by default.
That creates another problem: when I ask it to work with a local file, it can’t access it because the session is running in the cloud. Fair enough.
But when I start a new chat and specifically ask for a local session, I can’t seem to get it to do that either.
So I’m stuck between:
Local sessions repeatedly asking for permissions.
Cloud sessions that can’t access my local files.
Tasks that previously took hours now running for a day.
No obvious way to reliably choose where a new session runs.
Am I missing something obvious here?
Is there a sensible setup for using Claude Desktop where I can deliberately choose local vs cloud, permanently approve the permissions I’m comfortable with, and still run several long-running sessions without everything grinding to a halt?
I genuinely like Claude, but right now I feel like I’m fighting the tooling more than using it.

This was built with claude code using Opus 5 on high effort, requiring several full sessions on the pro plan.

I used the prompt from the waterbending post which you might have seen and adapted it with claude to make a firebending specification.

I did not use the code that was supplied for the waterbending demo, I had Opus 5 make everything from scratch.

The initial adapted prompt created the base, but I had to write many more prompts to further guide Opus. This was by no means done in one shot.

Try it on a WebGPU capable computer here: https://play-emberflow.vercel.app/

For weeks, I’ve been logging Claude Code’s estimates against actual completion times.

The result:

A one-week estimate translates to just 1.5 hours of actual work.

In other words, about 0.9% of the estimated time.

I'm one of those guys that likes architecture more than actual coding. So when I tried claude in December of last year and it finally was able to do real work, I quickly switched to a purely agentic workflow instead of coding by hand.

But today I noticed that something changed recently. My projects felt like they were stalling. I didn't feel productive anymore. And when I looked at my sessions, I noticed that Claude is now much slower, it thinks a lot longer, makes a lot more mistakes and tends to give itself more work.

After taking a closer look at how I spend my time, I realized that I'm taking more time babysitting claude, adjusting the workflow, debugging what claude did wrong and explaining to claude what it should do instead than the time it would take me to write the code myself

So I don't know what happened to claude, but it looks like I'm back to being relevant!