sunlc.ai

HODLer/Defi Farmer❌/Quant❌/Arbitrager❌

1Following

159followers

Feed

Old Sun guides you to build a financial terminal system worth millions 3: Overview page construction approach The core requirement for building the entire system is to integrate all the data and information needed for my daily investment decisions into an ALL IN ONE terminal, and the overview page is the most important entry point of this terminal. Opening this page, I can spend 5 minutes each morning and evening to get a comprehensive understanding of all the important market indicators of the day. Development process is divided into several steps: 1. Determine page layout The image below is a long screenshot of my entire overview page, divided into: 1) Top left corner: important macro indicators including US Treasury yields, precious metals/crude oil, exchange rates, interest rates for the coming year, recently added Trump indicators and South Korean stock market foreign capital inflow indicators, etc. 2) Top right corner: crypto indicators including Fear and Greed Index, AHR999, stablecoins, hash rate, BTC/ETH technical indicators, MSTR data, ETF data, etc. 3) Middle left: watchlist area where you can add real-time quotes for crypto, US stocks, commodities, and other key focuses 4) Middle right: event news area, further subdivided into macro news, crypto news, and earnings events 5) Bottom area: arbitrage opportunities area, prominently displaying currently monitored arbitrage opportunities 6) Bottommost area: system status area showing the status of various data collectors in the system, including basic data, various funding rates/trading volumes/data, as well as US stock and options data. After finalizing the layout, Codex can develop an interactive demo page to confirm AI’s understanding is accurate and the final layout meets requirements. Any modification suggestions can be easily implemented by adding comments on the Codex page (as simple as adding comments in Word), which is very convenient. 2. Determine data sources Data sources are the core of the entire system. My system is not positioned as a real-time trading system, so most data update frequencies are not very high; updating once per hour is sufficient, and some can even be updated after daily market close. Also, I prefer to use free data sources as much as possible, and for a small number of key data, I hope to find inexpensive sources. My experience here is to refer to excellent open-source systems online, then brainstorm separately with Claude and Codex. After clearly describing the requirements, Claude and Codex each provide recommended data source comparisons. After comprehensively considering frequency/performance/price, the final decision is made. My system’s data source subscription cost is only FMP 20U/month and IB quotes 10U/month. 3. Indicator breakdown I organized all the indicators currently on the overview page, each indicator’s function, data source, and update frequency. You can directly copy this or adjust according to your own needs. See the following 4 screenshots. For news-type information, most sources are foreign data sources. To facilitate quick reading, I also provide Chinese translations of the headlines, but clicking still opens the original article. Additionally, it’s necessary to confirm which indicators need to retain historical data and which only require the latest real-time value. These can be determined after discussion with AI. 4. Development process After indicators and data sources are confirmed, the development process can refer to my tweet from yesterday. The basic principle is not to develop too many things at once, but to develop module by module, data source by data source slowly. Each module must be carefully tested and data verified manually after completion. Problems should be discovered and corrected early with AI; otherwise, problems accumulating later will be harder to fix. With AI, the entire development process can be effortless, but early-stage requirement discussions and later testing still require indispensable human involvement. Don’t expect to complete system development with just a few sentences as some viral posts online claim. For a rigorous financial terminal system, the accuracy of every number is directly related to money.

"Old Sun Takes You to Build a Financial Terminal System Worth Millions 2: Developing Workflow" Today is Saturday, a day off, and I'm too lazy to write a long article, so I'll just talk about the current workflow and precautions: 1. Claude Opus 5 is mainly used for module function design, especially when you haven't fully figured out the functionality of a new module. You can brainstorm more with Claude. Claude will ask you questions step by step to gradually understand your needs and provide a design document that exceeds your expectations. After the initial draft is completed, hand it over to Codex for review and supplementation to form the final development document and plan. All documents are saved in md format under the docs directory. 2. Development uses Codex; the screenshot shows my Codex workspace. The most important thing is to remember to open a separate thread for each functional module (see Figure 1). The benefits are, first, the context won't get mixed up, and second, multiple independent modules can be developed in parallel. Also, Codex can create an interactive demo page before formal development, where you can directly annotate and modify to ensure the final finalized requirements are correctly understood. The overview module in the screenshot is relatively simple, so I directly discussed requirements with Codex. For complex requirements, it's recommended to discuss with Claude first. 3. The entire development environment is completed inside Docker, which facilitates subsequent maintenance and deployment. 4. Before developing the entire system, discuss clearly with Claude the system positioning, main functional modules, architecture, page style, performance requirements, etc., and solidify these constraints in agents.md. For example, in my system, the backend uses Python FAST API, and the database uses ClickHouse, all decided through discussions with Claude. The frontend uses a professional financial terminal style; you can have Claude and Codex each design several styles to choose the favorite for finalization. 5. After each module is developed, Codex must first perform self-testing, then manually check if the interface layout is correct and data is accurate. Data accuracy is the most important for financial terminals and also where AI is most prone to hallucinations, so manual careful verification is essential. This is also the most time-consuming part. 6. After completing the above step, have Claude perform code review (see Figure 2). The prompt can be written like this: "I had Codex complete the development of the xx module according to the xx development document. Please conduct a detailed review of this module's code, including but not limited to consistency between code and documentation, data accuracy, indicator calculation formulas, page layout, module performance, code conciseness, and reusability, and provide optimization suggestions. Save the review results in xxx_audit.md according to the severity of issues." 7. After Claude's review is complete, let Codex re-examine the review comments and provide the final plan. The prompt can be: "I had Claude conduct a code review of the xx module you developed; the review report is in xxx.md. Please objectively evaluate this report, re-check the code one by one, and provide final modification suggestions and plans saved in md. Be careful not to over-modify." Codex often over-modifies minor issues, so the last sentence is very important. 8. Finally, let Codex complete code modifications and self-testing according to the modification plan, then Claude reviews again. Generally, there won't be major issues. 9. Use GitHub for version control throughout development, especially when multiple modules are developed in parallel, allowing multiple branches and letting Codex manage versions well. 10. After each module is completed, Claude can summarize the module's function introduction into the readme.md document and update installation manuals, user manuals, and other documents. Also, regularly integrate, summarize, and delete outdated documents from the development process. 11. I connected Codex with Obsidian so that context and historical memory can be better preserved. You can ask Codex directly for specific methods. 12. As the system develops and modules increase, regular overall code optimization and simplification can be performed. For example, which code and common modules can be extracted (this should ideally be designed from the start, but AI inevitably produces some duplicate code later, so extracting it improves maintainability). Generally, one round of optimization can reduce code by 10%-20%. However, after each optimization, the entire module needs to be retested, which is quite laborious."

"Old Sun Takes You to Build a Financial Terminal System Worth Millions 1: Overall Concept and Architecture" I originally promised to start updating yesterday, but got delayed due to some matters. Today, I officially start updating the first article. Although all my code is written by AI, I have always insisted on typing every word of all tweets by hand, not even using typeless, because AI-written articles lack a human touch. The update speed may not be very fast, but I will definitely keep updating. The first article will explain why I want to build this system, the overall concept, the building cost, and the system's overall architecture. 1. Why build this system I not only do various quantitative and arbitrage trading in the crypto space but also invest in US stocks. I have always attached great importance to macro research and need a terminal that can integrate so much information daily for quick browsing and decision-making. When I worked in professional institutions before, the company would provide Bloomberg and Reuters terminals costing over a hundred thousand per year, which obviously individual users wouldn't afford. Now with AI, I want to build one myself. At the beginning of the year, when openclaw was popular, I tried to build a set but eventually chose to abandon Lobster and upgrade to the current terminal. The main reason is that openclaw, as an AI agent, is convenient for handling some daily small tasks, but since most tasks are script-based, it still has randomness and instability issues when processing financial data, which is fatal for financial data that requires extremely high quality. So from March, I started rebuilding this system using codex+claude. This system is tailor-made for me, completely based on my trading strategies, trading varieties, and even my daily routine. The display resolution is customized for my 48-inch 4K screen to ensure that the key information I care about can be displayed on one screen as much as possible. So what you can learn from my entire sharing process is not only the system building process but also my entire investment philosophy, which is far more valuable than just open-sourcing the code. 2. Building cost AI models: claude 200U subscription + gpt 200U subscription + grok 30U subscription (from Twitter membership). Mainly use claude's opus 5 max for overall system architecture design and functional module design, then hand over to codex's gpt 5.6 sol max for development and self-testing, and finally to claude for final review and acceptance testing. Server: A MAC MINI M4 16G is sufficient, built at home, then accessed externally via Cloudflare. Specific details will be explained later. Data sources: The system currently has nearly 30 external data sources, most of which are free. The only paid ones are FMP's 20U subscription and IB's 10U data fee, which already meet most needs. 3. System architecture In one sentence: a terminal that integrates crypto + US stocks + macro three main lines. The system adopts a completely decoupled front-end and back-end architecture: Back-end is fully encapsulated in Python as Fast API Front-end uses React + Ant Design framework Database uses ClickHouse Development and deployment are done entirely with Docker. Current system architecture includes: 9 crypto exchanges (unified access via CCXT) 26+ external data sources covering market data, macro data, on-chain data, Twitter news, on-chain anomalies, AI-related news, etc. 40+ work processes running in the background to update various data and indicators regularly 213 US stock AI-related research targets 78 data tables in the backend ClickHouse Over 560 configuration and runtime items It can be said to be very finely split. Current system functional modules mainly include: The overview page can display all the core data I care about on one screen, including macro indicators, crypto indicators, major event news, watchlist market data, arbitrage opportunities, and system status. The arbitrage page shows crypto positive/negative fee rate arbitrage, US stock and RWA target arbitrage, futures-spot premium, OI anomalies, and other important information. The US stock page shows over 200 AI-related targets I follow, with a focus on 30 core targets. This is the core module of my entire system and an important basis for my US stock investment decisions. The IB account and crypto account modules allow easy viewing of all my holdings spread across various exchanges and sub-accounts. The Twitter news module uses grok to collect AI and macro news hotspots I focus on every morning and evening, then uses LLM to summarize and organize them into Twitter morning/evening reports at 7:30 AM and 10 PM respectively. The US stock daily report collects market data and news one hour after US market open (10:30 PM) and at morning close (7:30 AM), organizing them into a daily report based on the data indicators I follow. The above Twitter and US stock daily reports are fully customized according to my daily routine. After waking up at 7:30 AM, I can know the overnight market trends and hot news within 5 minutes. Similarly, one hour after US market open, I can promptly know the day's information and usually make all trading decisions before 11 PM, never staying up late. Additionally, I developed an AI research report library feature. I bought a large number of professional AI industry research reports such as Semi Analysis, FundAI, Damnang, etc. These reports are very large and professional, sometimes hard to fully understand by myself. I put them all into the research report library and use LLM to dissect and analyze them, forming a very powerful research tool. There are also multiple dashboards for options, meme coins, US bonds, USD, inflation, etc., all information I pay attention to daily. Starting tomorrow, I will break down the functions, design ideas, and development methods of each module one by one. Feel free to leave comments for discussion if you have questions. I have a strong dislike for stupidity, so I won't answer overly basic questions or requests for source code directly.

Next, let's talk about my views on the software and application sectors: I believe the software and application sectors are currently severely undervalued and have been completely oversold. After the hardware sector enters a high-level adjustment phase, capital will gradually flow into quality software stocks to restore their valuations. The previously held market logic that large models will kill software companies does not hold, for several reasons: 1. For enterprises, the most important aspects of software are data accuracy and reliable workflows. Products like NOW and CRM have already deeply embedded themselves into many companies' entire workflows. For most enterprises, it is impossible to replace them easily, let alone choose to develop large models in-house. User stickiness is extremely strong. 2. The market worries that the current software seat-selling model will decline due to corporate layoffs. This concern may be valid in the short term, but in the long term, it is actually beneficial. For software companies, transitioning from selling seats to selling usage is not difficult. For enterprise clients, layoffs are due to AI replacement; in the future, software users will gradually be replaced by AI. Originally, one seat worked 5*8 hours per week; after replacement by AI, it will work 7*24 hours, increasing software usage by 4 times. 3. The current AI penetration rate is still very low. The direct users of large models are mainly cutting-edge technical personnel. To enable most people to use AI in the future, the usage form will definitely not be direct use of large models, but rather AI being seamlessly embedded into commonly used software such as chat software, office software, video software, etc. From this perspective, platform companies with massive customers like MSFT and META are currently severely undervalued. 4. The progress of AI large models is a huge negative for programmers but a major positive for software companies. The biggest cost for software companies is labor cost. Within the next 3 years, they can definitely eliminate two-thirds of developers, significantly improving software company profits. 5. Hardware companies sell shovels, software companies dig for gold. Now that all the shovels have been sold, whether gold can be found depends on software companies. I personally am strongly optimistic about MSFT, GOOG, NOW, CRM, and other targets. (META is actually not bad, but I have no confidence in Zuckerberg.) In the future, many innovative application software companies will emerge, and many companies without moats will be eliminated. Therefore, I do not recommend blindly buying IGV, as it contains too many companies.