It's 2026 and Schwab still can't get external bank linking to work

Edited for title clarification: The issue described here is specific to my account. I successfully linked IBKR, but after a failed Wise verification, Schwab's external bank linking feature became unusable for me. Customer support couldn't fix it, and I get the same error when trying another account.

I'd like to link an external bank account because otherwise I have to pay $15 for every wire transfer.

But this feature is buggy. Initially, I couldn't link any external bank account at all. It just showed "feature temporarily unavailable." Then I searched social media and found that formatting or abbreviating the address in Schwab might help. And it actually did.

On Friday night, I entered the information for my Wise USD account (Column xxx Bank) and my IBKR account (UMB xxx Bank). Both entered the verification process, so I just had to wait for two deposits and one withdrawal.

On Monday morning, Schwab withdrew $0.33 from my Wise balance, and deposited $0.15 and $0.18 into my IBKR account. The timing and amounts made the transactions look related, but they actually weren't, and I knew that. Schwab then allowed me to enter the amounts to continue the verification.

I made a stupid mistake at that point: I entered the IBKR deposit amounts into the Wise verification. (I don't remember exactly what the error message said.) The pending Wise link then disappeared, so I had to start the process over. Unfortunately, the "feature temporarily unavailable" error came back.

There was one small difference this time. Before I formatted my address, the error appeared immediately after I entered the bank information. This time, I could get to the "Verification notice" page, but the error appeared after I clicked Continue.

I didn't touch the pending IBKR verification. I waited for the withdrawal, entered the correct amount, and IBKR was linked successfully.

So I contacted customer service. They helped "reset" my profile and asked me to clear my browser cache and cookies. The representative even helped me "format my address" (again!) and admitted that this was "one of the causes." But none of that helped.

Even worse, after trying several times, I eventually got:

>"We can't link your account right now. Choose another transfer or payment method."

I also tried another account (another IBKR account, actually), but got the same error. At this point, it looks like I'm simply not allowed to link any external account.

Almost the exact same problem was described years ago in this post.

I contacted the Move Money Team as well, but they could only repeat that "your address is mismatched."

But if the address mismatch is really the reason, then:

Why did formatting the address make the feature work initially?
Why did customer service themselves recommend formatting the address?
And why was I initially able to enter the verification process at all?

It feels like Schwab has never actually fixed the underlying problem with their backend.

reddit.com

u/Sad_Exercise702 — 2 days ago

▲ 5 r/IA_Italia+1 crossposts

OpenCode Go seems to be much more compatible with Claude Code/Codex than its documentation suggests

I recently subscribed to OpenCode Go and have been experimenting with using it as a provider for Claude Code, Codex, etc. The main reason I subscribed is that I can apparently get up to $60 worth of DeepSeek models for a $10/$5 subscription.

Initially, I thought I would need something like LiteLLM as a compatibility layer. The OpenCode Go documentation lists DeepSeek as supporting only the /chat/completions endpoint.

However, after changing the base_url and API key in Claude Code/Codex to point to OpenCode Go, I found that DeepSeek V4 Flash worked surprisingly well.

Even more interestingly, in Claude Code, web_search also worked correctly.

I then tested some other models in Claude Code. For some of them, OpenCode Go only explicitly documents an Anthropic-compatible endpoint such as /v1/messages, without saying whether /chat/completions is supported. These models worked with Claude Code, although web search was unavailable for them (the tool call returned nothing).

MiniMax M3 is one example. Its documentation only lists an Anthropic-compatible /v1/messages endpoint, but I found that it could also be used successfully through /chat/completions.

I also tried to reproduce this setup with LiteLLM. I used Cloudflare AI Gateway to route the requests to DeepSeek rather than letting LiteLLM use Anthropic's official API, and had LiteLLM translate the Anthropic API format into DeepSeek's /chat/completions format.

This exposed an interesting problem: DeepSeek requires the reasoning/thinking content from a previous response to be passed back unchanged in subsequent requests. LiteLLM didn't preserve it correctly in my test, so the agent would eventually fail when it tried to reason again.

But I didn't encounter this problem when going through OpenCode Go.

Combined with the fact that DeepSeek explicitly documents Anthropic API compatibility and specifically mentions that Anthropic's web_search can work with DeepSeek, this makes me wonder whether OpenCode Go is actually routing my requests directly to DeepSeek's official API, rather than doing its own complete translation layer.

I haven't inspected the implementation, so this is only an inference. OpenCode Go could also be doing its own translation correctly. But the combination of:

Claude Code working through an Anthropic-compatible interface
DeepSeek reasoning being preserved correctly
DeepSeek web_search working
and some endpoints working even when they aren't explicitly documented

makes the direct-to-provider-routing hypothesis quite plausible.

I haven't tested every model or every feature, so these are only preliminary observations. But they seem to suggest a few things:

If an endpoint is explicitly listed by OpenCode Go, it seems to work without major problems.
If an endpoint isn't listed, that doesn't necessarily mean it isn't supported.
There may be more protocol translation/routing happening behind the scenes than the endpoint documentation suggests.

And I think this is the funny part about OpenCode Go: it's ultimately an OpenCode subscription, not really a general-purpose Coding Plan or API product. Inside OpenCode, everything is relatively straightforward and works as intended. But once you try to use the same subscription outside OpenCode, things become surprisingly confusing: some undocumented combinations work, some documented ones have missing features, and it's not always obvious what protocol is actually being handled at each layer.

Maybe that's simply because OpenCode Go was designed to be used with OpenCode in the first place, rather than as a standalone model gateway.

Has anyone looked into how OpenCode Go actually handles these requests internally?

(I used ChatGPT to polish my expressions.)

u/Sad_Exercise702 — 5 days ago

▲ 2 r/opencodeCLI

OpenCode CLI is sticking to DeepSeek reasoning format for custom providers?

I usually proxy my API requests through Cloudflare AI Gateway to keep track of everything. Most of the time, I use DeepSeek and it works perfectly.

However, today I tried using Cerebras through the gateway and it failed (Not at the beginning but at the time you send the second message, or OC trying to call tools). The error message was: messages.2.assistant.reasoning_content: property 'messages.2.assistant.reasoning_content' is unsupported

https://preview.redd.it/kmuk5p5j5rdh1.png?width=1674&format=png&auto=webp&s=62bd585da0aa75c44508f5cd51d55b02b5ff3554

When I checked my Cloudflare Dashboard logs, I noticed that OpenCode CLI was sending reasoning_content in the messages. Since Cerebras doesn't recognize that parameter, it threw an error.

Interestingly, if I connect Cerebras directly to OpenCode (without the Cloudflare proxy), it works fine without any errors.

I've tested other tools like Hermes Agent and Trae Work (all proxied via CFAIG), and they handle this beautifully. They only add the reasoning_content parameter if they detect that a DeepSeek model is actually being used. For other models, they leave it out.

Is anyone else experiencing this? It seems like OpenCode CLI is hardcoding or forcing the DeepSeek format for all custom providers, rather than adapting based on the model.

reddit.com

u/Sad_Exercise702 — 1 month ago