u/Intelligent_Path_878

Hi everyone,

I’m not trying to ask the subreddit moderators to resolve this, and I understand this community is not Anthropic support.

I’m looking for advice from other users who may have gone through a similar situation.

I had a paid Claude subscription that cost around $100/month. I cancelled it through the support bot and requested a refund. More than 10 days passed without any update, so I contacted support again. It has now been around 15+ days total, and I still have not received a response or refund.

Has anyone successfully escalated a delayed refund request with Anthropic support? Is there a specific support path, wording, or channel that worked for you?

I won’t share any personal billing details publicly, but I’d appreciate any advice from people who dealt with this before.

Hi r/Kotlin,

I’ve been working on a small finite-state-machine library for the JVM:

https://github.com/NGirchev/fsm

The original goal was simple: I often have domain objects with a `status` / `state` field, and I want transitions to be explicit instead of scattered across services as `if/when` blocks.

The library supports:

- Kotlin-first FSM builder API

- domain FSMs that apply transitions to an existing object

- guards / conditional transitions

- actions and timeouts

- Mermaid and PlantUML diagram generation

- Java usage as well, since it is a JVM library

Recently I also tried an experiment: I built a visual FSM editor for this library almost as a one-shot implementation using Codex CLI with GPT-5.5. I only tested it lightly so far, but code generation already works for both Kotlin and Java.

I’m curious whether this direction feels useful to Kotlin/JVM developers, or whether you’d rather keep FSM definitions purely in code.

https://i.redd.it/1nuyld9tgq1h1.gif

I ran a small experiment on my Java pet project and the result was less clean than I expected.

Small disclaimer: I did the final comparison review on April 19, 2026. With AI coding tools, that already makes the result somewhat time-sensitive.

The project is a multi-module Java monolith with a Telegram bot, an agent loop, tools, memory, streaming responses, and a mix of local models and OpenRouter models. At that point I had already started moving part of the agent logic away from Spring AI into my own FSM/ReAct flow, but the code still had many bugs.

So I copied the whole project into two separate branches, gave Codex 5.3 and Claude Opus 4.6 the same vague prompt, and let both agents work almost autonomously.

The rules were intentionally simple:

• do the task however you think is right
• pass the existing tests, including e2e
• run review
• fix review comments
• repeat until only minor comments remain

Basically, pure vibe coding.

Claude Opus produced the more attractive architecture in several places. The best part was around streaming output. It created a clearer boundary between raw model chunks and text that could be shown to a Telegram user. That matters because models do not stream neat sentences. They can send <th, then ink>, then internal reasoning, then a closing tag. If you clean the final text only after streaming is done, part of that garbage may already have reached the user.

In that sense, Claude's idea was better: filter before emitting user-visible events.

Codex was less elegant. More logic was tied to context mutation and post-processing. It felt like code that could become harder to maintain later.

But then I asked for a sequence diagram / call chain and found the uncomfortable part: some of Claude's nice architecture was not actually used. The tests were green because the old Spring AI streaming path was still covering the e2e scenario, not because the new ReAct/FSM streaming flow was properly integrated.

That changed how I read the whole result.

Codex had its own problems. It introduced more state and more concurrency risk. One branch even failed a REST test slice on the full verify run. But Codex also added practical things that mattered:

• timeout and fallback for a stuck AI stream
• conversation history recovery after restart
• URL hygiene before showing links to the user
• better separation of progress and final answer in the streaming contract
• batching for Telegram progress updates

Not all of it was beautiful. Some of it was exactly the kind of code you later want to simplify. But more of it was connected to the working product.

That was the main lesson for me: with AI coding agents, "good architecture" and "executed code path" are not the same thing.

The second experiment was similar. I compared Codex 5.3 with a newer GPT model on the same area. Again, the stronger model proposed a neater abstraction, but the code mostly did not execute and it did not find the real bugs. Codex was more boring, more direct, and more useful for this specific autonomous development loop.

I am not claiming Codex is universally better than Claude. This was one project, one setup, one date, one style of prompting, and one fairly specific task: autonomous development on a Java Telegram agent with minimal supervision.

For planning, research, and abstract design, stronger models can be better. Anthropic's own Claude Code setup also points in that direction: Opus is used for planning/advice, while execution often goes through a different model.

But for my setup, the practical result was simple:

the model that looked less impressive often moved the real product further.

The part I am still thinking about is not "which model is best." It is how to evaluate coding agents when they can produce convincing architecture that never actually enters the runtime path.

For people building or using AI coding agents: how do you check that the agent's best-looking work is really connected to the product, not just passing tests through an old path?

I use AI coding tools a lot, so this is not an anti-AI post. If anything, the problem is that they are useful enough to change how I work.

A couple of years ago I started a small Java pet project because I wanted my own Telegram bot. It was private, had a different name, and did a few simple things for me. When AI coding tools became more accessible, I kept working on it partly as a way to learn how to use them properly.

That project eventually grew into open-daimon: a Java framework that routes between local models and OpenRouter models depending on the task. Now it is slowly becoming something like an AI-agent workflow. It handles model choice, tool use, and some of the surrounding orchestration.

The useful part is obvious. AI can write boring mappings, generate tests, find bugs, explain failures, and sometimes implement a feature faster than I would have started it.

But the uncomfortable part is also real: full vibe coding can start to feel like gambling.

Not because AI is useless. Because it works often enough.

It works often enough that you start trusting it a little too much. It works often enough that reading every generated line starts to feel optional. It works often enough that you think: maybe one more prompt, one more model, one more review pass, one more test run, and this will finally be clean.

The reward is not only the finished feature. The reward is the anticipation that the next run might solve it.

On my own project, this mode does not reliably make me faster. I spend a lot of time repairing things that used to work, reviewing plausible changes that broke old assumptions, and cleaning up architecture drift. The strange part is that I still keep going. If I were writing everything by hand, I might have abandoned the project earlier. With AI, there is always a chance that the next session gives me a big jump forward.

There is another layer too. Right now AI feels cheap for what it gives us. But if we rebuild our engineering habits around cheap tokens and then prices change, the dependency becomes obvious. Writing without AI will feel slower, and using AI may become much more expensive.

I do not think the answer is "do not use AI." That would be silly. The distinction I care about is AI-assisted engineering versus a reward loop that feels like engineering because it keeps producing motion.

For people building or using coding agents: how do you keep autonomy, cost, and review under control when the system keeps generating plausible next steps?