[FEATURE]:Pay Go with crypto

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Please add crypto support for payment of opencode go.

up for this

That would be the only missing feature that would make me switch to opencode go

It would be great if one would just transfer crypto and have a balance in opencode that is then used to pay for pay-as-you go or monthly go subscriptions (like openrouter does it). So no credit card is needed.

Crypto payments are highly needed for developers worldwide. I personally use OpenRouter mainly because they support crypto payments, and I’d prefer using OpenCode Go if this gets added.

I'd like a simple option to top up my account with crypto like BTC or USDC for zen and go.

bump :)

This is a must have.

That would be the only missing feature that would make me switch to opencode go

Same here.

Having a credit card does not necessarily mean that I want to use it everywhere and for everything. Not to mention that transactions sometimes are rejected or fail for any number of reasons. And many people don't have a credit card in the first place.
If OpenCode Go is meant to make LLMs accessible "for everyone" and for programmers "around the world", then it must offer payment methods that everyone can use.

I would even be willing to pay 10% more to account for price instability with crypto, so OpenCode does not have to bear that risk.

And while crypto-payments are typically less than ideal for subscriptions, it would still work to just pay for a month, or for any number of months, in advance.

bumping too

That would be the only missing feature that would make me switch to opencode go

Same here.

Having a credit card does not necessarily mean that I want to use it everywhere and for everything. Not to mention that transactions sometimes are rejected or fail for any number of reasons. And many people don't have a credit card in the first place. If OpenCode Go is meant to make LLMs accessible "for everyone" and for programmers "around the world", then it must offer payment methods that everyone can use.

I would even be willing to pay 10% more to account for price instability with crypto, so OpenCode does not have to bear that risk.

And while crypto-payments are typically less than ideal for subscriptions, it would still work to just pay for a month, or for any number of months, in advance.

I second this. Credit cards here in east asia often get rejected and is a headache, crypto works instantly.

There is no good reason to not send a dev to implement a good crypto payment solution like Openrouter did for example. Why not having it done already? It take literally 5 minutes.

How have they not even made a comment on this? Setting this up using Stripe is trivial.

+1
Dear OpenCode developers,
This is a feature that almost every developer needs. OpenCode is already exceptional, and adding this feature could make it truly unmatched. Please make this happen for us!

Hey OpenCode. Nobody will continue using your subscriptions if you don't support crypto. Is this 1995? Should we pay with PayPal or AliPay? No. This is 2026 and we pay with crypto. The whole internet is, coincidentally, moving toward e2e encryption everywhere and crypto payments. Only the corporations will be left behind. Stripe? WTF? Read my lips: NO CORPORATIONS - THIS IS NOT 1995.

OX

#Springboard

Is it your cowardly corporation policies that even prevent you from daring to reply in this thread? You're not just simply matching card data with prompts for the politicians are you?

Disclosure: I build send21, so take this as one option among several. If the blocker is not wanting to run a crypto stack or hand subscription money to a gateway, a pay link lets the subscriber pay in BTC (on-chain or Lightning), USDC or EURC straight to your own wallet. You price in USD, the rate locks for 15 minutes, and an HMAC-signed webhook tells your backend when the payment confirms so the Go plan can switch on automatically.

Honest limits: one link is one payment, so each renewal is a new link created through the API. send21 only prepares payment instructions and never holds keys or funds, and the fee is never taken out of the payment. Docs: https://send21.io/docs

The Phoenixd route mentioned above is the fully self-hosted alternative if you would rather run your own Lightning node.

send21, info@send21.io

The blocker is pressure from their politician overlords.

i want thisss

Thanks for the suggestion!

We don't track plan or payment-method requests in GitHub issues. Please send this to help@anoma.ly so it reaches the team that handles billing.

Closing this issue.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

MAKE CRYPTO PAYMENTS !!!!!!!!!!!!!!!!!!!!!!!!!!!!! END OF 2026 AND STILL only SHI77TY CC payments

Thanks for the suggestion!

We don't track plan or payment-method requests in GitHub issues. Please send this to help@anoma.ly so it reaches the team that handles billing.

Closing this issue.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Noted emailing them now.

Thanks for the suggestion!
We don't track plan or payment-method requests in GitHub issues. Please send this to help@anoma.ly so it reaches the team that handles billing.
Closing this issue.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Noted emailing them now.

No reply. Also card keeps getting declined with OpenCode.

.

I just started using OpenRouter, buttery smooth payment using crypto with WalletConnect via Coinbase. Why can't you do like that?

@Tarquinen

Thanks for the suggestion!

We don't track plan or payment-method requests in GitHub issues. Please send this to help@anoma.ly so it reaches the team that handles billing.

Closing this issue.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

@Tarquinen I understand that billing requests don't belong in a repo for the code - but I'd push back on how this was handled, and I don't think I'm alone.

This issue wasn't a one-off support ticket. It gathered 95+ reactions and dozens of comments describing a real, recurring problem: people whose cards get declined, people in regions where card payments fail, people who use OpenRouter specifically because it accepts crypto. That's not noise - that's public, aggregated demand signal, which is exactly what an issue tracker is for. Closing it as "not planned" and redirecting to help_at_anoma.ly moves that signal into a private inbox where:

there's no visible counter of how many people want this,
there's no public response anyone can link to,
and, judging by the comments above, no response at all arrives.

If the real answer is "crypto payments don't fit our compliance model", that's a perfectly legitimate position - but say it here, publicly, and we can all move on. If the answer is "we'd consider it if there's demand" - then this thread was the demand, and closing it discards the evidence.

A constructive suggestion: reopen this (or open a dedicated issue/label like billing-requests) so payment-method demand stays visible and countable, and give the thread a single substantive maintainer comment on whether it's a "no, because…" or a "maybe, if…". People aren't asking you to build it tomorrow - they're asking not to be quietly routed into a void.

@Tarquinen

Thanks for the suggestion!

We don't track plan or payment-method requests in GitHub issues. Please send this to help@anoma.ly so it reaches the team that handles billing.

Closing this issue.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

@Tarquinen I understand that billing requests don't belong in a repo for the code - but I'd push back on how this was handled, and I don't think I'm alone.

This issue wasn't a one-off support ticket. It gathered 95+ reactions and dozens of comments describing a real, recurring problem: people whose cards get declined, people in regions where card payments fail, people who use OpenRouter specifically because it accepts crypto. That's not noise - that's public, aggregated demand signal, which is exactly what an issue tracker is for. Closing it as "not planned" and redirecting to help_at_anoma.ly moves that signal into a private inbox where:

there's no visible counter of how many people want this,

there's no public response anyone can link to,

and, judging by the comments above, no response at all arrives.

If the real answer is "crypto payments don't fit our compliance model", that's a perfectly legitimate position - but say it here, publicly, and we can all move on. If the answer is "we'd consider it if there's demand" - then this thread was the demand, and closing it discards the evidence.

A constructive suggestion: reopen this (or open a dedicated issue/label like billing-requests) so payment-method demand stays visible and countable, and give the thread a single substantive maintainer comment on whether it's a "no, because…" or a "maybe, if…". People aren't asking you to build it tomorrow - they're asking not to be quietly routed into a void.

He is right! Big support

Navigation Menu

Repository navigation

[FEATURE]:Pay Go with crypto #23153

Feature hasn't been suggested before.

Describe the enhancement you want to request

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]:Pay Go with crypto #23153

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Activity

nylla8444 commented on Apr 23, 2026

lambda-solver commented on Apr 26, 2026

suse-coder commented on Apr 26, 2026

khalile-32bit commented on May 10, 2026

z1bboyen commented on May 14, 2026

hedgeg0d commented on May 16, 2026

prhasn commented on Jun 9, 2026

orvenik commented on Jun 13, 2026

juviee commented on Jun 17, 2026

prhasn commented on Jun 18, 2026

11 remaining items

Kryptopaid commented on Sep 13, 2026

S-14-H commented on Sep 23, 2026

hyarian commented on Oct 3, 2026

621625 commented on Oct 3, 2026

621625 commented on Oct 3, 2026

send21io commented on Oct 8, 2026

621625 commented on Oct 9, 2026

Redshado0w commented on Oct 19, 2026

Tarquinen commented on Oct 20, 2026

god4claw commented on Nov 1, 2026

prhasn commented on Nov 1, 2026

prhasn commented on Nov 7, 2026

atomlab commented on Nov 7, 2026

god4claw commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions