ALL PROJECTS/CUSTOMGPT — CRYPTO MARKET INTELLIGENCE

Overview

CustomGPT is a crypto market-intelligence assistant: a chat application whose answers are assembled, on demand, from live market data rather than from a model's memory. A trader asks "what's the funding rate on BTC futures?" or "show me whale movements and the long/short ratio" in plain language, and the assistant decides which of sixty-seven declared tool functions to call, fetches the real numbers, runs the indicator maths and answers with charts and tables.

Underneath the chat sits an integration layer spanning five market-data providers — spot and futures pricing, derivatives positioning, market-cap reference data, on-chain metrics and social sentiment — declared as one function schema an LLM can reason over. On top of it sits a Streamlit workspace with sign-in, per-user chat history, file upload and export, backed by a small relational store.

I joined as a contract engineer for the final push. The product existed, but the work of three people sat on three divergent branches that no longer merged, and a large part of the tool surface either failed outright or returned data the assistant could not use. My brief was narrow and concrete: make it one codebase, make every function work, and prove it.

Problem

An LLM tool surface fails differently from an ordinary API, and worse.

When a normal endpoint breaks, a caller gets an error and handles it. When a tool function breaks, the assistant improvises around it — it answers anyway, in confident prose, with whatever it can reach. A partly-broken market-data surface therefore does not produce visible failures; it produces plausible, wrong financial answers. That made "most of the endpoints work" an unacceptable finishing state.

The integration surface was also unusually wide for its age: five vendors, each with its own auth, rate limits, pagination, symbol conventions and failure vocabulary. The same asset is spelled differently by each provider, and several of them answer a bad request with a 200 and an empty body rather than an error — so "it returned something" was not evidence of anything.

And the code was in three places at once. Three contributors had worked in parallel on branches that had drifted past the point where the tooling could reconcile them; the histories overlapped, the same functions had been edited in incompatible ways on each side, and there was no test suite to tell a good merge from a bad one. Merging blind risked silently reverting someone's fix — which, on this surface, would look exactly like nothing at all.

System Design

How It Works

01/04
01

A question becomes a data call

How plain language turns into a real market number instead of a confident guess.

  1. 1A trader asks in plain language — a funding rate, a whale movement, an indicator on a pair
  2. 2The assistant is given the declared tool schema and selects a function and its arguments
  3. 3The backend executes that call against the provider that actually owns the data
  4. 4The result is handed back for the assistant to narrate, with the numbers coming from the market rather than the model
02

Five providers, one surface

How five different vendor APIs are made to look like one thing to the layer above.

  1. 1Each provider sits behind its own wrapper that owns its auth, pagination and rate limits
  2. 2Symbols and parameters are normalised, so the same asset means the same thing everywhere
  3. 3Failure is normalised to one shape — an empty or errored success becomes an explicit error object
  4. 4So the layer above never has to know which vendor answered — only whether it answered
03

Three branches become one

How work that had drifted past automatic merging was reconciled without losing anyone's fixes.

  1. 1Each conflicting function was reviewed on both sides and resolved on merit, not by file or by branch
  2. 2The third contributor's branch was folded in as its own explicit pass rather than in the same sweep
  3. 3The merged tree was re-probed against every provider before anything was called done
  4. 4The result is one codebase where each function is the best of the three versions that existed
04

Proof, not assurance

How the hand-off was made verifiable instead of asserted.

  1. 1A status probe records what every provider returns for every asset, before and after the repairs
  2. 2Fifty plain-language phrasings, each bound to the function that must answer it, are called live against their vendors
  3. 3Each run writes a timestamped result set and a summary to disk
  4. 4The final run stands at fifty of fifty — and the earlier forty-nine sits beside it, so the progression is auditable

Key Features

  • Natural-language market questions answered from live data across five providers, with the assistant choosing the right tool call
  • Sixty-seven declared tool functions — spot and futures pricing, order books, derivatives positioning, on-chain metrics and social sentiment
  • Technical analysis on demand — moving averages, RSI, MACD, ATR and Bollinger bands, with candlestick and indicator charts
  • Derivatives context — whale movements, liquidations, funding rates, open interest and long/short ratios
  • On-chain intelligence — active addresses, transaction volume, MVRV, exchange flows, network growth and developer activity
  • Social intelligence — social volume and dominance, sentiment balance, topic and word trends, engagement and ranking scores
  • A Streamlit workspace with sign-in, per-user chat history, file upload and export over a small relational store
  • A recorded test surface — a provider status probe plus a fifty-question coverage suite called live against the vendors, each run written to disk as JSON and CSV

Outcomes

  • Took the tool surface from partly-broken to a recorded fifty-of-fifty pass on a fifty-question suite called live against the vendors
  • Reconciled three divergent contributor branches into one codebase by hand, function by function, without silently reverting anyone's work
  • Aligned the declared tool schema with the implementations, closing the failure mode that matters most on an LLM surface — a confident answer built on a call that did not really work
  • Put each of the five providers behind a wrapper that hides its auth, symbol convention and pagination — and reports failure the same way, so a failed call now fails instead of returning an empty success
  • Left the hand-off auditable: a provider status probe and timestamped result sets on disk, so the state of the system was verifiable rather than asserted
  • Delivered the whole engagement inside a two-day window, authoring fourteen of the repository's eighteen commits

More work

MVP100Hours preview
AI GROWTH PLATFORM

MVP100Hours

An AI-powered lead-to-close platform — silent visitor intelligence to autonomous AI voice outreach

VIEW PROJECT