Agent ignores configured files and returns credit balance error on queries

[arjunshetty1]

When running GitClaw on localhost:3333, generic conversational queries work correctly and receive valid responses. However, when asking questions that should be answered from the configured files (files and folders set up in the project), the agent fails to reference those files and instead returns a credit balance error.

Steps to Reproduce

• Configure both OpenAI (ChatGPT) and Anthropic (Claude) API keys in the project
• Start the agent - accessible at localhost:3333
• Ask a generic question (e.g. "Hello, how are you?") - works correctly
• Ask a question that should be answered from the knowledge base (e.g. "What is the leave policy?" or "What files have you been configured with?") fails

Expected Behavior

The agent should search the configured files and folders, retrieve relevant context, and return an accurate answer.

[shreyas-lyzr]

Apologies for the wait @arjunshetty1.

The "credit balance error" is the key clue here. That message comes from Anthropic, not from GitClaw — it means the agent fell through to the Anthropic provider for a query and the Anthropic key has zero balance. The fact that generic queries work (likely routed to OpenAI) but knowledge-base queries fail (routed to Anthropic) suggests:

1. Different requests are landing on different providers. Possibly RAG/knowledge retrieval uses an embedding step or a follow-up call that defaults to Anthropic, while chat-only paths default to OpenAI.
2. Anthropic key has no balance / is expired. Top-up or rotate the key.

To confirm the routing, can you share:

• The output of gitclaw --verbose for the failing query (will show which provider+model is being called per request)
• Your agent.yaml model: block (specifically preferred and fallback)

The expected fix on our side is probably one or both of:

• Surface the underlying provider error inline in the response (PR Surface LLM errors in CLI, use pi-ai credential detection, and implement model fallback #2 by @Priyanshu-Priyam was supposed to address this — main now does it for stopReason === "error", but if the error comes back as a different shape, it might still be falling through)
• Make sure RAG/knowledge-retrieval paths inherit the same model selection logic as chat, not hardcode a provider

Will reproduce locally once I have the verbose output + manifest. Thank you for the screenshot.