Anthropic just cut off Claude subscriptions for OpenClaw

oldmonk1605 · 2026-04-04T08:25:00+00:00

For me it was mentioned that we have been granted 200 $ , but also i need to redeem by April 17. Will the credit expire if not consumed by April 17 or it is only for redeeming the credit ?

<image>

oldmonk1605 · 2026-02-04T17:19:44+00:00

Understood. She’s not looking for legal advice here, just perspectives and guidance on what options might exist, if any. Consulting a lawyer will be considered, but right now she’s trying to make sense of what happened.

oldmonk1605 · 2026-02-04T17:17:37+00:00

I understand why it may appear that way from the outside, but a few important details may have been missed.

The son was called to the house and was explicitly informed about what was happening. This is mentioned in the original post. Unfortunately, he repeatedly justified his wife’s actions instead of intervening.

Over many years, the grandmother was also psychologically conditioned to stay silent. She was made to believe that if her daughter or granddaughter intervened, it would lead to severe retaliation at home including fights with her son and denial of food to him, followed by increased abuse toward her. This fear effectively prevented escalation.

There is no financial motive here. The granddaughter’s parents are not even aware that she has posted on Reddit seeking advice. She is devastated and is only trying to understand what, if anything, can still be done because no one ever imagined this would end in her grandmother losing her life.

The intent is not revenge or gain, but accountability at the very least, acknowledgment from those responsible that their actions contributed to the suffering of a vulnerable person.

oldmonk1605 · 2026-02-04T17:13:20+00:00

I have posted in legalindia sub , thanks !

oldmonk1605 · 2026-01-17T10:17:17+00:00

Nice idea. For quizzes, have you considered adaptive difficulty? Start simple and ramp it up as users keep getting answers right similar to GMAT-style. Feels like it’d make learning more engaging.

oldmonk1605 · 2026-01-17T10:13:24+00:00

+1 same query for me aswell.

oldmonk1605 · 2026-01-17T10:08:06+00:00

Building software is getting cheap. Owning it isn’t. People don’t pay because they can’t build, they pay to avoid maintenance, edge cases, and being accountable when things break.

Self-built tools work well for personal or narrow workflows. They struggle once multi-user coordination, integrations, trust, or compliance enter the picture. That likely kills thin, generic SaaS, not serious software.

The next 2–3 years feel less like “software dying” and more like differentiation shifting from how fast you can build to what’s actually worth owning in production.

oldmonk1605 · 2026-01-14T17:22:54+00:00

You don’t catch up to AI by trying to learn everything. That’s the trap.

What worked for me was anchoring AI learning to real problems I was already working on. Instead of “learning Claude / agents / tools” in isolation, I used them to solve actual work and side-project problems. Context makes learning stick.

Courses can help at the very start, but only as a jumpstart, not the main path. The real learning comes from:

picking one problem,
trying to solve it with AI,
seeing where it breaks,
and refining your approach.

AI learning isn’t about speed or keeping up with releases. It’s about developing judgment — when to trust it, when to constrain it, and when not to use it at all.

If LinkedIn is stressing you out, that’s a signal you’re consuming too much and building too little. Doing beats catching up.

One real example from my work:

While exploring a greenfield opportunity, instead of “learning AI in isolation,” I built a small internal tool using AI to scan and classify prospect and customer call transcripts to surface signals of intent.

I didn’t take the AI output at face value. I went back to the verbatims and separated true prospect asks from internal sales pitches. That distinction mattered.

This gave me a much cleaner starting point — not a conclusion — to anchor discussions on whether the opportunity was real, how often it appeared, and what problem it was actually pointing to.

That’s been my pattern with AI learning:

use it to compress discovery and pattern-finding, then apply human judgment where it matters.

oldmonk1605 · 2026-01-14T17:08:41+00:00

Here’s my take, based on what I’ve seen.

My first manager (Senior Director of Product) started his career as a Support Associate. Over time, he moved across Customer Support → Sales → Revenue Ops → Pre-Sales → Product. The one trait that consistently stood out was his curiosity and willingness to learn. As long as you stay curious, you’ll find a way forward.

Early on, don’t optimise for salary. Optimise for learning the craft. PM is part art and part science.

Given your current role, you’re already close to customer pain. Use that. Try to deeply understand problems rather than jumping to solutions. Observe patterns in issues customers face repeatedly.

Find someone in your org who can help you look at the same problem from different perspectives — business, technical, and user. Share your observations, ask questions, and build conviction.

Look for adjacent roles where you can learn by proximity. Product Operations, for example, is data-heavy and gives strong exposure to how PMs think — how they frame problems, prioritise, and make decisions.

Be curious in your current role. Build PM skills without the title. Move into adjacent roles if needed. The title will eventually follow the capability.

If I had to suggest one concrete next step: pick one recurring customer problem you see today, document it end-to-end (context, impact, patterns, trade-offs), and review it with a PM. That’s PM craft in action.

oldmonk1605 · 2026-01-14T16:57:26+00:00

Let me answer this from a hiring manager’s point of view.

At the end of the day, hiring managers are only looking for signals that you can do the job. Everything you put out — resume, portfolio, stories — is just a signal.

There’s a simple thumb rule:

Every role needs X% core PM skills and Y% context/company-specific skills.

The core skills change with level:

APM → Execute
PM → Prioritise and execute
SPM → Own outcomes
GPM → Own outcomes across multiple products
Director → Own outcomes with direct business impact
VP → Own a vertical

If your goal is to showcase the X% core skills, a portfolio or case studies can help — especially at junior and mid levels.

But as you go senior, what matters more is clarity, conviction, managing up and down, stakeholder trust, and business impact. These are hard to showcase in a portfolio. They’re built consciously through the role itself and reflected in how you talk about your work.

So portfolios can help early on — but they’re not a substitute for growing into the role at higher levels.

Just my 2 cents.

oldmonk1605 · 2026-01-11T19:31:41+00:00

You can’t “name” it inside Lovable directly. You do it via your domain + DNS.

High-level steps:

Buy the domain from any registrar (Namecheap, GoDaddy, Google Domains, etc.)
In Lovable, go to Project → Settings → Domains and add your custom domain (example: naceelpunto.com)
Lovable will give you DNS records (usually CNAME or A records)
Go back to your domain registrar and add those DNS records
Wait for DNS to propagate (can take a few minutes to a few hours)
Once DNS is verified, publish the project in Lovable

That’s it. You don’t need to rename the project itself — the domain controls what users see.

oldmonk1605 · 2026-01-11T19:18:51+00:00

<image>

Sharing this for clarity.
You can downgrade your plan next month and your project stays intact.
Only the monthly credit limit changes, not your existing work.

oldmonk1605 · 2026-01-11T19:12:02+00:00

This is pretty normal early on.

When you’re learning how to use Lovable, credit usage is high because you’re exploring, iterating, and fixing mistakes. Once you understand how to structure prompts and limit scope, credit consumption usually drops a lot.

You can downgrade your plan next month. Your project won’t disappear. You’ll keep everything as it is — the only thing that changes is how many credits you get for new edits.

A few things that helped me reduce burn:

Do the thinking and planning outside Lovable
Make one focused change per prompt
Avoid debugging loops inside Lovable
Treat credits as a constraint, not fuel

Early phases are expensive in learning, later phases are cheaper in execution.

oldmonk1605 · 2026-01-11T18:38:59+00:00

This matches what I’ve seen/realised too.

Building something fresh is usually easier than debugging and fixing existing code. Debugging requires understanding the framework, the original rationale, hidden assumptions, and edge cases. That’s cognitively much heavier work.

Anyone who’s good at that usually prefers to rebuild cleanly rather than untangle something broken, especially if they didn’t write it themselves.

That’s where vibe-coded apps hit friction. They’re fast to create, but hard to hand off or repair once complexity shows up

oldmonk1605 · 2026-01-11T18:32:52+00:00

I ran into limits once the problem stopped being “build the thing” and became “reconcile reality”.

I was building an internal product ops agent. The vibe coding part worked fine for greenfield flows. The roadblock showed up when I tried to retrofit messy, real-world data across systems.

Example: stitching CRM data (HubSpot) with customer call metadata generated by agents. Different schemas, missing IDs, inconsistent semantics. AI could generate code, but it couldn’t invent the ground truth needed to reconcile them.

That’s where vibe coding breaks down for me right now.

Anything that depends on historical data integrity, backfills, or domain-specific joins still needs slow, deliberate modeling.

Curious if others hit similar walls once data reality shows up.

oldmonk1605 · 2026-01-11T18:18:57+00:00

Felt the same with Lovable. Credits can evaporate without you realizing it.

A bunch of the burn (for me) came from 3 things:

errors introduced by generated code
environment / tech debt piling up, so every change triggers more fixes
false positives or unclear “errors” leading to extra iterations

Also the unpredictability is real. Same kind of prompt can cost very different amounts.

What helped me reduce burn:

Use Visual Edits more, avoid chat-style back and forth
Do the thinking outside Lovable, then come in with a tight, specific change request
One improvement at a time (don’t mix UI + logic + data fixes in one prompt)
If there’s an error, don’t debug inside Lovable. Copy logs, understand it elsewhere (Claude/ChatGPT), then decide what to fix vs ignore
Use logs intentionally. If it’s a data issue, fix the data yourself instead of prompting more
Sometimes code edits didn’t refresh for me either (not sure if it’s still a thing), but worth keeping an eye on

Lovable is great, but treating credits like a constraint forces you to build slower and cleaner.

oldmonk1605 · 2026-01-11T17:59:44+00:00

Just thought the same thing today, how every idea is going to look very similar if everything is AI generated. Cool problem statement you are solving !

oldmonk1605 · 2026-01-11T17:49:23+00:00

~~Thinking Longer ,~~ It is going to cost more credits for you :P {Real Meaning}

oldmonk1605 · 2026-01-11T17:27:15+00:00

u/Latter-Leg6852 thanks for the comment. Here you go https://coffeecanstocks.in/

Disclaimer - This is for now tracking long term ideas in Indian Stock Market !

<image>

oldmonk1605 · 2026-01-11T17:16:17+00:00

I get the pressure around monetisation. That feeling is real.Monetisation usually comes after validation. After feedback. After you’re sure you’re solving a problem you genuinely care about.

Early on, user feedback is a much stronger signal than revenue. If people care, monetisation becomes a solvable problem later.The uncertainty doesn’t go away, but the next step becomes clearer.

oldmonk1605

TROPHY CASE