Tried the GitHub app, made sure everything was properly connected, and asked a question about one of my repositories. It repeatedly claimed (5 times) that it wasn't connected and couldn't do anything, telling me to check the checkboxes that were already checked. Only after I showed it a screenshot of the settings did it suddenly comply and answer the question. I guess it still needs more polish.

▲

measurablefunc 5 days ago | parent | next [-]

Screenshots use a different router, so if you get stuck in one modality then pasting a screenshot can sometimes divert whatever "expert" you were stuck on that was refusing to comply. I don't work at OpenAI but I know enough about how these systems are architected to know that once you are stuck in a refusal basin the only way is to start a new session or figure out how to get routed to another node in their MoE configuration. Ironically, they promised their fancy MoE routing would fix issues like these but it seems like they are getting worse.

▲

tacitusarc 5 days ago | parent [-]

It’s actually more complicated than that now. You don’t get that kind of refusal purely from MoE. OpenAI models use a fine-tuned model on a token-based system, where every interaction is wrapped as a “tool call” with some source attached, and a veracity associated with the source. OpenAI tools have high veracity, users have low veracity. To mitigate prompt injection, models are expect a token early in the flow, and then throughout the prompt they expect that token to be associated with the tool calls.

In effect this means user input is easily disbelieved, and the model can accidentally output itself into a state of uncorrectable wrongness. By invoking the image tool, you managed to get your information into the context as “high veracity”.

Note: This info is the result of experimentation, not confirmed by anyone at OpenAI.

▲

measurablefunc 5 days ago | parent [-]

Seems plausible but the overall architecture is still the same, your request has to be "routed" by some NN & if that gets stuck picking a node/"expert" (regardless of "tools" & "veracity" scoring) that keeps refusing the request incorrectly then getting unstuck is highly non-trivial b/c users are not given a choice in what weights are assigned to the "experts", it's magic that OpenAI is performing behind the scenes that no one has any visibility into.

▲

tacitusarc 4 days ago | parent [-]

I think maybe you mean something else when you say MoE. I interpret that as “Mixture of Experts” which is a model type where there is a routing matrix applied per layer to sort of generate the matmul executed on that layer. The experts are the weight columns that are selected, but calling them experts kinda muddies the waters IMO, it’s really just a sparsification strategy. Using that MoE you almost certainly would get various different routing behaviors as you added to the context.

I might misunderstand you but it seems like you think there are multiple models with one dispatching to others? I’m not sure what that sort of multi-agent architecture is called, but I think those would be modeled as tool calls (and I do believe that the image related stuff is certainly specialized models).

In any case, I am saying that GPT5 (or whichever) is the one actually refusing the request. It is making that decision, and only updating its behavior after getting higher trust data confirming the user’s words in its context.

▲

measurablefunc 4 days ago | parent [-]

Here you go: https://q.uiver.app/#q=WzAsOSxbMCwxLCJcXHRleHR7cXVlcnkgffCfp...

▲

tacitusarc 4 days ago | parent [-]

OK that’s what I figured you meant. FWIW, MoE as a term of art means something different, what I described. It’s internal to a single model, part of the logit generation process.

	▲	measurablefunc 4 days ago \| parent [-]
		That's fine, you can pretend my entire diagram is one NN, end result will still be the same whether you put it all inside one box or break it out into many.

▲

kevinslin 5 days ago | parent | prev | next [-]

hi kgeist - i work on the team that manages the github app. are you able to share a conversation where the github connector did not work? feel to message me at https://x.com/kevins8 (dm's open)

	▲	kgeist 4 days ago \| parent [-]
		I think I understand what went wrong. I was confused by the instructions and ChatGPT's UI. I asked the GitHub app to review my repository, and the app told me to click the GitHub icon and select the repository from the menu to grant it access. I did just that and then resent the existing message (which is to be expected from a user). After testing a bit more, from what I understand, the updated setting is applied only to new messages, not to existing ones. The instructions didn't mention that I needed to repeat my question as a separate message again.

▲

Abishek_Muthian 4 days ago | parent | prev [-]

I never had a pleasant GitHub connection experience in any platform.

Permission to allow the specific repo only access never works, so I'll have to allow access to all repo and then manually change it back to specific repo inside GitHub after connecting.

There have been instances of endless loop after Oauth sign-in, more recent experience was in Claude Code Web[1].

Poor GitHub folks, only if someone can donate time/money to this struggling small company these critical issues could be addressed /S

[1] https://github.com/anthropics/claude-code/issues/11730